Document processing: contracts, forms and the extraction trap
AI reads documents well and extracts fields confidently, including wrong ones. How to build extraction that can be trusted, and where a person stays.
The short answer
Document processing is turning documents that arrive as PDFs, scans and photos into structured fields your systems can use: who, when, how much, which terms, which answers. AI models do this well, quickly and cheaply. They also do it wrong occasionally, with exactly the same confidence as when they are right. That is the extraction trap: a fluent, plausible value that nobody checked because it looked right.
Built properly, extraction is one of the highest-return automations available. Built naively, it puts wrong numbers into your systems faster than any human could.
Design by document type and by field
| Document type | Fields | Automatic check | Goes to a person when |
|---|---|---|---|
| Standard forms (applications, intake) | Name, contact details, choices, dates | Format rules, required fields, plausible dates | Low confidence, missing required fields |
| Invoices and receipts | Supplier, number, amounts, dates, bank details | Lines sum to total, supplier in master data, no duplicate | Mismatch, changed bank details, unknown supplier |
| Identity and compliance documents | Names, numbers, expiry | Format and checksum rules, expiry in the future | Anything below a high confidence threshold |
| Contracts | Parties, term, notice period, key clauses | Compare against your standard terms | Always, for the decision; extraction prepares |
| Correspondence | Sender, subject, request, deadline | Category confidence | Ambiguous category, complaints, legal |
The four defences
- Cross-checks between fields. Lines that sum to the total. A due date after the issue date. A postcode that matches the city. Cheap, and they catch most misreads.
- Reference data. Supplier details against your master data. Customer numbers against your CRM. A value that does not exist in your systems is flagged, not created.
- Confidence thresholds per field. The model reports how sure it is. Below the threshold, a person looks. Thresholds are stricter for money and identity than for a subject line.
- Sampling. Even for fields that pass every check, a person reviews a random sample weekly. The error rate they find tunes the thresholds.
Where to start
Pick a document type that arrives often and has a clear structure: invoices, standard intake forms, order confirmations. High volume makes the return visible; clear structure makes the extraction reliable; simple validation rules make it safe. Contracts and free-form correspondence come later, with extraction preparing and a person deciding.
What this means for you
If documents are typed into systems by hand, extraction can remove most of that work, provided every field has a check that matches what a mistake would cost. Start with the frequent, structured document type, build the four defences in from the first day, and keep a person on anything that decides money, identity or commitments. The trap is real, and it is entirely avoidable.
Frequently asked questions
How accurate is document extraction?
Good on clean, structured documents such as typed forms and standard invoices; less so on poor scans, handwriting and unusual layouts. The design assumes errors happen and catches them: cross-checks between fields, plausibility rules, confidence thresholds, human review for what matters.
Can it read contracts?
It can find parties, dates, terms and specific clauses, and summarise. It cannot be the last word on what a clause means. Use it to prepare: extract, highlight, compare against your standard terms, and hand the result to the person who decides. That saves most of the reading time without delegating the judgement.
What about handwritten or scanned documents?
Scans of typed documents work well; handwriting works sometimes. The process should measure confidence per field and route low-confidence reads to a person rather than guessing. A clear photo from a phone is usually fine.