Retyping documents is one of the most expensive routine activities in an office, measured against how little judgment it requires. An invoice arrives as a PDF, someone opens it, reads off the supplier, amount and line items, and types everything into the accounting software. This is exactly the kind of work language models have become good at. Good, however, does not mean flawless, and anyone taking the topic seriously should understand both sides: why it works far better today than earlier approaches, and where it still goes wrong.

Why templates used to be the bottleneck

Automatic document extraction has existed for decades under the acronym OCR. The classic approach worked like this: you define a template per supplier, encoding that the invoice total sits at the bottom right and the invoice number at the top left. This works as long as the supplier never changes their layout, and as long as you are willing to maintain a template for every new supplier. With three major suppliers, fine. With two hundred changing suppliers, template maintenance becomes a full-time job of its own.

Language models solve the problem differently. They read the document for meaning, the way a person who has never seen this supplier’s invoice still knows immediately where the total is. No template needed. Stated unspectacularly, that is the actual breakthrough of recent years: software now copes with layouts it has never seen.

And unfamiliar layouts remain the norm. According to a Bitkom survey (2024) of 1,103 German companies with 20 or more employees, 96 percent receive invoices by email and 93 percent still accept postal mail, but only 45 percent can process structured e-invoices, the format that would make extraction unnecessary. Everyone else reads values off a page. Or has software do it.

	Template-based OCR	Language model
New supplier	build and test a template	works without preparation
Layout change	template breaks, needs maintenance	not an issue
Ongoing effort	grows with every supplier	maintaining validation rules
Typical errors	field read from the wrong spot	plausible digit swaps, handwriting

What a modern extraction workflow actually does

The process we typically build has four stations. The document arrives, as an email attachment, scan or upload. The model reads it and returns structured data: supplier, date, invoice number, net amounts, tax rates, individual line items. Then comes the step that decides whether the whole thing is trustworthy: validation. Fixed, programmed rules check whether the line items add up to the total, whether the VAT ID has a valid format, whether the supplier exists in the master data, whether a matching purchase order is on file.

Only when these checks pass does the data move into the ERP or accounting system. If a check fails or the model reports uncertainty, the document lands in a review queue for a person, with the original and the extracted values side by side. Correcting then takes seconds instead of minutes, because nobody is retyping anymore, only comparing.

The honest list of failure cases

To set expectations properly: these are the cases that cause problems in practice.

Bad scans and phone photos: skewed, blurry, cut off. What a person struggles to decipher, the model also struggles with, and sometimes gets wrong.
Handwritten additions, such as a corrected amount in the margin. The model overlooks them or weighs them incorrectly.
Ambiguous line items: bundled positions, partial deliveries, credits on the same invoice. Here the problem is often not recognition but the business-side interpretation.
Plausible digit errors: if the model reads 1,580 instead of 1,850, no format check will notice. Only reconciliation against the purchase order or human review catches these.

Confidence: the most important dial

A well-built workflow does not treat all documents the same. It differentiates by certainty: a clean PDF from a known supplier with a matching purchase order can pass through automatically. A first-time supplier, an unusually high amount or a contradiction between extracted values always goes to a person. Where these thresholds sit is not a technical question but a business one, and it should be decided at the start of the project, not retrofitted.

Our rule of thumb: better to send too much to review at the beginning and loosen the thresholds after a few weeks of real data than the other way around. Trust in a workflow like this builds over weeks of traceable results, and a single error that slipped through silently destroys it.

Contracts are a different game than invoices

Invoices and delivery notes are structured documents with clear target fields. Contracts are not. There, the goal is usually not data transfer but questions like: what notice periods are in our thirty supplier contracts? Where do automatic renewals hide? A language model can find such clauses reliably and summarize them with the exact location, across an entire folder.

What it cannot do is the legal assessment. Whether a clause is enforceable, whether it applies in a specific case, whether you should rely on it: that stays with your lawyer. The sensible use is the groundwork, pulling the five relevant passages out of three hundred pages, with references, so that a person can read on precisely where it matters.

Data protection: where the documents get processed

Invoices contain business data; contracts often contain far more sensitive material. Before any document goes to a model, it needs to be settled where that model runs. The range spans APIs with a data processing agreement, EU cloud hosting, and models on your own hardware. Which route fits depends on the sensitivity of the documents and your own requirements; for most invoice workflows, a contractually clean API is enough, for contracts under confidentiality obligations it often is not.

What matters is that this decision is made at the start and documented. Discovering after the fact that two years of incoming invoices went through a service without a data processing agreement is an avoidable conversation with your data protection officer.