AI document processing turns a document your team would otherwise read and re-type — an invoice, a claim, a purchase order, a contract — into validated fields in a system of record. The pipeline is capture, classification, extraction, validation and routing, and only the extraction step is new: OCR and business-rule checking have existed for decades. What separates a pipeline that survives contact with real mail from a demo is what happens to the fields the model is unsure about, and what each of those fields costs when it is wrong.
Most evaluations stall on the same question — how accurate is the model? — because per-document accuracy is the least useful number in the project. A pipeline that reads nine of ten fields perfectly and misses the invoice total on one document in twenty has excellent document accuracy and a review queue that never empties. This guide is about the numbers that predict whether the work actually leaves your team's desk.
OCR, extraction and RPA are three different things
The vocabulary in this market is loose, and it hides real cost differences.
- OCR converts pixels into characters. It is cheap, mature and commoditised. On clean printed documents it is close to solved; on skewed scans, faxes, stamps and handwriting it degrades, and every downstream stage inherits the damage.
- Template or zone-based extraction reads fields from fixed coordinates. It is fast and free once configured, and it breaks whenever a supplier redesigns an invoice or a new document type arrives — which is why template libraries grow into maintenance projects.
- Model-based extraction asks a vision-capable model for specific fields as structured output validated against a schema. It handles layout variation and semantics — distinguishing a purchase-order reference from an invoice number, or a ship-to address from a bill-to — and it costs inference per page, with a failure mode that looks like confidence rather than an error.
- RPA does not read documents at all. It moves data between systems once something else has read them. Adding RPA to an unread document pipeline automates the re-typing, not the reading.
In practice, a modern pipeline uses OCR as a pre-processing step where it helps, a model for extraction, and deterministic code for validation. The engineering time goes into the pipeline, not the model choice.
The five stages, and the one that decides the outcome
Ingest. Email attachments, shared-drive drops, supplier portals, EDI feeds, scanner output, and the mailbox nobody admits is the real intake process. Duplicate detection belongs here — the same invoice arrives twice more often than anyone expects.
Classify. Decide what the document is before extracting from it. A supplier sends invoices, credit notes, statements and remittance advices from the same address, and the wrong extractor produces confident nonsense.
Extract. Capture the fields you need: header data, line items, totals, tax, dates, reference numbers, and the tables that carry most of the value in claims and logistics documents.
Validate. Check the extracted values against something authoritative, not against the document itself. Does the invoice total reconcile to the purchase order and the goods receipt? Does this policy number exist and is it active? Is this vendor approved and bank-detail-verified? This is the stage that creates the value.
Route and post. Clean documents post automatically. Exceptions go to a person with the questionable field highlighted, the source page alongside it, and the candidate match from the system of record offered as a one-click fix.
A pipeline that extracts perfectly but cannot confirm an invoice belongs to an open order has automated typing. The team still opens every document to check it, the headcount does not move, and the project is written off as a technology disappointment rather than a scope error.
Accuracy is the wrong headline number
Four measurements describe a document pipeline, and only one of them is accuracy in the usual sense.
Straight-through rate — the share of documents posted with no human touch. This is the number that decides whether the team's workload changes, and it is the number to put on the project's one-page dashboard.
Field accuracy on the fields that gate posting — totals, reference numbers, dates, entity names. A model at ninety-nine percent field accuracy that fails on the total is a model that generates exceptions at the exact moment money moves.
Exception composition — not just how many documents hit the queue, but why. A queue that is mostly new supplier formats is a configuration problem. A queue that is mostly poor scans is an intake problem. A queue that is mostly validation mismatches is a process problem upstream, and no amount of model tuning fixes it.
Review minutes per exception — the labour the pipeline did not remove. If a reviewer needs four minutes and a call to resolve an exception, a low exception rate can still cost more than the automation saves.
Measure all four on a labelled sample of your own documents, re-measured after every prompt, model or template change. A vendor's accuracy figure is a claim about their benchmark set; your sample is the only evidence about your mail.
The exception queue is the product
Most failed document automation projects did not fail at extraction. They failed because the exception path was an afterthought: a spreadsheet, a shared mailbox, or a routing rule that dumped uncertainty on whichever reviewer was unlucky.
Three design decisions carry most of the benefit.
Threshold per field, not per document. A missing purchase-order reference on an invoice should route; a slightly uncertain supplier name that fuzzy-matches exactly one vendor in the master should not. Field-level confidence lets the pipeline post the document and flag the one value, instead of holding the whole document hostage to its weakest field.
Route with evidence. The reviewer needs the source document crop next to the extracted value, and — where validation found a candidate — the matching record from the ERP, claims system or policy admin platform. An exception queue without evidence becomes a re-keying queue.
Treat corrections as labels. Every override is a labelled example. Keep them, and the pipeline has a path to improve on your documents rather than on a benchmark. Discard them, and the same exceptions return next quarter with new dates.
Before adding a second document type, get the first one stable. A pipeline that posts eighty percent of invoices untouched is a working product; a pipeline that handles six document types at forty percent is six half-finished projects.
What it costs, and how to model it
Quotes for document automation vary by an order of magnitude because they bundle different things: platform licence, build, integration, and the review labour the buyer still pays for. Model the number yourself and the proposals become comparable.
Cost per document has four components, and you can estimate each from your own volumes:
- Inference and platform — pages per document multiplied by per-page extraction cost, plus the platform subscription. Ask for per-page pricing rather than per-document, because a ten-page contract and a one-page invoice are not the same job.
- Review labour — exception rate multiplied by minutes per exception, multiplied by the loaded hourly cost of the reviewer, divided by sixty. This is usually the largest line at mid-market volumes, and it is the line that improves as straight-through rate rises.
- Build and integration — one-off, but amortise it over the documents you expect to process in two years, or the first month will look catastrophically expensive.
- Change cost — how often document formats change, how many systems the results must reach, and who maintains the prompts and validation rules after go-live. Ask this question before signing, not after.
The arithmetic matters more than any benchmark: a pipeline at a high straight-through rate on one document type usually beats a broader pipeline at a low one, because the review line dominates the total.
Build or buy
Buy when the documents are standard and the integration is shallow: accounts-payable invoices into one ERP, with a vendor that already maintains the connectors. The time-to-value is measured in weeks, and the platform carries the maintenance.
Build when the documents are specific to your industry, when the decision inside the workflow is yours (validating a claim against policy terms, matching a bill of lading to a shipment), when the results must reach several systems, or when the logic is a competitive asset you do not want to rent. Our AI document processing service covers the delivery shape of that work; the AI automation practice covers the surrounding workflow.
The hybrid is common and often right: a platform for the standard high-volume type, custom code where the validation logic and the integration actually live.
Integration is the schedule risk, not the model
Extraction demos in days. Integration sets the go-live date. The recurring causes:
- Master data quality. Vendor matching depends on a clean supplier master. If the ERP holds four spellings of the same vendor, validation will route documents that should have posted.
- Duplicate submission. Email plus portal plus EDI means the same invoice can arrive twice. Idempotency keys and a document fingerprint at ingest are cheaper than a credit-note cleanup later.
- Write-back permissions and audit. Posting into an ERP, claims platform or EHR is a privileged operation. Design the service account, the approval path and the audit trail before the first document is posted, not after the first bad one.
- Validation duplicated on both sides. If the ERP will reject a posting anyway, model that rule in the pipeline so the exception arrives with an explanation instead of bouncing back from a batch job at midnight.
Data handling and compliance
Documents are among the most sensitive files a business holds: bank details, health information, personal identifiers, contract terms. Four things belong in the design review.
- What leaves your environment. Model providers differ on whether inputs are retained or used for training. For regulated data, the answer has to be contractual, not a setting in a dashboard.
- Residency and agreements. If the documents contain protected health information, the vendor needs a business associate agreement; if they contain EU personal data, a data processing agreement and a lawful basis. Reviewers in the exception queue count as access, and their location matters.
- Retention and redaction. Decide how long extracted fields, source images and model inputs are kept, and redact what the workflow does not need.
- Audit trail. Record what was extracted, by which model or prompt version, which rules validated it, who overrode what and when. When a figure is questioned a year later, this is the only defensible answer.
A four-week pilot that produces a decision
A pilot should end with a number, not a demo.
Week one — baseline. Take a few hundred real documents of one type, measure the manual process honestly (minutes per document, error and rework rate), and label a representative sample as ground truth. Set the straight-through and accuracy thresholds that would justify the build before you see the model's results.
Week two — the pipeline, one document type. Ingest, classify, extract with a schema, validate against the system of record. Measure straight-through rate and field accuracy on held-out documents, not on the ones you tuned against.
Week three — the exception queue. Route with evidence, instrument review minutes, and watch where reviewers hesitate. Those hesitations are the next iteration's requirements.
Week four — the number. Cost per document from measured review minutes and real inference volume, compared against the baseline. Either the pipeline clears the threshold you set in week one, or you have learned that this workflow is not the one to automate first — which is a genuine result, and much cheaper than discovering it a quarter into a build.
Where the payback usually comes from
The workflows that pay back first share four traits: high volume, a fixed field set, an authoritative record to validate against, and an error that costs money. Invoices, claims, purchase orders, remittances and logistics documents all qualify. The nine document workflows worth automating first covers each one, and our insurance claims case study shows what the pipeline looks like when the validation target is a policy rather than a purchase order.
Frequently asked questions
What is the difference between OCR and AI document processing?
OCR converts document images into text. AI document processing is the pipeline around it: classifying the document, extracting specific fields into a structured schema, validating those fields against an authoritative record such as an ERP vendor master or a policy, then posting clean documents and routing the rest to a person. OCR is one component, and often not the one that decides the outcome.
How accurate does AI document processing need to be?
Accurate enough that the documents that gate on a field post without review. In practice that means measuring field accuracy on the fields that block posting — totals, reference numbers, dates, entity names — rather than per-document accuracy, and pairing it with a field-level confidence threshold so one uncertain value does not hold an entire document. Set the threshold from your own labelled sample before the pilot starts.
What does AI document processing cost per document?
It is a function of four lines: extraction and platform cost per page, exception rate multiplied by review minutes and reviewer cost, build and integration amortised over expected volume, and the cost of maintaining rules and prompts as formats change. Review labour dominates at most mid-market volumes, which is why straight-through rate predicts total cost better than the licence price does.
Can AI document processing handle handwritten or scanned documents?
It can, with caveats. Clean printed scans are the easy case; handwriting, stamps, fax artefacts and multi-generation photocopies degrade accuracy, and the variance between documents matters more than the average. The honest test is a labelled sample of your own worst documents, measured field by field, rather than a demonstration on clean examples.
Do we have to replace our ERP or claims system to use it?
No. The pipeline writes validated data into the systems you already run. What it does require is write access with an auditable service account, agreement on which system owns validation, and master data clean enough to match against — which is usually the real work in the project.