From Documents to Structured Data: Anatomy of a Production Pipeline

"Can't we just send the PDF to ChatGPT?" You can. It will even work — on the first document, in a demo. This article is about what it takes for the same idea to work on document number 14,000, on a Tuesday, unattended, feeding numbers into a real financial system. That gap is an architecture, and it looks the same in every successful deployment I've seen or built.

The problem, honestly stated

Documents arrive scanned, skewed, photographed, and in forty different layouts from forty different senders. Fields move around. Some suppliers put the invoice number where others put the customer reference. Amounts appear with and without VAT, in different currencies and formats. A human absorbs this chaos without noticing. A naive "LLM reads PDF" script does not — it just fails confidently, which is worse than failing loudly.

The pipeline, stage by stage

1. Intake

One entry point, no exceptions: a monitored inbox, an upload endpoint, a scanner folder. Every document gets an ID and a stored original the moment it arrives, because six months from now someone will ask "where did this number come from?" and the answer must be one click, not an archaeology project.

2. Parse & OCR

Before any AI sees the document, it gets normalized: pages rotated, text extracted with layout preserved, scans OCR'd. Layout matters enormously — an amount means something different in the line-items table than in the totals box, and a parser that flattens the document into a text blob throws that signal away.

3. Extraction against a schema

The model never gets to answer freely. It fills a strict JSON schema — every field typed, enumerations closed, formats pinned. If the schema says currencyis one of DKK/EUR/USD, the model cannot invent "Danish crowns." Structured output turns a creative writer into a data-entry clerk, which is exactly what you want here.

4. Validation: rules first, model second

Everything checkable gets checked with plain code, not AI: do the line items sum to the total? Is the VAT rate one that exists in this country? Is the date plausible? Does the supplier exist in the vendor registry? Deterministic rules catch a large share of model mistakes for free — and every rule that passes raises justified confidence in the fields you can't check mechanically.

5. The confidence split

Each extraction gets a confidence assessment from the model's own signals plus the validation results. High-confidence documents flow straight through. Everything else lands in a review queue where a human sees the original document and the extracted fields side by side, and fixes what's wrong in seconds. This single design decision is what makes the system deployable in week one instead of "when it's perfect" — which is never.

6. Delivery and the audit trail

The result posts to the real system — ERP, accounting platform, database — via API where one exists. Every document keeps its full history: original file, extracted values, validation results, who approved it, what was corrected. In finance workflows this isn't a nice-to-have; it's the difference between a tool the auditor accepts and one they don't.

The part everyone skips: measurement

Here is the uncomfortable truth about extraction pipelines: you cannot know your accuracy without building the machinery to measure it. The corrections humans make in the review queue are that machinery — each one is a labeled test case. Feed them back into an evaluation set, run it on every prompt or model change, and "did the update break anything?" becomes a number instead of a feeling.

A concrete example

A pattern from my own work: an accounting firm ran bank/supplier reconciliation in a spreadsheet — a senior accountant matching statement lines against supplier documents by hand. We replaced it with a web app that parses the incoming documents, proposes matches, and queues only the uncertain ones for review. The accountant went from doing the matching to approving it. Same person, same responsibility, a fraction of the hours — and every match traceable back to its source documents.

That is what "documents to structured data" means in practice. Not magic. A pipeline — with the model as one stage in it, and measurement wrapped around all of it.