Document processing done right
Uploading a PDF to an LLM takes seconds. Building a document process that is reliable, cost efficient and auditable is a completely different job.
Uploading a PDF to an LLM takes seconds. Building a document process that is reliable, cost efficient and auditable is a completely different job.
Most people think document processing is simply uploading a PDF to an LLM. Below is the same file, run twice: once through a single model call, and once through a staged pipeline, with what actually happens at every step.
| Single model call | Staged pipeline | |
|---|---|---|
| Cost per document | Every page sent as text and as an image, whether or not the images add anything | Cheap steps filter first, the model only sees what actually needs interpretation |
| Build effort | An afternoon | Weeks, and the business rules have to be written down |
| Hallucination | Nothing compares the output against the source | Values must be findable in the source, totals must add up |
| Failure mode | A confident wrong value that looks exactly like a right one | A flagged field with a source reference next to it |
| Auditability | The prompt and the answer | Source location, method, version and validation status per field |
| At volume | Cost scales linearly, accuracy does not improve | Smart routing, caching and deterministic methods make this much cheaper |
The single call is genuinely the right choice for low volume, low stakes, or a first prototype. It stops being the right choice at the point where somebody has to explain a result, or where the monthly bill starts to matter. Anthropic's own numbers make the second part concrete. Send a PDF as a PDF and every page is converted into an image and passed to the model alongside the extracted text; there is no text-only setting. The same three page file costs about 1'000 tokens as extracted text and about 7'000 tokens sent whole, seven times the bill for one document.source
First decide what belongs to the case
Documents do not arrive as documents. They arrive as email attachments, portal uploads, API payloads, scanned mail and files pulled from existing systems. One incoming case might contain three attachments, one of which is a 40 page PDF holding a cover letter, an invoice and a report, plus a duplicate of something submitted last week and a password protected file nobody can open.
The system needs to know what it is holding. Is this really a PDF, or an image in a PDF container? Is there a clean text layer, or is the file partly scanned and partly digital? Has this exact file been submitted before? None of these checks involve a model, and every one of them determines what the next step costs.
Classification turns extraction into a business process
Extraction without classification produces generic data. Classification is what turns generic data into specific obligations. An invoice needs invoice number, date, net, VAT and total; the amounts have to add up and the invoice number must not have been seen before. A claim notification needs a policy number, an incident date, the parties involved and the incident has to fall inside the policy period. Same pipeline, entirely different obligations.
So the required fields, the validation rules and the next action in the business process all follow from the document type, not from the model. Get the type wrong and every later step is answering the wrong question.
Use the simplest reliable method
The goal is not to use the most powerful model everywhere. It is to use the cheapest reliable method for each step.
| Layer | Use it for | Cost | How you verify the result |
|---|---|---|---|
| Deterministic rules | Metadata, text layers, IBAN and date checks, totals, duplicate hashes | Negligible | The rule is the check |
| Traditional extraction and OCR | Scans, known form layouts, table structures | Low | Reproducible output, confidence per token |
| Language or vision model | Unstructured text, unusual layouts, information spread across pages | High | Source references plus downstream validation |
| Human review | Ambiguity, conflicts, high value exceptions | Highest per case | A person signs off |
Cost rises down that table, and so does the effort required to prove the answer is right. That is not a coincidence, and it is the reason cheap and reliable usually point in the same direction here.
A well designed pipeline does not ask "can an LLM do this?" It asks "what is the simplest reliable method for this step?"
In practice: do not send page images when the text is already selectable. Reduce context before the model call, so a 200 page contract becomes four relevant clauses. Use a small model for language detection and simple classification, and save the large one for ambiguity and conflict. Cache OCR output, extracted text and page classifications so nothing is processed twice. Stop as soon as confidence is sufficient.
Compare, then validate
Extraction answers what the document appears to say. The first question after that is not whether a value is correct, but whether the values you need are there at all. Comparison answers that: the document type fixes a list of required fields, and the case already carries data of its own. A motor claim without a policy number is incomplete no matter how well it was read.
Validation is the step after that, and it asks whether the values that are present hold up on their own. An invoice shows a subtotal of CHF 1'000, VAT of CHF 81 and a total of CHF 1'200: the VAT is the correct 8.1%, every field is extracted perfectly, and the arithmetic is still wrong. One check is different in kind and worth as much as the rest combined: can the extracted string actually be found in the source text? It costs almost nothing and removes a whole class of hallucination.
Every result needs a trail
Keep the original document, the structured result, source locations, the method and model version used, validation results, human corrections and the routing decision.
One question decides whether a system is ready for production: can someone reconstruct later why it produced this result? That question comes up in audits, in customer complaints, in regulatory reviews and every single time you change a model.
How we approach this at Voviva
We build document pipelines for insurers, banks and the public sector in the DACH region. Regulated settings where the data is sensitive, the pipeline has to run on premises or in the customer's own cloud, and every result has to be defensible later.
A good document AI system does not simply read documents. It selects the right processing method, extracts only what is needed, validates the result against business rules and routes it to the next step in the process.
