Most finance and purchasing teams still have someone opening supplier PDFs and typing quantities, part numbers and totals into the ERP. Delivery notes, quotes, invoices from small suppliers, signed forms that were printed and scanned back in. AI can take most of that typing away, as long as you point it at the right documents and decide upfront what happens when it gets something wrong.
Which documents actually need AI extraction?
Documents that already arrive as structured data do not. An e-invoice sent over the Peppol network or an order received through EDI is a machine-readable file with defined fields, and an import job handles it more cheaply and more reliably than any model. Running AI on those adds cost and a new way to fail.
AI extraction earns its place on everything else. That usually means PDF invoices from suppliers who are not on an e-invoicing network, delivery notes and packing slips, quotes and price offers, contracts, and paper forms that come back as scans or phone photos. None of these share a schema, and every supplier lays them out differently and changes the layout without telling you.
What can AI reliably extract from a PDF today?
On a PDF exported from accounting or ERP software (selectable text, clean layout), extracting header fields is reliable: supplier name, dates, document numbers, VAT or tax IDs and totals. It also works on layouts the system has never seen, which is the main improvement over the old coordinate-based templates.
Line items are where it gets harder. A delivery note with eighty lines across three pages, merged cells and repeated headers is exactly where extraction drops or duplicates a row and nobody notices. Skewed scans, faxes and photocopies of photocopies hurt OCR quality before the model even sees the text. Handwriting is still the weakest point: a quantity corrected in pen on a delivery note can be read, but it should never be accepted without a check.
| Content | Reliability today | What it needs |
|---|---|---|
| Printed text in native PDFs (headers, dates, tax IDs, totals) | High | Format and consistency checks |
| Short, regular tables | Good | Line sum compared with the total |
| Long, multi-page tables with merged cells | Variable | Row counts, reconciliation, review of doubtful cases |
| Low-quality scans and phone photos | Variable | Dedicated OCR and a confidence threshold |
| Handwriting, stamps, pen corrections | Low | Human review, always |
Should you use OCR with rules, an LLM, or a hybrid?
OCR with rules (per-supplier templates, regular expressions, fixed positions) is cheap per page and predictable. It breaks as soon as a supplier changes their template, and every new supplier needs setting up. It makes sense when you have a handful of stable suppliers.
An LLM that reads the document and returns fields in a fixed format handles new layouts with no setup and understands context such as "partial delivery" or "price valid for 30 days". It costs more per page, and its errors are plausible: it can write a believable number that is wrong.
Every document pipeline I have taken to production has been hybrid. An OCR and layout service reads the document, an LLM interprets the fields, and deterministic checks decide whether the result can be accepted. In the financial statement extraction pipeline, each document goes through about 30 checks, for example totals that must reconcile. Documents that pass all of them clear with no human step, and the rest go to review.
| OCR + rules | LLM only | Hybrid (OCR + LLM + checks) | |
|---|---|---|---|
| New layouts | Configured one by one | Handled without setup | Handled without setup |
| Errors | Obvious (empty field) | Plausible, hard to spot | Caught by the checks |
| Cost per page | Low | Higher | Higher, plus the checks |
| Maintenance | High if suppliers change often | Low | Medium (the check rules) |
| Use it for | Few suppliers, fixed layouts | Prototypes, low volume | Production, data that lands in your ERP |
How do you know the extracted data is correct?
Extraction without checks moves the work around: instead of re-keying, someone re-reads everything. Useful checks are usually simple. Line items should add up to the total, net plus tax should equal the invoice total, a VAT number should have a valid format, the supplier should exist in your master data, and the purchase order quoted on a delivery note should match an open order with compatible quantities.
The second tool is comparing against data you already hold. In the inheritance document checks built for a major Italian bank, legal documents are compared with the bank's own records. When a check fails, the file goes to an operator with the specific reason, so the operator looks at one discrepancy instead of re-reading the whole file. Handling time dropped by 80%.
Who reviews low-confidence fields, and how much manual work is left?
Human review is part of the design. The reviewer needs the original document next to the extracted fields, with only the problem fields highlighted, and should be able to fix and confirm in a couple of clicks. If the review screen is awkward, people go back to checking everything and the savings disappear.
How much work remains depends on how many documents pass every check. In the financial statement project, at more than 2,500 documents a day, manual work fell by 84%: analysts only review documents that fail a check, and they know which check failed. Your delivery notes and quotes will give different numbers, and the only way to know them is to measure on a sample of your own documents.
What drives the cost of a document extraction system?
I will not quote generic figures because they vary too much, but the cost drivers are always the same. Volume matters, meaning pages per month and the peaks. So does layout variety: ten suppliers or three hundred, native PDFs or scans. The number of fields counts, especially if you need line items and not only header data. Then come the ERP integration and your data constraints. For banking clients, models ran on Azure OpenAI inside the client's EU cloud, with an audit trail on every document and no sensitive data in logs, and that shapes both the project and the infrastructure.
Model cost per page is usually the smallest line. Defining the checks, building the review screen and integrating with your systems take most of the effort, and they are also what makes the system work.
How do you start automating data extraction from supplier documents?
| Step | What to do | Outcome |
|---|---|---|
| 1. Pick one flow | One high-volume document type, such as inbound delivery notes | A measurable scope |
| 2. Collect a sample | A few hundred real documents, including the ugly ones | An honest test set |
| 3. Define fields and checks | What the ERP needs and which rules verify it | Written acceptance criteria |
| 4. Measure | How many documents pass every check and how many errors slip through | The number you decide on |
| 5. Integrate with review | Connect the ERP and the queue for doubtful cases | A flow in production |
If you have not yet picked which process to automate, the guide on which back-office tasks to automate first with AI covers how to choose.
What mistakes should you avoid when extracting data from documents?
The first is running AI on data that is already structured, such as Peppol e-invoices or EDI orders. The second is judging the system on average field accuracy, when what matters is how many documents clear automatically without an error reaching the ERP. The third is testing only on clean PDFs and finding out in production that half the delivery notes arrive as phone photos. The fourth is leaving out human review, or building one that forces people to re-read everything. And in regulated sectors, sending documents with personal data to an external service before deciding where the models run and what ends up in the logs.
If you work in a regulated industry, the document AI service for banks and regulated companies page describes how I set up pipelines, checks and audit trails.
Still re-keying delivery notes or supplier PDFs?
Send me a few sample documents and I will tell you what can be extracted automatically and with which checks.
Let's talk