Structured Data Extraction: A Technical Guide

Structured data extraction is the process of converting unstructured or semi-structured documents, such as PDFs, scans, and images, into predictable, schema-shaped data (typically JSON) that an application, database, or downstream AI pipeline can use, rather than a wall of unformatted text. This guide is for developers choosing between raw OCR, a rules-based parser, and an AI extraction API, and for teams building RAG, search, or analytics pipelines that need clean input. It covers why OCR alone does not get you there, the architecture most modern extraction APIs use, a concrete worked example, and named tools with technical specifics.

Why OCR Alone Is Not Structured Data Extraction

A document is more than a string of text. Headings, paragraphs, tables, and layout carry information beyond the words, and some content, such as letterhead, boilerplate, and page numbers, is less valuable than the rest. With OCR alone, a scanned PDF becomes searchable text, but the structure is lost: there is no way to tell a header from a table from a paragraph, and pulling out a specific value, such as an invoice total, a date of birth, or a line item, still needs more processing on top of the raw text. How OCR models read characters in the first place is covered in machine learning algorithms for OCR.

The gap matters beyond a single document. Extracted data commonly feeds retrieval-augmented generation, search indexes, or analytics dashboards, and unstructured text with no field boundaries makes all of them harder to build well. Structured extraction closes the gap by understanding the document's structure well enough to return exactly the fields you asked for, correctly typed and organized for whatever consumes them next.

The Two-Step Architecture Most Modern Extraction APIs Use

A pattern shows up consistently across independent implementations, so treat it as the default approach and not something specific to one vendor.

1. Layout-aware parsing first. A layout model processes the document and preserves structure, headings, tables, and reading order, converting it into an intermediate format. Markdown is a common choice because it represents headings, lists, and tables naturally.
2. Schema-based extraction second. That intermediate output goes to an AI model along with a defined schema (the fields you want), and the model fills the schema from the recognized content, returning typed JSON so you do not parse free text yourself.

The reasoning for two steps: the layout step is good at recovering what is on the page and how it is organized, while the schema step is good at understanding what a piece of content means and mapping it to the field you need. Combining both in one step tends to give less consistent results.

A Worked Example: Schema In, Grounded Output Out

Take a simple invoice. You define a schema requesting vendor_name, invoice_date, and total_amount. A well-built extraction API returns the three values alongside where each one came from. Teams applying this to payables can see the wider workflow in DeepRead's guide to AI document processing for AP automation.

This two-part structure, extracted values in one place and source locations for each field in another, is common across independent implementations. It is the difference between "the model says the total is $1,240" and "the total is $1,240, and here is exactly where on the page it came from, so you can check it in two seconds."

Why Off-the-Shelf LLMs Hallucinate Fields, and What Grounding Fixes

A general-purpose language model generates its next token from learned patterns, not from a verified lookup against the source document. Ask it for a total, and it can produce a plausible number that appears nowhere in the document, especially when the field is absent or ambiguous, since the model would rather generate something plausible than signal "not found." Repeated runs on the same document can also drift, returning slightly different values or formatting, because generation involves some randomness by default. The wider trade-offs between language models and traditional OCR pipelines are covered in LLMs vs OCR software.

Grounding is the direct fix: constraining or verifying that every extracted value traces back to a location in the source document instead of trusting the model's raw output. That is why strong extraction APIs treat grounding as a core feature. It turns "trust the model" into "verify the model" and lets a reviewer confirm a flagged field in seconds.

Structured vs Freeform Extraction

This distinction changes which approach fits.

• Structured extraction pulls specific, known fields into a consistent schema. Use it when you know in advance what data you need, such as an invoice total, a patient's date of birth, or a line item.
• Freeform extraction pulls content when the target fields are not known ahead of time. Use it for a varied document set where you do not want a rigid schema, at the cost of less predictable output.

Some platforms offer both as separate endpoints so you can choose per use case.

Document Type Declaration: Auto-Detect or Explicit

Some extraction APIs let you declare the document type (invoice, receipt, form) so the system applies rules tuned to that category, which generally improves accuracy over a generic pass. Others offer an auto mode that identifies the type first, useful for a mixed batch where you do not want to classify documents yourself. If accuracy on a known, high-volume type matters most, declare it explicitly. Auto-detection trades a small accuracy cost for not building a classification step.

A Practical Approach: From Document to Structured JSON

