Most businesses run on documents that arrive as files: invoices, order forms, application forms, statements, contracts. Someone opens each one, reads it and types the important parts somewhere else. AI document processing is software that does the reading step, so a person checks the result instead of typing it from scratch. This guide explains how it works, how it is checked and where it does not fit.
How does software read a PDF or a scanned page?
It depends first on what kind of file you have. A PDF can hold two very different things, and the method changes with each.
- A text layer: the file contains the actual characters, so software can pull the text out directly and keep its position on the page
- A scanned image: the file is a picture of a page, a photo or a fax, and there are no characters in it until something reads the picture
Reading a picture is the job of OCR, short for optical character recognition. It turns the shapes on the page into text. Quality depends heavily on the scan: skew, shadows, stamps, handwriting and low resolution all cause misreads, and a number misread by one digit is easy to miss.
Once there is text, the harder part begins: knowing what it means. Older tools relied on fixed templates, such as "the total is in this box". They work until a supplier changes its layout. A language model can instead read the page the way a person does, using the layout and the wording together, to decide that this figure is the invoice total and that one is a tax line. For readers new to the term, our guide to what a private LLM is starts with what a language model is.
A model reads plausibly, not perfectly. It can pick the wrong figure or fill a gap with a guess. That is why the rest of the system matters as much as the reading.
How are the results checked before anyone relies on them?
A well-built system does not trust a single read. It runs checks the way a careful clerk would, and the checks are ordinary rules that do not depend on the model being right:
- Cross-checks: line items should add up to the subtotal, the subtotal plus tax should equal the total, and dates should be in a sensible order
- Required fields: an invoice with no number, no supplier or no amount is incomplete, whatever the model said
- Matching against your records: the supplier should exist in your list, the purchase order number should be real and open, and a duplicate should be caught
- Format rules: a tax identifier, bank detail or date has a known shape that a misread usually breaks
- Confidence: many tools report how sure they are of each field, and a low score is a reason to look, though a high score is not a guarantee
None of these proves a document was read correctly. A total can be wrong and still add up if the same mistake was made twice. They catch many errors cheaply, and they decide which documents can pass and which need a person.
What is an exception queue, and why does it matter?
An exception queue is the list of documents the system is unsure about. When a check fails, a required field is missing or confidence is low, the document does not go through. It lands in front of a person, who sees the original page beside what was read, corrects it and approves it.
This is the design choice that makes the whole idea safe to use. The aim is not to remove people from document work. It is to spend their attention on the documents that need judgment instead of on all of them. If a vendor tells you every document will be handled with no review, ask what happens to the ones that are misread, because some will be.
Which documents suit AI document processing, and which do not?
The best candidates arrive in volume, share a purpose and need the same handful of fields every time. The poorest are rare, ambiguous or high stakes on their own.
| Document type | Usually suits | Take more care |
|---|---|---|
| Supplier invoices | Many layouts, same fields, easy to cross-check against totals and purchase orders | Credit notes, multi-page invoices and unusual tax treatment |
| Order and intake forms | Fixed fields and a clear set of valid answers | Handwriting and forms filled in unevenly |
| Bank and card statements | Rows of transactions with running balances that check against each other | Poor scans and merged cells |
| Receipts and expense claims | A small set of fields: date, vendor, amount | Crumpled photos and faded thermal paper |
| Contracts and agreements | Finding clauses, dates and parties for a person to review | Anything where the meaning of a clause decides a decision |
| Rare or one-off documents | Rarely worth setting up | Too few examples to test against |
Documents that need background knowledge that is not on the page also tend to disappoint.
How do you know it is accurate enough?
Do not rely on a vendor's accuracy claim, including ours. Accuracy depends on your documents: your suppliers, your scanner, your forms. The honest test uses your own files.
- Collect a sample of real past documents, including the messy ones, and keep the correct answers a person already entered
- Run the system on them without showing it the answers
- Compare field by field, and note which fields and which document types fail
- Decide in advance what error rate is acceptable for each field. A missed note matters less than a wrong bank detail
- Repeat after any change to the model, the settings or a major supplier's layout
The result is a record you can read, not a single percentage. It tells you which fields need a person every time, which can pass after checks, and where the process should not be automated at all.
Is document processing the same as data entry automation?
No, though they are often sold together. Document processing is the reading step: turning a file into structured fields. Data entry automation is the moving step: taking structured data and putting it into your accounting system, CRM or database, or passing it from one system to another. You can have either without the other. A system can read an invoice and hand the fields to a person to key in, or move data between two systems that never involved a document. Most real projects need both. The connection side is what our AI integration work covers.
What about contracts, and what are the risks?
Contracts are a good example of where care is needed. A model can pull out the parties, dates, renewal terms and notice periods, or summarize a clause in plainer words, which helps a person find what to read. It is not legal advice, and a summary can leave out or soften something that matters. Treat every contract summary as a draft for review by the person responsible for the agreement, and have a qualified adviser read anything that carries real obligations.
There is also a security point. A document is input, and input can be hostile. Text hidden in a PDF or an email attachment can try to instruct the model, for example to approve a payment or ignore a rule. The OWASP guidance on prompt injection describes this class of problem. The defense is design: the model reads and proposes, fixed rules and a person approve, and the system has no ability to pay, send or delete on its own.
What should you do next?
Pick one document type that arrives often and has a clear destination. Gather a sample, write down the fields you need and decide what a wrong value would cost. If you are still choosing between candidates, how to find business processes worth automating with AI gives a method for ranking them, and the wider list in business processes to automate with AI shows other places to look. When you are ready to talk it through, our AI integration services page explains how we scope and test this kind of work.
For the bigger picture of how a model connects to the software you already run, and what it should be allowed to change, see what AI integration is.