What AI document processing does
Every business receives documents that someone reads in order to type their contents into a system: supplier invoices, purchase orders, delivery notes, application forms, identity documents, certificates, contracts. Document processing automates the reading. Older tools needed a template for each layout and failed when a supplier moved a box. Current systems, built on language and vision models, cope with varied layouts and can be told what to look for in plain terms.
They are still not perfect readers. A faint scan, a handwritten correction, a total that does not add up or an unusual format can each produce a wrong value, stated with apparent confidence. A sound implementation assumes this and is designed so that doubtful documents reach a person and wrong values are caught by rules. That design is what the requirements must describe.
List the document types and collect real samples
- 01
Name each type
Supplier invoice, credit note, purchase order, delivery note. Be specific, because each type has its own fields and rules.
- 02
Count the volume
Documents per month for each type, and how it varies. Volume decides where automation pays.
- 03
Describe how they arrive
Email attachments, uploads to a portal, scans from a mailroom, photographs from a phone. Each channel has different quality.
- 04
Collect real samples
At least several dozen per type, chosen to include the awkward ones: poor scans, multiple pages, several languages, handwriting, stamps over text.
- 05
Record the correct values
For each sample, the values a careful person would extract. This becomes the test set against which any system is judged.
- 06
Note what is out of scope
Types that are rare or too varied can stay manual. Saying so keeps the project small.
Samples contain real personal and commercial data. Agree how they will be shared, stored and deleted before sending them to any supplier.
Specify the fields and the rules they must pass
For each document type, list every field to be extracted, its format, whether it is required and how it can be checked. The checks are what turn a reading into something you can rely on.
| Kind of rule | Example for a supplier invoice | Catches |
|---|---|---|
| Format | The date is a valid date, the tax number has the right pattern | Misread characters |
| Arithmetic | Line amounts add up to the subtotal, and subtotal plus tax equals the total | A wrong digit in any amount |
| Lookup | The supplier exists in the supplier list, the order number exists and is open | Wrong supplier, invented or mistyped references |
| Cross-document | Quantities and prices agree with the purchase order and goods receipt | Overbilling, and extraction errors |
| Duplicate | The same supplier and invoice number have not been processed before | Double payment |
| Plausibility | The amount is within the usual range for this supplier | Misplaced decimal points, and fraud |
| Change detection | Bank details match those held on file | A common invoice fraud |
Write the rules with the people who process the documents today. They apply most of them in their heads already, and they know the ones that matter.
Design the exception queue
A document becomes an exception when a required field is missing, a rule fails or the system reports low confidence in a value. The exception queue is the screen where a person resolves it. Its quality determines both the accuracy of the whole process and how much time is really saved.
- 01
What does the reviewer see?
Why it mattersThe document image beside the extracted fields, with the doubtful values highlighted and the location of each value shown on the page.
- 02
What can they do?
Why it mattersCorrect a value, choose from a lookup, reject the document, send it back to the sender or pass it to a colleague.
- 03
Is the reason shown?
Why it mattersThe failed rule in plain words, such as total does not equal subtotal plus tax, saves the reviewer from hunting.
- 04
Who handles which exceptions?
Why it mattersRoute by type, value or supplier to the people with the knowledge and authority.
- 05
What happens to corrections?
Why it mattersThey should be recorded and used to improve the system, and to spot senders whose documents always fail.
- 06
How long may an exception wait?
Why it mattersSet a target, show the queue's age and alert when items are overdue.
Set thresholds by what an error would cost
Most systems report a confidence level for each value. A threshold decides how confident the system must be for a value to pass without review. Set it per field, not once for everything. A misread reference number that fails a lookup is harmless. A misread payment amount is not.
Sensible threshold practice
- Stricter thresholds for amounts, account details and identity fields
- Rules trusted more than confidence scores
- Everything reviewed at first, then loosened on evidence
- A random sample of passed documents checked regularly
- Thresholds revisited when document sources change
Risky practice
- One threshold for all fields
- Confidence treated as proof of correctness
- Tuning to maximize the automatic share
- No sampling of documents that passed
- No value limit above which a person always looks
A high confidence score means the model is sure, not that it is right. Arithmetic, lookup and cross-document rules are stronger evidence, which is why a value that passes them can be trusted further than one with only a score.
A worked example
Processing delivery notes at a building supplier
This example is invented to show requirements written from real samples. A building supplier's branches receive signed delivery notes from hauliers, which staff key into the ERP to release invoices.
- Types and volumeOne document type, about 3,000 a month, arriving as phone photographs and scans. 150 samples are collected, including creased, stamped and handwritten ones.
- FieldsDelivery number, date, customer, each product line with quantity delivered, any handwritten amendment and whether a signature is present.
- RulesThe delivery number must exist and be open in the ERP. Products must match the order. Quantity delivered may not exceed quantity ordered. A signature must be present.
- ExceptionsAny handwritten amendment sends the note to review, whatever the confidence. Reviewers see the photograph beside the order lines, with differences marked.
- TrialOn the samples, 108 of 150 pass all rules with correct values. 39 go to review, almost all for amendments or poor photographs. 3 pass with a wrong quantity, each a handwritten figure not recognized as an amendment.
The three silent errors lead to a new rule: any ink over the printed quantity sends the note to review. On the next trial none slip through, and the team accepts a lower automatic share as the price of that.
Where the result goes and what is kept
- The destination system. Which system receives the data, through which interface, and whether records are created as drafts or posted. Start with drafts.
- The original document. Store it, linked to the record it produced, so that anyone can see the source later.
- An audit trail. For each document: what was extracted, which rules ran, who reviewed, what they changed and when.
- Retention and deletion. How long documents and extracted data are kept, in line with your legal obligations and privacy policy.
- Privacy and provider terms. Documents sent to a hosted model are processed by its provider. Check the terms on retention, location and use, and exclude document types that must not leave your environment.
- Failure handling. What happens when the destination system is unavailable or rejects a record. Nothing should be lost or entered twice.
Document processing requirements checklist
AI document processing checklist
0 of 11 checkedWhat to do next
Pick the document type with the highest volume and gather fifty real examples, with the values a person would enter for each. Ask the people who process them which checks they perform before trusting a document. You then have a test set and a first list of rules.
Our business process automation page explains how document handling fits into a wider workflow, and our guide on human review design covers the approval steps. Tell us which documents you handle.
Common questions
How accurate is AI document processing?
It varies with document quality, layout variety, language and the fields involved, so a general figure is not meaningful. Printed, well-scanned documents with clear fields are read very reliably. Handwriting, poor photographs and unusual layouts are not. Test with your own samples, and judge the whole process, including rules and review, by the errors that reach your systems.
Can it read handwriting?
Clear handwriting in expected places is often read correctly, and messy or cursive writing often is not. The safer design treats handwriting as a signal for review: the system detects that something is handwritten, proposes a reading and sends the document to a person. Do not rely on unreviewed handwritten amounts or names.
What share of documents can be processed without a person?
It depends on how uniform and clean your documents are and how strict your rules need to be. It rises over time as rules are refined and senders improve their documents. Treat the automatic share as an outcome, not a target. Pushing it up by loosening checks trades visible work for invisible errors.
Do we need templates for each supplier's layout?
Generally not with current model-based systems, which locate fields by meaning instead of position. A new supplier's invoice usually works without setup. Unusual documents may still need specific instructions or examples, and your validation rules remain the safeguard when a new layout is read wrongly.
Is it safe to process confidential documents with AI?
It can be, with the right arrangement. Check where documents are processed and stored, whether the provider retains them or uses them for training, who can view them in the review queue and how long they are kept. Some document types may need to stay within your own environment. Involve your data protection adviser before personal data is processed.
