Intelligent document processing: what it is and how to get it right

Intelligent document processing (IDP) is software that reads documents such as invoices, delivery notes, bank statements and application forms, and turns them into data your systems can use. This guide is for the UK operations or finance lead deciding whether it is worth doing, and how to tell whether it works.

We design, build and run AI automation that reads documents, and run an AI service of our own that reads job ads. Here we cover what decides a project: accuracy, review, data protection and cost.

What intelligent document processing does

An IDP system usually has five parts.

1. OCR. Optical character recognition turns an image of a page into text. A PDF made by software already contains its text; a scan or a phone photo does not.
2. Classification. What each document is: invoice, credit note, statement. One PDF may hold several, which have to be split first.
3. Extraction. The fields you need: supplier, invoice number, date, net, VAT, total, lines.
4. Validation. Checking values against rules and your records: the lines add up, the supplier exists, the purchase order is open.
5. Review. A person corrects anything that fails a check or that the software is unsure of.

The result is then written into the accounting package or ERP. When we build these, the last two steps take more design work than the first three.

How it differs from OCR and from templates

Plain OCR stops at text: an open-source engine such as Tesseract turns a scanned invoice into lines of words, but doesn't know which number is the total. Template capture reads fixed layouts: you mark where the invoice number sits on one supplier's invoice, and the software reads that spot every time. It breaks when the layout changes, and every new supplier needs a new template. Microsoft still offers a custom template model for static layouts, beside a neural model for documents that vary.

IDP uses machine learning, and increasingly large language models, to find fields by meaning rather than position, so it copes with many senders. It is less predictable, which is why validation and review matter.

The options: document AI services or a general AI model

You can buy a finished IDP product, build on a cloud document AI service, or ask a general AI model for the fields. If you buy, ask what the product uses underneath and where that runs.

Cloud document AI services

Microsoft, Google and Amazon each offer OCR, prebuilt models and custom models. From their documentation and pricing pages as of October 2026, in US dollars at the first price tier:

The prebuilt models lean towards US documents, and Amazon's FAQ says Textract reads invoices and receipts in English only. A prebuilt invoice model is a fair start for a UK finance team; for most other documents, plan on a custom model or a general one.

General AI models

Models such as Anthropic's Claude and Google's Gemini can read a PDF directly and return the fields you ask for. Anthropic says each page is converted into an image, with its extracted text alongside, at standard API rates. Google says Gemini reads PDFs of up to 1,000 pages and can return structured output.

The advantage is range: no training, and one prompt can cover invoices from a thousand suppliers. The cost is predictability. The document services return confidence scores; with a general model you design the checks yourself, with tests on real examples and a person checking.

How to measure accuracy honestly

Vendors' accuracy figures aren't about your documents. Measure your own.

1. Take a real sample. Recent documents as they arrived, including faint scans, phone photos and the supplier who puts the total somewhere odd. A few dozen per document type is enough to start.
2. Check them by hand. Someone who knows the work keys the correct value of every field, and a second person checks a share. This is your answer key.
3. Score each field. Count right, wrong and blank, and keep wrong and blank apart: a blank goes to a person, but a wrong value can go straight into your ledger.
4. Score whole documents. With ten fields each right 98% of the time, only about 82% of documents have every field right, if errors are independent (0.98 to the power of ten).
5. Keep the sample. Rerun it whenever a model, prompt or provider changes, and add the documents that caught you out.

The review step and confidence thresholds

The design question is which documents a person sees. There are two triggers.

Confidence. Microsoft says a field confidence of 0.95 means the prediction is likely correct 19 out of 20 times, and suggests using it to accept a value or flag it for review. Set thresholds per field: a delivery address can tolerate more doubt than a bank account number. Then check against your sample that fields above the threshold really are right as often as you need.

Rules. Confidence says whether the software thinks it read the page correctly; rules say whether the answer makes sense. The lines add up to the net, net plus VAT equals the total, the VAT number matches the supplier record (HMRC has a public VAT number checker), and the invoice number is new for that supplier. A confident misreading often fails a rule.

Show reviewers the page image beside the fields, with the failed check highlighted, and record every correction. Then watch two numbers: the share of documents that go through untouched, which is the saving, and the error rate among them, which is the risk. Moving the threshold trades one for the other.

An example from our own work: reading job ads

We built and run 4dayweek.io, a job board for four-day weeks and other reduced hours. It collects jobs from more than 1,300 company job boards on dozens of hiring systems, each with its own format. Job ads are web pages, not scans, but the problem is IDP's: many layouts, the same few facts, and a real cost when one is wrong. An AI service reads every ad, and three of its design choices carry over to any document work.

• Narrow requests. Three AI requests read each ad: one for role, level and skills, one for the location text alone, one for the salary. The location reader never sees the company name, so it can't guess the head office.
• A missing value rather than a wrong one. The salary reader takes base pay only and keeps the stated period, and a guard drops implausible figures before they are stored. We never estimate pay, because a wrong salary misrepresents a real employer.
• Tests before every change. Before any prompt, model or provider change goes live, golden tests run against the real models, checking that real facts are found and boilerplate isn't read as a perk.

Data protection basics

Payslips, bank statements, ID documents, application forms and sole traders' invoices all contain personal data, so UK GDPR covers the whole pipeline. Start with the ICO's guidance on AI and data protection; it is under review after the Data (Use and Access) Act, so check each page's status.

• A contract with every processor. The ICO says that every time a controller uses a processor, there must be a written contract, and that includes the cloud provider.
• Know where it runs and what it keeps. Microsoft deletes Document Intelligence inputs and results 24 hours after analysis. Amazon's FAQ says Textract may use inputs to improve its services, and store some content in another region, unless you opt out through an AWS Organizations policy. Sending personal data to a separate organisation outside the UK is a restricted transfer with its own rules.
• Extract only what you need. Personal data must be adequate, relevant and limited to what is necessary. If you need the supplier and the total, don't store every name on the page.
• Consider a DPIA. The ICO's list requires a data protection impact assessment when innovative technology, including AI, is combined with any criterion from the European guidelines, such as large-scale processing or sensitive data.

When intelligent document processing isn't worth it

• Low volume. If someone keys a few dozen documents a week, the saving is small next to building, testing and review. Check what your accounting software already does with bills.
• Nothing to check against. Without a purchase order, a total that must add up or another rule that catches errors, you either review everything or accept errors you can't see. For contracts and letters, use AI to summarise or route them for a person, not to post data unattended.
• The data already exists. A PDF is often a printout from someone else's system. Asking a large supplier for a CSV or e-invoices can beat reading their documents perfectly.
• Poor scans and handwriting. Fix the capture first, or swap the paper form for a web form.

If the case is borderline, map the process first: how many documents arrive, how long each takes and how often they go wrong is most of the business case.

If you want a hand

You can test much of this yourself: build an answer key and try a free tier. Azure lists 500 free pages a month, and AWS gives new customers three months of Textract free tier. Use documents without personal data until the paperwork is in place. If you would rather have it built, tested and run for you, start a project and tell us which documents you have in mind.