Structured Data Extraction: A Technical Guide

Structured data extraction is the process of converting unstructured or semi-structured documents, PDFs, scans, and images into predictable, schema-shaped data (typically JSON) that an application, database, or downstream AI pipeline can actually use, rather than a wall of unformatted text. This guide covers why OCR alone doesn't get you there, the architecture pattern most modern extraction APIs actually use, a concrete worked example, and named tools with real technical specifics.

Who This Is For

Developers building document extraction into an application or pipeline, deciding between raw OCR, a rules-based parser, or an AI-based extraction API.
Teams building RAG (retrieval-augmented generation), search, or analytics pipelines that depend on clean, structured input from documents rather than raw text dumps.
Engineers evaluating extraction APIs who want to understand what's actually happening architecturally, not just an accuracy percentage.

Why OCR Alone Isn't Structured Data Extraction

A document is more than a string of text. Headings, paragraphs, tables, and layout communicate information beyond the words themselves, and some content- letterhead, boilerplate, page numbers- is less valuable than the rest. With OCR alone, a scanned PDF becomes searchable text, but the structure is lost entirely: there's no way to tell a header from a table from a paragraph, and pulling out a specific value, an invoice total, a date of birth, a line item, still requires meaningful additional processing on top of the raw text.

This gap matters beyond a single document too: extracted data commonly feeds downstream applications like retrieval-augmented generation, search indexes, or analytics dashboards, and unstructured text with no field boundaries makes all of those meaningfully harder to build well. Structured extraction closes this gap, not just reading the document, but understanding its 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 multiple independent implementations, worth understanding as the default approach rather than something specific to one vendor:

Layout-aware parsing first. The document is processed by a layout model that preserves structure, headings, tables, and reading order, converting the document into a structured intermediate format (Markdown is a common choice specifically because it naturally represents headings, lists, and tables).
Schema-based extraction second. That structured intermediate output is then passed to an AI model along with a defined schema (the fields you actually want), and the model fills the schema from the recognized content, returning typed, structured JSON rather than requiring you to parse free text yourself.

The reasoning behind splitting this into two steps rather than one: the layout step is good at recovering what's on the page and how it's organized; the schema-filling step is good at understanding what a given piece of content means and mapping it to the field you actually need. Combining both in one step tends to produce less consistent results than doing them separately and well.

A Worked Example: Schema In, Grounded Output Out

To make this concrete rather than abstract, take a simple invoice extraction case. You define a schema requesting vendor_name, invoice_date, and total_amount. A well-built extraction API doesn't just return the three values; it returns them alongside where each one came from:

This two-node structure- extracted values in one place, source locations and grounding for each field in another- is a genuinely common pattern across independent implementations, not a hypothetical. It's what makes the difference between "the model says the total is $1,240" and "the total is $1,240, and here's exactly where on the page that came from, go check it yourself in two seconds."

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

Worth explaining the actual mechanism, not just naming the risk: a general-purpose language model generates its next output token based on learned patterns, not a verified lookup against the source document. Ask it to extract a total amount, and it can produce a plausible-looking number that isn't actually present anywhere in the document, especially when the requested field is genuinely absent or ambiguous, since the model would rather generate something plausible than clearly signal "not found." Repeated runs on the identical document can also drift, returning slightly different values or formatting across calls, since generation involves some degree of randomness by default.

Grounding is the direct fix: constraining or verifying that every extracted value traces back to an actual location in the source document, rather than trusting the model's raw output. This is why the strongest extraction APIs treat grounding as a core feature, not an optional add-on; it turns "trust the model" into "verify the model," letting a reviewer confirm a specific flagged field in seconds by checking the exact source location.

Structured vs. Freeform Extraction

Worth knowing this distinction exists, since it changes which approach fits your use case:

