From business PDFs to validated data

The invoice looks clear to a person: twelve service units, a credit adjustment and a total of EUR 1.089,00. Yet the file has a table split across two pages, a scanned delivery note and a number format that a careless parser may misread. Even perfect character recognition would not establish whether the purchase order authorized twelve units. Document extraction is a sequence of evidence and validation decisions.

Expand figure ↗

Choose the route page by page#

A born-digital PDF may contain useful text and positions. A scan may contain only pixels. A mixed PDF may require both paths. PyMuPDF’s extraction documentation explains that stored text order can differ from natural reading order; its OCR documentation describes creating a reusable text representation for image content. Do not OCR every page automatically when a reliable text layer already exists.

Docling is a candidate for structured conversion with layout, reading order, tables and OCR. Mistral’s hosted OCR and annotation documentation describe another processing option. These are tools to evaluate against the same documents, not interchangeable guarantees. Check the chosen release, licenses, model downloads, hardware, region and retention terms. A local executable may still download assets or make network requests unless you deliberately constrain it.

Route the example’s header and ordinary table text through a parser if they are reliable, then OCR the scanned delivery-note region only when needed. Detect failures explicitly: empty text, implausible character counts, overlapping boxes, suspicious reading order or missing expected structure. A route should be allowed to return “needs review” rather than forcing a confident result.

Treat the document as untrusted input#

Register an immutable input ID, a content hash and the authorized tenant before processing. Quarantine uploads, verify type and signature, and impose limits on bytes, pages, image dimensions, time and memory. Client MIME and filename extensions are insufficient. OWASP’s file-upload guidance supports layered validation, server-generated names and restricted storage; valid files can still exploit a parser or exhaust resources.

Run maintained parsers in a worker with minimal credentials and restricted outbound network. Define what happens to encryption, embedded attachments and unsupported formats. Avoid exposing raw storage paths to readers. Logs should retain failure categories and correlation IDs, not unrestricted document text. Apply retention and deletion to originals, OCR text, page previews and temporary files.

Recover structure before interpreting values#

A visible table can be positioned text and drawn lines rather than a spreadsheet. Reading characters left to right may merge headers into rows or move totals into the wrong column. Preserve words, blocks and coordinates while reconstructing structure. A repeated header on page two is not another invoice line, and a subtotal carried forward is not an additional charge.

In the schematic, page one has ten units at 80.00 and page two continues with two units at 80.00. Together they produce 960.00 before the credit. Keep an explicit continuation relationship rather than concatenating the pages and hoping the model recognizes it. Preserve negative signs and distinguish a credit adjustment from a positive charge. Reconciliation should expose a lost row or duplicated carry-forward total.

Separate shape, normalization and business truth#

A schema defines expected fields and allowed types. It can require a currency code and a decimal string; it cannot prove that the total was read correctly. Mistral’s annotation feature illustrates schema-oriented extraction, but every value still needs evidence and validation. Keep raw text separate from normalized values so a reviewer can undo an incorrect transformation.

{
  "exampleOnly": true,
  "invoiceId": "DEMO-1042",
  "currency": "EUR",
  "rawTotal": "1.089,00",
  "totalDecimal": "1089.00",
  "quantity": 12,
  "evidence": { "displayPage": 2, "region": "C" },
  "arithmeticCheck": "consistent",
  "purchaseOrderCheck": "quantity_exception",
  "paymentAuthorization": "not_granted"
}

This illustrative JSON is a target representation, not a measured extraction result. In a real schema, use explicit states for missing, illegible, conflicting and not-applicable fields. Do not substitute an invented tax identifier because a supplier name looks familiar. Validate dates and locale assumptions, use exact decimal arithmetic for money, and require evidence for consequential fields.

Business validators should compare the invoice to authorized supplier and purchase-order records: matching supplier, expected currency, remaining quantity, duplicate invoice ID within the appropriate scope, tax treatment and allowed state. The example’s arithmetic passes but its quantity does not. Route that exception to review; do not silently change the invoice to ten units or increase the purchase order.

Make every candidate traceable to the page#

Store document version, page index, coordinate system and bounding box with each evidence span. Declare whether internal pages are zero-based and display pages one-based. Record rotation and scaling so a highlight lands on the correct text after rendering. Region letters in this schematic are teaching labels; they are not actual parser coordinates.

Evidence can span multiple boxes or pages. The quantity of twelve comes from a relationship between the two table portions, while the delivery note provides a separate corroborating claim. Keep those paths distinct. A reviewer should see the relevant crop, raw extraction, normalized candidate and reason for an exception side by side. A source hash protects change detection, not the truth of the invoice.

Preserve corrections as new evidence#

A reviewer may determine that the second page is an authorized delivery or that it was attached to the wrong invoice. Record the correction, reviewer identity, time and reason in a new version. Preserve the original candidate and its source. Corrections should feed evaluation and controlled improvement, not silently mutate historical evidence used by an earlier decision.

Extraction review and payment authorization are different actions. Before posting, recheck current supplier status, purchase-order state, authorization and any required approval. Use idempotency and an operation receipt so retries cannot create duplicate financial effects. The document model should never grant payment authority because the invoice itself contains an instruction to pay.

Evaluate the difficult document families#

Build a held-out set stratified by supplier, language, scan quality, rotation, multi-page tables, credits and unfamiliar layouts. Measure field-level exact match after a stated normalization rule, row/column alignment, totals consistency, missing-value detection and evidence-location accuracy. Measure exception recall and reviewer correction time as well as per-page cost. A high mean accuracy can conceal failures on the largest amounts.

Include documents with no extractable answer, duplicate attachments, a missing page and a plausible but wrong total. Compare direct parsing, selective OCR and layout or vision routes on the same examples. Report actual measured results only after running the pipeline; the arithmetic and schematic here teach the evaluation target, not a vendor ranking.