How structure recovery works, and where the model takes over
Apryse Smart Data Extraction separates document extraction into two steps: deterministic structure recovery that identifies reading order, headings, tables, and form fields, followed by purpose-built model interpretation for classification, key-value extraction, and tabular data output. Processing runs on-premises, in a private cloud, or air-gapped. Documents never leave your infrastructure. Output is structured JSON with confidence scores; table data exports to JSON or Excel. It operates standalone or as a preprocessing layer that reduces token cost in LLM pipelines.
Why AI Needs Document Structure Before Intelligence
AI has transformed how organizations extract information from documents. But it hasn't changed the underlying challenge: before AI can understand a document, the document's structure must be understood first.
Headings, tables, reading order, form fields, and relationships between elements provide the context that gives information meaning. When that structure is lost, even the most advanced AI models become less reliable.
That's why Smart Data Extraction separates document understanding into two distinct steps: recovering structure and interpreting meaning.
The two jobs
Parsing recovers structure (or layout): where text sits, what's a heading, what's a table, what order the page should be read in.
Extraction interprets meaning: which value is the invoice total, what type of document this is, or which fields matter for a workflow.
This distinction matters even more when it comes to AI. Large language models excel at reasoning about information, but they are not optimized to consistently recover document structure from complex layouts. Multi-column reports, nested tables, forms, and technical documents often contain relationships that can be lost when content is flattened into plain text. Recovering structure first gives AI a cleaner, more reliable representation of the document to work from.
How the separation works
Smart Data Extraction separates document understanding into two steps: structure recovery and meaningful content extraction.
First, it recovers document structure deterministically, identifying elements such as headings, tables, lists, form fields, and reading order. Rather than flattening a document into plain text, it preserves the relationships that give information context.
This matters because AI models are good at interpreting information, but less reliable at consistently recovering structure from complex layouts. By understanding structure first, AI receives a cleaner and more accurate representation of the document.
Purpose-built document AI then interprets the meaning of that structured content, identifying paragraphs, document types, extracting key values, or building tabular data.
Structure recovery answers where information is and how it relates to other content. AI interpretation answers what that information represents. Together, they transform documents into structured, AI-ready data.
What the combined architecture can accomplish
- Document structure: Parses headers, footers, lists, and paragraphs. Useful for screen reading, content routing, and compliance workflows.
- Form field identification: Detects visual fields in flat PDFs and generates fillable interactive forms.
- Nested tables: Extracts merged cells and multi-row headers, and exports to JSON or Excel.
- Key-value pairs: Reads the spatial relationship between a label and its value, for example "Invoice Number" and "INV-001," without pre-defined zones or templates.
- Document classification: Assigns categories to document pages based on content and structure.
- CAD title block extraction: Purpose-trained for key-value extraction on CAD and technical drawing title blocks.
Output comes back as JSON with page numbers and bounding boxes and can be transformed into any needed format for downstream workflows. This could mean optimizing for search, retrieval, analytics, and any other LLM pipeline. Preserving the document hierarchy gives AI the most accurate data which is not possible with plain text alone.
Where OCR and ICR fit
Not every document starts as machine-readable text. The OCR Module and the Handwriting ICR Module digitize scanned pages and handwritten content before extraction runs on them.
How Much Does Document Extraction Actually Cost?
Cost comes down to two variables: how much compute a method needs, and the price per unit of compute.

Compute and hosting
A purpose-built engine reads document geometry on CPU. A general-purpose model needs far more compute, typically on a GPU, regardless of who hosts it. Self-hosting on infrastructure you already own runs close to the cost of electricity. A cloud API bundles that same compute with software, margin, and per-page fees into every call.
Token cost
Send a full document to an LLM, and you pay to process every token in it, whether or not it contains the data you're looking for. Smart Data Extraction can pull out the relevant fields first, so every token you send the LLM is one it actually needs. You're paying for data, not documents.
Where Should Document Extraction Run?
On-Prem or Cloud?
Smart Data Extraction runs on your infrastructure. Choose an on-premise server, a cloud VM you control, a container, or a fully air-gapped environment with no network access. In any of these configurations, documents never leave your environment.
Compare that to a hyperscaler's cloud document API, like AWS or Google. Your data leaves your environment before extraction starts.
For a bank reviewing filings or a hospital handling patient records, that's not an architectural detail. It's the difference between passing a compliance audit and failing one. As AI moves from pilots into production and compliance frameworks harden, IT teams are increasingly insisting that documents never leave their environment before they'll sign with a vendor. For more on this shift, see When AI, Compliance, and Cloud Costs Collide and our comparison of on-premise vs. cloud smart data extraction.
Clean input before extraction is key to accuracy and compliance
Extraction is only as good as the documents it pulls from. Inconsistent file formats, bundled multi-document PDFs, scanned pages with no selectable text, and sensitive data that can't leave your infrastructure all need to be handled before extraction starts.
As add-ons to the same Server SDK that delivers Smart Data Extraction, developers can prepare documents for maximum accuracy and compliance using:
- Convert and normalize mixed file types → Conversion
- Assemble, split, and reorder bundled files → Document Manipulation
- Redact sensitive data before documents move → Redaction
- OCR scanned and image-only pages → OCR / ICR