How to Extract Structured Data from Documents with LLMs
Document extraction has traditionally been one of the hardest automation problems because documents vary enormously in format, layout, and language. An invoice from one vendor looks nothing like an invoice from another. A resume in PDF format has different structure than one in Word format. A contract drafted by one law firm uses different clause numbering than one from another firm. Rule-based extraction systems require custom templates for each format, and they break when the format changes. OCR plus regex is fragile and maintenance-intensive. LLMs with structured output bypass these problems entirely because they understand the content semantically rather than relying on positional or format rules.
Define the Extraction Schema
Start with the fields your downstream system needs. For an invoice extraction, this might include vendor name, invoice number, date, line items (an array of objects with description, quantity, unit price, and total), subtotal, tax, and total amount. For a resume, this might include candidate name, email, phone, education (array), work experience (array of objects with company, title, dates, description), and skills (array of strings).
The critical design decision is how to handle missing information. Not every invoice has a tax line. Not every resume has a phone number. Use nullable types for fields that may be absent: {"anyOf": [{"type": "string"}, {"type": "null"}]}. This tells the model to return null when the information is not present, rather than inventing a value or leaving the field out. The difference between null (information not found) and an empty string (information found but empty) matters for downstream processing.
For arrays of extracted items, include a minimum of relevant fields per item. A line item on an invoice needs at least description and amount. A work experience entry needs at least company and title. Optional fields within array items (like dates or detailed descriptions) should also be nullable. This design produces consistent records where the essential fields are always present and supplementary fields are present when the document includes them.
Keep the schema focused on what you need. A schema with 50 fields will produce lower-quality extractions than a schema with 15 fields, because the model's attention is spread across more targets. If you need 50 fields, consider splitting the extraction into multiple passes with different schemas, each focused on a subset of the data. This also helps with context window management for long documents.
Prepare the Document for the Model
The model needs the document content in a format it can process. For text-based documents (plain text, HTML, Markdown), pass the content directly. For PDFs with embedded text, extract the text first using a PDF library. For scanned documents or images, use a vision-capable model (GPT-4o, Claude Sonnet with vision, Gemini) and pass the image directly, or use OCR first and pass the resulting text.
Long documents that exceed the model's context window need chunking. The simplest approach is page-based chunking: split the document into pages and extract from each page separately, then merge the results. This works well for documents where the data you need is concentrated on specific pages (invoices, forms). For documents where data spans multiple pages (contracts, reports), use overlapping chunks with deduplication logic to handle data that appears in the overlap region.
For very long documents (100+ pages), consider a two-pass approach. First pass: use a cheaper, faster model to identify which pages contain the data you need (a classification task). Second pass: send only the relevant pages to a more capable model for detailed extraction. This reduces cost and improves accuracy by focusing the extraction model's attention on the relevant content.
Document preprocessing also includes cleaning: removing headers, footers, page numbers, and watermarks that add noise without useful content. Removing these elements reduces token count and improves extraction accuracy by giving the model cleaner input.
Send the Document with the Schema
The prompt structure for extraction is straightforward: a system message that defines the extraction task, the document content in the user message, and the schema as the structured output format. The system message should include explicit instructions about handling edge cases:
"Extract the requested information from the provided document. Return null for any field whose value is not explicitly stated in the document. Do not infer, guess, or make up values. If a field could have multiple values, return the most specific one. For dates, use ISO 8601 format (YYYY-MM-DD). For currency amounts, return numeric values without currency symbols."
These instructions prevent the most common extraction errors: hallucinated values for missing fields, ambiguous date formats, and currency formatting inconsistencies. The more specific your instructions, the more consistent the extractions across different documents.
For multi-language documents, add a language instruction: "Extract data in English regardless of the document's language. Translate field values to English if needed." This produces consistent output even when your input documents come in different languages.
Validate and Post-Process
After extraction, run the response through your validation layer. Common post-processing steps include:
Date normalization: Even with ISO format instructions, the model occasionally returns dates in other formats. Parse and normalize all dates to your application's standard format.
Currency normalization: Convert all monetary values to a standard precision (2 decimal places for most currencies) and verify that line item totals sum to the document total. Discrepancies indicate extraction errors that may need retry or manual review.
Deduplication: If you extracted from multiple chunks, merge the results and remove duplicate entries. This is especially important for arrays of items where the same item might appear in overlapping chunks.
Cross-reference validation: Verify extracted data against known reference data. Does the vendor name match a known vendor in your system? Does the invoice number follow the expected pattern? Does the total match the sum of line items? These checks catch extraction errors that schema validation alone cannot detect.
Confidence assessment: Add a confidence field to your schema where the model rates its extraction confidence. Low-confidence extractions can be routed to human review. This is particularly useful for handwritten documents, poor-quality scans, or documents in unusual formats.
Common Document Types
Invoices: Extract vendor, invoice number, date, line items, and totals. Validate that line items sum to the total. Handle multi-page invoices by processing each page and merging line items. This is the most mature extraction use case, with well-established schemas and high accuracy rates.
Contracts: Extract parties, effective date, term length, key terms, and specific clauses. Contracts are challenging because important terms can be scattered across many pages. Use the two-pass approach: identify relevant sections first, then extract from those sections. The entity extraction pillar covers the underlying techniques.
Resumes: Extract contact information, education, experience, and skills. Handle varied formats (chronological, functional, combination) by using a flexible schema that does not assume a specific order. This is a high-volume use case where structured output replaces expensive manual data entry.
Medical records: Extract patient information, diagnoses, medications, lab results, and procedures. This requires careful handling of medical terminology and abbreviations. Use a model that has strong medical knowledge (larger frontier models) and validate extracted codes against medical coding standards (ICD-10, CPT).
Financial reports: Extract key metrics, revenue figures, dates, and notable items. Financial documents often have complex table structures that benefit from vision models over text extraction, because the spatial layout of tables carries meaning that is lost in text-only representations.
Production Pipeline Architecture
A production extraction pipeline has several stages beyond the model call itself. Document ingestion handles file uploads, format detection, and text/image extraction. Preprocessing cleans and chunks the document. The extraction stage calls the model with the schema. Validation checks the extraction against business rules. Post-processing normalizes and enriches the data. Storage writes the structured data to your database or data warehouse. Monitoring tracks extraction quality, failure rates, and processing times.
For high-volume systems (thousands of documents per day), batch processing reduces cost by using batch API endpoints that offer discounted pricing. The trade-off is higher latency, typically 24-hour turnaround, which is acceptable for back-office document processing but not for real-time applications. The AI cost optimization pillar covers batch processing economics in detail.
Document extraction with structured output replaces custom parsers, regex, and template matching with a single model call that returns typed data matching your schema. Design schemas with nullable fields for missing information, chunk long documents, validate extractions against business rules, and route low-confidence results to human review. The result is an extraction pipeline that handles format variation automatically.