Invoice scanning was a real breakthrough: you stopped retyping data. That problem is solved. Why the term now describes what a system no longer needs to be good at.
Invoice scanning is one of the few pieces of finance software where you can point at exactly what it solved. Before OCR, someone retyped the invoice number, the amount, the date and the VAT from paper. After it, nobody did. That is not a marketing story, that is a job that changed, and it is why the term stuck around for twenty years.
Which is precisely why it is misleading now. The term describes the step that is solved, and says nothing about the step where the work actually sits.
What scanning really solved
The problem around the turn of the century was retyping. An invoice was an image, and an accounting system wants fields. OCR bridged that: software learned to read text from paper. Because every supplier lays out their invoice differently, every supplier got a template: the invoice number goes here, the amount there.
It worked, and it scaled. Later it moved to the cloud, became a per-document subscription, and was often supplied by your accounting firm. Approving moved to your phone. That is the world in which Blue10, Basecone, TriFact365, Zenvoices, Elvy and ScanSys grew up, and on what they promised, they deliver.
Then two things happened that hollowed out the value of that step.
First, UBL and Peppol. An e-invoice is not a picture but a structured file. There is nothing to recognise, because the data arrives as fields. For that stream, scanning did not get better, it became unnecessary. And this is no longer a fringe case: Belgium has required structured B2B e-invoicing since January 2026, Germany has required businesses to be able to receive e-invoices since 2025 and is phasing in the obligation to send them through to 2028, and Peppol is the standard the rest of Europe is moving towards.
Second, AI. An AI system reading an invoice needs no template. New supplier, different layout, invoice in German: there is nothing to train. The whole maintenance task of keeping templates disappears, and with it the main reason scanning was a separate product.
So the reading step was hollowed out twice: by e-invoicing, which makes it unnecessary, and by AI, which makes it trivial. What remains is the question of what should happen to the invoice, and that was never what scanning did.
The term hides where the work is
You can see it in what companies are still hiring people for.
We went through 21,642 Dutch finance job postings and looked at every task named in them to see whether it is directly automatable.
| Task | Directly automatable | n |
|---|---|---|
| Reading and entering invoices | 72.8% | 7,723 |
| Matching against purchase orders | 47.2% | 1,088 |
| Approvals | 22.1% | 587 |
That descending series is the whole story. The scanning layer cleared the first category, and that genuinely happened. Further from the reading, less of it happens by itself, and that is exactly the work companies keep writing job ads for.
And you notice it at companies that set things up properly, not at the ones lagging behind. An international hardware reseller processing 500 to 800 invoices a month, scanning software fully configured, told us no invoice goes through without manual intervention. At an aviation maintenance company, one FTE did nothing but the scanning software and the invoice mailbox: templates paid off on recurring invoices, on variable ones they cost more than they saved, and every invoice was still coded by hand on general ledger, cost carrier and cost centre.
That is not a criticism of the software. It does what it says on the box. The point is that what it says on the box is no longer the problem.
"Self-learning" is the word to watch
Almost every vendor now calls their software self-learning. Ask what exactly is learning.
Usually the recognition learns. The system gets better at seeing where the amount sits on this invoice. That is real progress and it saves template maintenance. What almost never learns is the processing: which ledger, which cost centre, which project, what to do with this kind of difference. That stays a rule you configured in advance.
The difference is testable with one question: if my team corrects this posting, will it be right by itself next month?
At a travel services company on NetSuite the answer was no, and their controller said it plainly: the system does not learn from corrections, and first-time processing of a single invoice takes about half an hour. At a distributor on NetSuite OneWorld, one supplier's multi-line invoices came back wrong month after month. Same correction, same supplier, every month again.
If the answer is no, the recognition is learning, and not the system. And a system that asks for the same correction every month is not automating. It moves the work from typing to checking.
What replaces it
Call it what it is: not a scanning layer in front of your ERP, but a layer that executes the work after it. Reading without templates is the easiest step in that, not the hardest.
What has to happen next is threefold, and it builds on itself.
Understanding why something is wrong, not just seeing that it is. Flagging a difference is half a second of work. Working out whether it is a price deviation, a partial delivery or a duplicate invoice, that is the work.
Fetching the context a person would fetch: the order, the receipt, the previous invoice from the same supplier, the email announcing a surcharge, the contract. That is also where the reasoning sits. "Laptop Stand" on the invoice is the same item as "Notebook Riser" on the order, and that is a language question, not a search question.
And then acting, within rules you described in plain language. Posting, splitting across order lines, coding on every axis you use, emailing the supplier with the difference. Every step in an audit trail, so a posting can be explained to your auditor.
What separates this from the previous generation is that you no longer configure software, you give instructions the way you would give them to a colleague. You explain once that this landlord's invoices always cover the following month, and after that you never say it again.
One boundary belongs with that. The AI reads and understands, but it does not decide. A system that is usually right is unusable in a set of books, because five percent wrong on two thousand invoices is a hundred postings a month someone has to find again. The decision has to be deterministic: the same input gives the same outcome, every time.
Should you drop your scanning software now?
Not necessarily. If you process a few hundred invoices a month, without purchase orders, with a stable supplier base, scanning software does exactly what it should and is cheaper than anything else. The term is outdated, the product is not useless.
It only pays to look further once the work after recognition costs structural hours: matching against purchase orders, coding on several axes, invoices split across multiple orders, the mailbox, multiple administrations.
Frequently asked questions
Reading in a paper or PDF invoice and automatically recognising the fields on it, such as supplier, invoice number, amount, date and VAT, so you do not have to retype them. Classically this uses OCR and a template per supplier.
No. Scanning solves the reading. AI invoice processing starts at the reading and continues into understanding, matching, coding and acting. Software that put AI into its recognition still only solves the reading.
Not for the stream arriving as UBL or Peppol, because that data is already structured. As long as your suppliers email PDFs there is still something to read, but it has become the simplest step in the process.
A system that gets better from your corrections. Watch what is learning: with most vendors it is the recognition, not the processing. Test it by asking whether the same correction comes back next month.
Work it out with the ROI calculator, which uses the automatable shares per task category from our analysis of Dutch finance job postings.
More context on the generations of technology and all vendors: the comparison guide to accounts payable software. On what AI invoice processing does look like: automated invoice processing.
Source: Claridy analysis of 21,642 Dutch finance job postings, 2026. Reading and data entry n=7,723, matching n=1,088, approvals n=587. Last checked: 2026-08.