Structured extraction pulls specific, known fields into a consistent schema; use this when you know in advance exactly what data you need (an invoice total, a patient's date of birth, a specific line item).
Freeform extraction extracts content when the target fields aren't known ahead of time; use this when you're processing a genuinely varied document set and don't want to define a rigid schema upfront, at the cost of less predictable, less consistently structured output.

Some platforms offer both as separate API endpoints specifically so you can choose per use case rather than forcing every document through the same extraction mode.

Document Type Declaration: Auto-Detect or Explicit

Worth knowing as a practical API design choice you'll encounter: some extraction APIs let you explicitly declare the document type you're sending (invoice, receipt, form) so the system applies extraction rules tuned for that category specifically, generally improving accuracy over a generic pass.

Others offer an "auto" mode that attempts to identify the document type itself before applying the corresponding rules, useful when you're processing a genuinely mixed batch and don't want to classify documents yourself before calling the API. If accuracy on a known, high-volume document type matters more than convenience, explicit declaration is usually the better choice; auto-detection trades a small accuracy cost for not having to build a classification step yourself.

A Practical Approach: From Document to Structured JSON

Classify the document first if your input is mixed, or use an API's auto-detection mode if you'd rather not build that step yourself.
Define your schema deliberately. Each field's description should tell the extraction model exactly what belongs there; better descriptions produce better matches. The same principle is covered in more depth in our JSON Schema for extraction guide.
Add instructions where a schema alone is ambiguous. Free-form guidance, disambiguation rules, formatting preferences, domain-specific context, functions the same way as briefing a colleague doing the extraction by hand.
Choose structured or freeform mode based on whether your fields are actually known upfront.
Confirm grounding is returned with the output, not just the extracted values, so you can build a verification step rather than trusting output uncritically.
Decide where the extraction actually runs. Some platforms support running the underlying model locally or on-premises specifically for documents that can't leave your environment, relevant if data residency is a real requirement, not just a cloud API by default.

Named APIs and What They Actually Do

DeepRead

DeepRead implements the same underlying pattern this guide describes end to end, and it's the clearest example of that pattern in this comparison. Schema-driven extraction means you define exactly the fields you need, rather than being limited to a vendor's fixed, pre-trained document templates, so one integration can flex across invoices, contracts, forms, or anything else your application needs to pull structured data from.

Per-field confidence scoring built into every response. Every extracted value returns a confidence score alongside it, not just the value itself.
Uncertain values are flagged needs_review, not returned silently. This is functionally the same verification purpose that grounding serves elsewhere in this article, telling you specifically which fields need a human look rather than requiring you to check everything or trust everything equally.
Async processing and webhook delivery are built in by default, relevant for batch document volume rather than one-at-a-time synchronous calls.
A free tier that removes the barrier to testing: 2,000 documents a month, no credit card required, letting you validate the schema-driven approach against your own real documents before any commercial conversation.
Full implementation reference available directly: current API specifics, request/response formats, and integration details are documented in DeepRead's docs.

Reducto

Reducto pulls structured fields from any document using a schema you define, positioned specifically for teams needing accurate fields extracted fast without writing a custom parser per document template.

Every extracted value is grounded to the page it came from, with citations on each one included in the response.
States pricing starting at $20 per 1,000 pages, with no additional charge for the parsing step itself.
Offers an agent harness that extracts, verifies output against the source document, and re-extracts automatically until results meet a defined accuracy criteria, a genuinely distinct iterative-verification pattern beyond a single extraction pass.

Landing AI (Agentic Document Extraction / ADE)

Landing AI's ADE uses layout-agnostic parsing specifically built to handle complex layouts without requiring templates or training data upfront.

Identifies text, tables, form fields, and checkboxes as distinct elements, rather than returning flat, undifferentiated text.
Understands hierarchical relationships between elements, a caption correctly linked to its image, for instance, not just detected in isolation.
Returns exact page and coordinate references for every extracted element.
Explicitly positioned for feeding downstream RAG, search, and custom workflow applications, not just one-off document review.

Nutrient

Nutrient's structured extraction takes a JSON Schema you supply and fills it from the document's recognized content, with the same grounding principle applied consistently.

Reports per-field source locations and grounding labels for verification, matching the pattern described in the worked example above.
Supports configuring the AI provider directly, including a local, OpenAI-compatible server that keeps documents entirely on your own machine rather than sending them to a hosted provider.
Relevant specifically for teams with strict data-residency requirements who can't send documents to a third-party cloud API at all.

Azure AI Document Intelligence, paired with Azure OpenAI

This combination demonstrates the two-step architecture explicitly, and it's a genuinely useful reference implementation for understanding the pattern rather than taking it on faith.

Document Intelligence's layout model outputs the document as Markdown, preserving headings, tables, and reading order.
That Markdown is passed as context to an Azure OpenAI completion request with instructions to extract structured JSON.
A public code sample demonstrating this exact pattern is available directly from Microsoft, useful as a working reference rather than a conceptual description alone.

Box AI Extract

Box AI Extract offers structured and freeform extraction as two distinct API endpoints, letting you choose per use case rather than forcing every document through the same mode.

Structured extraction endpoint for known, predefined fields into a consistent schema or Box metadata template.
Freeform extraction endpoint for cases where target fields aren't known ahead of time.
An "enhanced extraction" mode is available for more complex cases at improved accuracy.
Handles orchestration, permission checks, and rate-limiting internally, so you don't need to build that surrounding infrastructure yourself.

What to Evaluate

Whether the API uses a two-step architecture (layout parsing, then schema-filling) or a single-pass approach, since the former tends to produce more consistent results on complex, varied documents.
Whether extracted values come with grounding or citations, not just the value itself, this is what makes output verifiable rather than something you have to trust blindly.
Structured vs. freeform mode availability, if your use case spans both known-schema documents and genuinely varied ones you can't predefine fields for.
On-premise or local model deployment options, if any of your documents can't leave your own environment for compliance or data-residency reasons.
Confidence scoring or an equivalent uncertainty signal, so you can route only genuinely uncertain fields to human review rather than reviewing everything or nothing.
Real accuracy on documents that resemble yours, not a vendor's demo set. DeepRead's benchmarks page is one example of what independently checkable accuracy reporting looks like, published methodology measured against named competitors on identical documents, worth using as a model for the kind of evidence to ask any vendor for, not just this one.
Real pricing at your expected volume, confirmed directly rather than assumed from a headline per-page rate.

Conclusion

Structured data extraction is a genuinely different problem than OCR, recovering text is only the first step; understanding structure well enough to return exactly the fields you need, correctly typed and grounded to their source, is what actually makes extracted data usable in an application or a downstream AI pipeline. The two-step architecture (layout-aware parsing, then schema-based extraction) and field-level grounding are the two mechanisms worth checking for specifically in any API you evaluate, since together they're what separate genuinely trustworthy structured extraction from a model confidently returning a value with no way to verify it.

FAQ

What's the difference between OCR and structured data extraction?

OCR converts an image into searchable text, but loses document structure entirely; there's no way to distinguish a header from a table from a paragraph. Structured data extraction goes further, understanding the document's structure well enough to return specific, typed fields (an invoice total, a date) rather than just raw text.

What is field-level grounding in structured data extraction?

It's the practice of returning, alongside each extracted value, exactly where that value came from in the source document: a page number, coordinates, or a specific location. This lets you verify an extraction is correct by checking the exact source, rather than trusting the model's output without a way to confirm it.

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

Because they generate output based on learned patterns rather than a verified lookup against the source document, a model can produce a plausible-looking value that isn't actually present, especially when a requested field is genuinely absent. Repeated runs can also drift due to some randomness in generation. Grounding fixes this by verifying every value against an actual source location.

What's the difference between structured and freeform extraction?

Structured extraction pulls specific, predefined fields into a consistent schema, used when you know exactly what data you need. Freeform extraction extracts content when target fields aren't known in advance, useful for genuinely varied documents at the cost of less predictable output structure.

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

Explicit declaration generally produces better accuracy when you know the document type in advance, and it's a high-volume, known category. Auto-detection is useful for genuinely mixed document batches where building your own classification step isn't worth the effort, at a small accuracy tradeoff.

Is DeepRead a structured data extraction API?

Yes, DeepRead uses schema-driven extraction where you define the fields you need, returning structured JSON with per-field confidence scoring, and flags uncertain values as needs_review rather than returning them silently, functionally similar to the grounding/citation mechanism other extraction APIs use for verification.