Document AI beyond invoices: contracts, forms, and the messy middle
Invoice extraction is the easy version of document AI: a bounded set of fields, a predictable structure per supplier, numbers that can be cross-checked against a total. Once teams have that working, the next request is almost always harder: read this contract and tell me the termination clause, read this intake form and route it to the right team, read this scanned letter and tell me what the customer is actually asking for. That's a different problem, and treating it like invoice extraction with a bigger prompt is where these projects go sideways.
Why unstructured documents are a different problem
An invoice has a total, a due date, and line items in roughly the same place every time for a given supplier. A contract might express the same clause in a dozen different ways depending on who drafted it, and the information you need is often implied across several paragraphs rather than sitting in one field. A scanned intake form might be handwritten, at an angle, with a coffee ring over the box you need to read. The model has to do genuine interpretation, not just pattern-matched extraction, and that changes what accuracy and verification look like.
It also changes what a wrong answer costs. An invoice extraction error usually shows up fast, the total doesn't reconcile and someone catches it. A contract misread might not surface for months, until the clause it got wrong actually matters, by which point the document has long since been filed away and trusted. That asymmetry, silent failure with delayed and expensive consequences, is exactly why unstructured document work needs a more conservative approach to verification than invoices ever did.
- Define what 'correct' means before you build: exact text extraction is different from a summarized interpretation, and they need different QA.
- Keep a human in the loop for anything with legal or financial consequence, the model drafts, a person confirms.
- Route by confidence, not just always or never: high-confidence extractions flow straight through, low-confidence ones queue for review.
- Version your prompts against a document set that includes the ugly scans, not just the clean PDFs.
OCR quality sets the ceiling before the model even sees the text
A mistake that's easy to miss: if a document is a scanned image rather than native text, optical character recognition happens before the model ever sees the content, and errors introduced at that stage propagate into everything downstream. A poorly scanned page, low resolution, skewed angle, a stamp partially covering text, can turn a clear clause into garbled characters, and the model will do its best to make sense of garbage, sometimes producing a fluent, wrong answer instead of flagging that the input itself was bad. Checking OCR confidence scores and routing low-confidence scans to a human before they even reach the model is a cheap step that prevents an entire class of downstream error.
Where this earns its keep
Intake triage is the clearest win: a form or email comes in, the model reads it, classifies the request, extracts the key fields, and routes it to the right queue with the fields pre-filled. Nobody's job is replaced, but the fifteen minutes someone used to spend reading and re-typing before the real work even starts disappears. Contract review works the same way at a smaller scale: flagging clauses that deviate from a standard template so a lawyer reviews the three unusual paragraphs instead of rereading the whole document every time.
Correspondence handling, scanned letters, faxed forms, mailed applications, is the least glamorous version of this and often the highest-value one, because it's usually the slowest, most manual step left in an otherwise digitized process. A team that's already automated its digital intake often still has a drawer of paper mail that gets typed in by hand once a week. That's frequently the single biggest remaining chunk of manual document work in the building, precisely because nobody thought to include it in the first automation pass.
The value isn't in reading the document instead of a person. It's in reading it fast enough that a person only looks at the part that actually needs judgment.
Keep the original document attached to every extraction
One habit that costs almost nothing to build in and saves enormous pain later: every extracted field should carry a pointer back to the exact page and, ideally, the exact region of the source document it came from. When someone questions an extracted answer six months later, and someone eventually will, being able to show the original clause or field in one click is the difference between a five-minute verification and an hour spent hunting through file storage trying to reconstruct what the system was looking at. This is especially important for anything that touches a dispute, an audit, or a legal question, where the source document, not the model's summary of it, is what actually matters if it's ever challenged.
Scope the confidence threshold, not just the feature
The question that matters before you build this isn't 'can the model read this document.' It's 'what happens when it's wrong, and how do we know.' Decide upfront what confidence threshold sends something to a human, and make that threshold visible and adjustable, not buried in a prompt. That single decision does more for whether this becomes a trusted tool or an abandoned experiment than any amount of prompt engineering, and it's worth revisiting every few months as the document set and the team's tolerance for review load both change.