1. Classify the document first if your input is mixed, or use an API's auto-detection mode.
2. Define your schema deliberately. Each field's description should say exactly what belongs there, since better descriptions give better matches. The same principle is covered in our JSON Schema for extraction guide.
3. Add instructions where a schema alone is ambiguous. Free-form guidance, disambiguation rules, formatting preferences, and domain context work like briefing a colleague doing the extraction by hand.
4. Choose structured or freeform mode based on whether your fields are known upfront.
5. Confirm grounding is returned with the output, not just the values, so you can build a verification step.
6. Decide where extraction runs. Some platforms support running the model locally or on-premises for documents that cannot leave your environment.

Named APIs and What They Do

Pricing and limits below come from each vendor's own pages where noted. Confirm current figures before you buy.

DeepRead

• What it automates: Implements the two-step pattern in one call. Extract reads the document into Markdown with layout blocks and bounding boxes, then fills the schema you define and returns JSON. Because you define the fields, one integration can cover invoices, contracts, forms, or anything else, instead of a vendor's fixed templates. Deep Extract adds two OCR engines, adjudication where they disagree, and a verification pass on every value.
• Pricing: $15 per 1,000 pages for Extract and $35 per 1,000 pages for Deep Extract, chosen per request. Free covers 2,000 pages a month with no card, Standard has no monthly page limit; and Enterprise is custom. A failed job costs nothing.
• Limits: Free allows 50 pages and 15 MB per document and 10 requests a minute. Standard allows 1,000 pages, 50 MB, and 100 requests a minute, with webhooks. Enterprise adds retention controls, PII redaction, bring-your-own model keys, EU and AU residency, and SSO. Processing defaults to US East, and there is no self-hosted option, which matters if you need documents to stay on premises.
• Best for: Developers who want schema-driven extraction with each value traceable to its place on the page.
• Pros: Every field returns its page, bounding box, and source text (with include_markers=true), and values inside tables, such as line-item cells, are located individually. Uncertain values come back marked needs_review with a review_reason, instead of passing silently. It does not return a numeric confidence score. Async jobs run on every plan.
• Cons: There is no self-hosting, so it does not fit strict on-premises requirements, and it does not provide approvals or downstream workflow.

Implementation details, request and response formats, and integration steps are in DeepRead's docs.

Reducto

• What it automates: Pulls structured fields from any document using a schema you define, so you do not write a custom parser per template. Every extracted value is grounded, with citations returning the page, bounding box, and source text.
• Pricing: Extract is listed at $20 per 1,000 pages, with parsing included at no extra charge, and Deep Extract at $40 per 1,000 pages. The Standard plan lists $150 in free usage.
• Limits: The pricing page does not state whether Deep Extract includes parsing, and it does not describe confidence scores. Check which plans include citations.
• Best for: Teams that want accurate fields fast, with an agentic option for the hardest documents.
• Pros: Deep Extract is an agent harness that extracts, verifies output against the source, and re-extracts until it meets a defined accuracy criterion, an iterative pattern beyond a single pass.
• Cons: Deep Extract costs twice the Extract rate.

Landing AI (Agentic Document Extraction)

• What it automates: Layout-agnostic parsing built for complex layouts without templates or training data upfront. It identifies text, tables, form fields, and checkboxes as distinct elements and keeps hierarchy, such as a caption linked to its image.
• Pricing: The Explore plan is pay as you go at $0.01 per credit with 1,000 free credits that expire after 90 days. Team starts at $250 a month for 25,000 to 200,000 credits, and Enterprise is custom. A typical business page uses about 1.5 credits, roughly $0.015 per page at list price.
• Limits: Credit use varies by model and document, so estimate on your own pages.
• Best for: Teams feeding RAG, search, and custom workflows who need exact page and coordinate references.
• Pros: Returns page and coordinate references for every extracted element and handles complex layouts without templates.
• Cons: Credit-based billing makes per-page cost harder to forecast.

Nutrient

• What it automates: Structured extraction in its SDK. You supply a JSON Schema and it fills the schema from the recognized content.
• Pricing: Not published on the pages reviewed. The vision data extraction feature must be included in your license.
• Limits: Source grounding is on by default and returns per-field page and bounding box with a match label. You can point it at a local OpenAI-compatible server so documents stay on your machine.
• Best for: Teams with strict data-residency needs who cannot send documents to a third-party cloud API.
• Pros: Per-field grounding by default and a local-model option.
• Cons: Licensing is needed for the vision data extraction feature, and you run and maintain the local model yourself.

