AI Document Processing: How to Automate Invoices, Contracts, and Forms

AI document processing automates the extraction of structured data from invoices, contracts, and forms by pairing a document parser with a language model that reads layouts it has never seen before. It is the most-bought enterprise AI workflow because the ROI arithmetic is unusually clean: a defined stack of paper, a measurable per-document cost today, and a system that typically posts 70–85% of documents straight through at roughly $0.10–0.60 each. The part buyers get wrong is accuracy. A vendor quoting "95% accuracy" on a twelve-field invoice is describing a system where only about half of documents come out fully correct.

The gap between extraction approaches is real and measurable. According to Yashwant et al., 2025, an LLM-based extractor achieved 94% overall accuracy on a benchmark of 102 digitally born and scanned invoices, compared with 63% for a layout-and-OCR pipeline on the same set. That is the case for LLMs in one number – and, read carefully, also the case for why raw model output alone never ships to accounts payable.

OCR, IDP, or LLM extraction – which should you use?

These are not competitors so much as layers, but they have genuinely different economics and failure modes. Here is how they compare on the four dimensions that decide procurement:

The pattern in production is almost always the fourth row. A parser handles text, tables, and page geometry; the model handles the interpretive work – which of four numbers is the grand total, whether this clause is an auto-renewal, what a handwritten "n/a" in a form field means; and deterministic rules decide whether the answer is allowed to post.

Where do LLMs beat traditional OCR, and where do they lose?

LLMs win decisively on format variety. If you receive invoices from 400 vendors in 300 layouts, template-based OCR needs 300 templates and a maintenance burden that grows every time someone redesigns a header. A schema-driven model handles all 300 without being told what any of them look like. They also win on semantic fields that have no fixed position at all: payment terms buried in a paragraph, a governing-law clause, a termination notice period, the difference between a discount and a credit memo.

They lose on three things. First, deterministic repeatability – the same document can produce slightly different output across runs unless you pin the model version, set temperature to zero, and freeze the prompt, and even then a model upgrade can shift behavior. Second, per-page cost at extreme volume: at ten million pages a month, a trained OCR pipeline is an order of magnitude cheaper and that difference is real money. Third, silent failure. Traditional OCR returns garbage characters when it fails, which is obvious. A language model returns a confident, well-formatted, plausible number that is wrong – which is why validation, not accuracy, is the real engineering problem. Our guide to reducing AI hallucinations covers the grounding techniques that apply directly here.

Why isn't 95% accuracy good enough for finance?

Because per-field accuracy compounds and finance cares about documents, not fields. A standard invoice schema has roughly twelve extracted fields: vendor, vendor ID, invoice number, invoice date, due date, PO number, currency, subtotal, tax, total, remit-to account, and line items. If each field is independently 95% accurate, the chance that all twelve are correct is 0.95 to the twelfth power – about 54%. Nearly half of your invoices contain at least one error.

Push per-field accuracy to 99% and document-level accuracy rises to about 89%. At 99.5% per field you reach roughly 94% clean documents. That curve is why the useful target is never a single accuracy percentage. Define three separate numbers instead: straight-through processing rate (what share posts with no human touch), escaped error rate (what share posts wrong – the number that should be near zero on monetary fields), and review load (what share hits the queue). A system at 75% straight-through with a near-zero escaped error rate is far more valuable than one claiming 97% accuracy with no idea which 3% is wrong.

How do confidence thresholds and review queues work?

Human-in-the-loop review is the architecture, not an admission of defeat. Every extracted document carries a confidence signal per field, and a threshold decides its route: clear the bar and the document posts automatically; fall below it and the document lands in a review queue.

The trap is trusting the model's own self-reported confidence, which is poorly calibrated – models are often most confident exactly when hallucinating a plausible number. Better signals, in rough order of usefulness: agreement between two independent extraction passes or two different models; whether the value survives arithmetic validation; whether it matches a record in your system of record; and token-level probabilities where the API exposes them. Combine these into a single routing score and tune the threshold against a labeled set until escaped errors on monetary fields hit zero.

