Reliable document extraction starts with a field schema and evidence rule. Preserve page or region references, distinguish printed values from inferred values, validate types and relationships in code, and review low-quality or ambiguous documents. AI can draft records, but it should not silently create missing data.
Who this is for: Operations, finance, research, and technical teams converting semi-structured documents into reviewable data.
- Define each field's meaning and allowed missing-value behavior before processing documents.
- Retain evidence locations so reviewers can inspect values without rereading the whole file.
- Validate table structure, arithmetic, and cross-field rules outside the model.
Specify fields and provenance
Write a data dictionary containing field name, description, type, format, required status, and source rule. Distinguish invoice_date from payment_due_date and printed_total from calculated_total. If the source omits a value, decide whether the output should be null, rejected, or manually supplied.
Add provenance fields such as page, table title, row label, bounding region, or quoted text. Evidence coordinates are essential when similar values appear several times. They also let reviewers find a value quickly and help diagnose whether a mistake came from image reading, table reconstruction, or semantic interpretation.
Prepare difficult documents
Inspect scan quality, rotation, handwriting, columns, merged cells, repeating headers, and footnotes before batch processing. A table that looks simple visually may become scrambled when converted to plain text. Use a document-capable model or extraction tool suited to the source and check current official format guidance.
Split document types when layouts differ materially. A utility bill, laboratory report, and purchase order should not share one giant schema merely because each contains dates and totals. Route password-protected, corrupted, or unreadable files to an explicit failure path rather than treating empty extraction as an empty document.
Extract rows without losing structure
For tables, define what creates a row and how multi-line cells, subtotal rows, units, and repeated headers should be handled. Request one structured record per logical row with its source location. Preserve raw text beside normalized values when normalization could change meaning, such as percentages, ranges, or identifiers with leading zeros.
Do not ask the model to infer missing rows or complete a sequence unless that inference is a separately approved task. A blank cell differs from zero. A dash may mean none, not applicable, or unavailable depending on the legend. Capture the visible mark and interpretation status when ambiguity matters.
Validate and sample the output
Run schema validation, type checks, allowed-value checks, and arithmetic reconciliation. Compare stated totals with extracted line items without overwriting either. Detect duplicate document IDs and impossible dates. Use confidence or warning labels only as routing aids; calibrate them against actual errors before setting thresholds.
Review every record during initial development, then establish risk-based sampling only after measuring performance by document type and field. Keep a separate queue for low-quality images, missing required evidence, and validation failures. Changes to models or layouts require a fresh test on known examples.
Extract a shipment packing table
Warehouse PDFs list carton number, item code, quantity, unit weight, and exceptions across variable multi-page tables.
- Define field types, preserve leading zeros in item codes, and require page plus row evidence.
- Identify table headers and state that repeated page headers are not shipment rows.
- Extract one JSON record per carton-item pair while keeping blank quantity distinct from zero.
- Validate positive quantities, allowed units, duplicate carton-item pairs, and stated weight totals.
- Send records with merged cells, unreadable scans, or failed reconciliation to a warehouse reviewer.
Document extraction specification
Complete this specification for each document family before automating a batch.
- Document family: expected layouts, languages, scan conditions, and explicit unsupported cases.
- Field dictionary: name, meaning, type, format, required status, normalization, and null rule.
- Table rules: logical row, header treatment, merged cells, subtotals, units, blanks, and footnotes.
- Evidence contract: page, region, row label, raw value, and reviewer display requirements.
- Validation plan: schema, arithmetic, duplicates, ranges, sample rate, and exception ownership.
Common mistakes
- Converting every blank table cell to zero without consulting the document legend.
- Normalizing identifiers into numbers and accidentally removing meaningful leading zeros.
- Reporting overall extraction accuracy while hiding failures on one critical field or layout.
Try one
A scanned report shows '1O0' in a quantity cell, and the model returns 100. What should a responsible extraction pipeline store and do?
It should preserve the visible raw value and evidence location, mark the normalized value as uncertain, and route the field for review unless another authoritative rule establishes the intended character. A strong answer does not silently accept a plausible correction. Evaluation should mention image ambiguity, provenance, and a validation or reviewer step before downstream use.
Sources
- Gemini API document processing guideOfficial guidance for understanding PDF documents and their visual elements.
- OpenAI structured outputs guideOfficial guidance for producing responses that conform to a JSON schema.