Azure AI Document Intelligence with Azure OpenAI

• What it automates: A reference implementation of the two-step pattern. The layout model outputs the document as Markdown, preserving headings, tables, and reading order, and that Markdown goes to an Azure OpenAI request with instructions to return structured JSON.
• Pricing: Billed by Microsoft per page and per model. Check its pricing page, which varies by region and model.
• Limits: You assemble the two services and write the prompt and validation layer.
• Best for: Teams on Azure who want to understand and control the pattern step by step.
• Pros: Microsoft's Tech Community blog describes this exact pattern and links a public GitHub sample you can run.
• Cons: More assembly than a single extraction API, and grounding is yours to build.

Box AI Extract

• What it automates: Structured and freeform extraction as two separate API endpoints. The structured endpoint fills a predefined schema or Box metadata template, and the freeform endpoint handles cases where target fields are not known ahead of time.
• Pricing: Not reviewed. It depends on your Box plan.
• Limits: An Enhanced Extract Agent is available for long, complex documents. Orchestration, permission checks, and rate limiting are handled internally.
• Best for: Teams whose documents already live in Box.
• Pros: Two modes on one platform and no surrounding infrastructure to build.
• Cons: Tied to the Box platform.

What to Evaluate

• Architecture: whether the API uses two steps (layout parsing, then schema filling) or a single pass, since the former tends to be more consistent on complex, varied documents.
• Grounding: whether extracted values come with citations, not just the value. This makes output verifiable.
• Modes: structured and freeform availability, if your use case spans both known-schema and varied documents.
• Deployment: on-premises or local model options, if documents cannot leave your environment.
• Uncertainty signal: review flags with reasons, or another signal, so you route only uncertain fields to people instead of reviewing everything or nothing.
• Evidence on your documents: accuracy on documents that resemble yours, not a vendor's demo set. Ask any vendor for the method behind its numbers. DeepRead's October 2026 benchmark, for example, names its competitors and its test sets and states its scoring: Deep Extract averaged 92.0% and Extract 91.1%, against 89.9% for Extend Operator and 87.3% for Reducto Deep Extract. It is vendor-run and its scoring is lenient (exact match, match after normalization, or a reviewer model judging the difference immaterial), so use it as a signal and run your own sample.
• Real pricing at your volume: confirm directly instead of assuming from a headline rate. DeepRead's breakdown of per-document vs per-page pricing shows how the unit changes the total.

Conclusion

Structured data extraction is a different problem from OCR, because recovering text is only the first step. Returning exactly the fields you need, correctly typed and grounded to their source, is what makes extracted data usable in an application or a downstream AI pipeline. The two-step architecture and field-level grounding are the two mechanisms to check for in any API you evaluate, since together they separate trustworthy extraction from a model confidently returning a value with no way to verify it.

Frequently Asked Questions

What is the difference between OCR and structured data extraction?

OCR converts an image into searchable text but loses document structure, so there is no way to tell a header from a table from a paragraph. Structured data extraction goes further, understanding the structure well enough to return specific, typed fields, such as an invoice total or a date, instead of raw text.

What is field-level grounding in structured data extraction?

It is returning, alongside each extracted value, where that value came from in the source: a page number, coordinates, or another location. You can verify an extraction by checking the exact source instead of trusting the model's output.

Why do off-the-shelf LLMs hallucinate fields during extraction?

They generate output from learned patterns, not a verified lookup against the source, so a model can produce a plausible value that is not in the document, especially when a field is absent. Repeated runs can also drift. Grounding fixes this by verifying every value against a source location.

What is the difference between structured and freeform extraction?

Structured extraction pulls specific, predefined fields into a consistent schema and suits cases where you know what data you need. Freeform extraction pulls content when target fields are not known in advance, useful for varied documents at the cost of less predictable output.

Should I declare a document's type or let the API auto-detect it?

Explicit declaration generally gives better accuracy when you know the type and it is a high-volume category. Auto-detection suits mixed batches where building your own classification step is not worth the effort, at a small accuracy cost.

Is DeepRead a structured data extraction API?

Yes. DeepRead uses schema-driven extraction: Extract reads the document into Markdown with layout blocks and bounding boxes, then fills the schema you define and returns JSON with the page, bounding box, and source text for each field. Uncertain values are marked as needs_review with a review_reason, and it does not return a numeric confidence score.