Design the queue around reviewer speed. The document image should render beside the extracted fields with low-confidence values highlighted and the cursor already in the first one. Target 30–60 seconds per document. Every correction is labeled training data – feed it back into few-shot examples, schema descriptions, and threshold tuning, and expect straight-through rate to climb 10–20 points over the first quarter of real traffic.

How do you get reliable structured output?

Never ask a model to "extract the invoice data." Define an explicit schema – JSON Schema, a function/tool definition, or a structured-output constraint – with a typed field for every value you need, and make the model fill it. Four rules carry most of the quality:

Type everything strictly. Dates as ISO 8601, amounts as decimal strings with a separate currency code, identifiers as strings so leading zeros survive. Numeric fields typed as floats invite rounding artifacts on money.

Make null a first-class answer. Every optional field needs an explicit nullable type and a description saying to return null rather than guess. Most fabricated values come from schemas that leave the model no legal way to say "not present."

Ask for provenance. Have the model return the page number and the verbatim source text alongside each value. This makes review dramatically faster and turns unverifiable output into something auditable.

Write field descriptions like spec, not labels. "total" is ambiguous on a document showing subtotal, tax, shipping, prior balance, and amount due. "The final amount payable for this invoice including tax and shipping, excluding any prior balance" is not.

How do you handle scanned, handwritten, and multi-page documents?

Scanned and photographed documents are where accuracy quietly collapses, and the fix is mostly upstream. Normalize before extraction: deskew, correct rotation, and target 300 DPI – low-resolution faxes and phone photos taken at an angle are the single biggest driver of field errors we see. Handwriting is the honest limitation: modern vision models read printed and neatly hand-printed text well but degrade sharply on cursive, and any handwritten monetary field should route to review by policy rather than by confidence score.

Multi-page documents need a classification step before extraction. A forty-page contract or a mail batch containing three unrelated documents must first be split and labeled by page type, then routed to the right schema. Line-item tables that span pages need explicit continuation handling – extract per page, then merge, and validate that merged line items sum to the stated subtotal. For long contracts, retrieve the relevant sections rather than pushing the whole document into context on every question; our guide to preparing data for AI covers the ingestion and chunking work this depends on.

How do you validate extractions against source systems?

Deterministic validation catches more real errors than any confidence score, and it is cheap. The checks that earn their keep on invoices: line items sum to subtotal, subtotal plus tax plus shipping equals total, vendor name and tax ID resolve to a record in your vendor master, invoice number is not a duplicate for that vendor, the PO exists and has remaining balance, currency matches the vendor's configured currency, and dates fall in a plausible range. Contracts get their own set: counterparty matches a known entity, effective date precedes expiration, renewal terms are internally consistent.

Three-way matching against the purchase order and goods receipt is the strongest control available, and it is deterministic – the model proposes, your ERP disposes. Anything that fails validation routes to review regardless of confidence. Log every check result, because the failure distribution tells you exactly which schema field or prompt to fix next.

What does it actually cost, per document and to build?

Per document: model inference for a one-to-three-page invoice runs about $0.005–0.05, higher if you send page images rather than parsed text, and materially higher for long contracts. Storage, orchestration, and retries add a fraction of a cent. Human review dominates the rest – at a 20% review rate, 60 seconds per document, and a $30 fully loaded hourly rate, that is $0.10 per document averaged across total volume. Most production workflows land at $0.10–0.60 all in. Measure your own manual baseline first: total AP or intake team cost divided by annual document volume. That single number, not a vendor deck, is what the business case rests on.

To build: a single document type wired into an existing system with a review queue, validation rules, and an eval set is typically $15,000–50,000 over a 30–45 day build. A focused document-automation MVP spanning several document types, ERP or CRM validation, confidence tuning, and an operator interface runs $50,000–150,000. The expensive part is never the model call – it is assembling a few hundred representative labeled documents, including the ugly ones, and connecting validation to your systems of record. Document automation is also one of the cleanest entry points into a wider agent roadmap; see our roundup of AI agent use cases for business for where it sits alongside the other high-ROI workflows.

If you have a stack of documents someone is keying by hand today, the build is well-defined and the payback is measurable in months rather than years. You can see how we scope and ship this kind of workflow on our services page – and the first conversation should be about your escaped error tolerance, not about which model we would use.