Structured output (JSON extraction)

Structured output (JSON extraction) is the process of converting information from a document, whether scanned, photographed, or born digital, into a machine-readable format such as JSON that follows a defined schema. Instead of returning free text or a wall of OCR characters, the system returns fields like invoice_number, total_amount, or due_date with values already typed and organized. This makes the output directly usable by downstream systems (ERPs, CRMs, databases) without further parsing.

How it works

A structured output pipeline starts with a schema: a list of fields, their types (string, number, date, array), and sometimes validation rules (a SIRET must be 14 digits, a date must fall within a range). The document is fed into an extraction engine, historically OCR plus rule-based parsing, more recently a multimodal LLM that reads layout and text together.

The model or pipeline maps what it finds in the document to the schema, producing a JSON object rather than a transcript. Some systems enforce the schema strictly at generation time (constrained decoding, function-calling APIs), which prevents the model from returning malformed JSON or inventing extra fields. Others generate freely and validate afterward, rejecting or flagging outputs that do not conform.

Nested and repeating structures matter here. An invoice has line items, each with its own quantity, description, and price. A contract might have parties, clauses, and renewal terms as nested objects. A good extraction system handles these without flattening them into a single unreadable row.

Confidence scores are often attached per field, so a low-confidence total_amount can be routed for human review while high-confidence fields flow straight through. This is what separates a demo from a production system: the schema, the validation, and the routing logic around the raw extraction.

Why it matters for document processing

Free-text output from an LLM or OCR engine is not directly useful to a business system. Someone still has to parse it, which reintroduces the manual work automation was meant to remove. Structured output closes that gap: it is what lets an extracted invoice post directly into an accounting system, or an extracted KYC document populate a compliance record without a human retyping numbers.

It also makes automation auditable. A fixed schema means every extraction can be checked against validation rules, logged for an audit trail, and compared across documents for cross-document validation. Without structure, none of that is practical at scale.

The catch is that structure without accuracy is just neatly formatted wrong data. Schema conformance and factual correctness are separate problems, and a system that only solves the first one can be dangerous in something like insurance claims or contract analysis, where a wrong number in a valid-looking field goes unnoticed longer.

Related terms

• Schema inference
• Zero-shot extraction
• Confidence score
• Multimodal LLM
• Named Entity Recognition (NER)

FAQ

Is structured output the same as OCR?

No. OCR converts pixels to text; it has no notion of a schema or field meaning. Structured output takes that text (or the raw image, in newer systems) and maps specific pieces of it to named fields with defined types. You can have accurate OCR and still get no usable structured output if nothing maps the text to a schema.

How do I stop the model from hallucinating a value that isn't in the document?

Use constrained generation or function-calling APIs that force the model to draw only from provided context, add per-field confidence scores, and validate outputs against known formats (dates, tax IDs, currency). See LLM hallucination for a fuller discussion of why this happens and how validation rules catch it before it reaches a downstream system.