5 June 2026 · Pedro Aldea
Invoice and delivery-note OCR: the platform isn't the bottleneck
Reading the document is the easy, already-solved part. The real bottleneck sits before and after it: documents that shouldn't exist, and the manual matching. Shown with systems in production.
Almost every conversation about document automation starts in the wrong place: at the tool that reads the paper. In 2026, reading an invoice, a delivery note or a purchase order from a PDF is a solved problem — there are a dozen platforms that pull the amount, the tax ID and the date with very high accuracy, with no templates, on formats they’ve never seen. Buying one of those platforms isn’t a bad decision; it’s an incomplete one. Because reading the document is, at most, twenty percent of the work. The real bottleneck lives at the two ends nobody puts in the demo: what happens before the document arrives (how many of those documents shouldn’t exist at all) and what happens after it’s read (the matching, the validation, and getting the data into the system clean without a single person touching it). When we step into a document operation, that’s where almost all the value is — and almost no one looks there.
Reading the document is no longer the problem
It’s worth saying plainly, because it saves arguments: the reading technology is mature. Today’s intelligent document processing systems interpret invoices from different suppliers, delivery notes with varying layouts and orders in any format without anyone training a template for each one. If your problem is strictly “I have a PDF and I want the fields in a table,” almost any solution on the market handles it.
We’ve confirmed this in production. One of the systems we run digitizes a complete industrial catalogue —388 pages of PDF— in a single execution, without anyone typing a line. Another reads the freight quotes that arrive by email and leaves them structured and comparable without anyone opening the message. A third processes documentation daily, with no human in the loop. In none of the three is the merit in “knowing how to read.” Reading is what the tool gives you. The merit is in everything else.
The bottleneck before: documents that shouldn’t exist
Before automating the reading of a document, it’s worth asking an uncomfortable question: why does this document exist? It’s the same question we apply to any step in a workflow, and with documents it gives equally surprising results.
A good share of the documents a company processes by hand are re-entries of information it already holds somewhere else. The delivery note that gets keyed in again when the order was already in the system. The spreadsheet someone fills in by copying data from an email that itself came from a portal. The extra field a customer asked for in 2019, still forcing a manual validation step even though that customer no longer buys. Automating the reading of those documents is using technology to solve a problem that’s better solved by removing it: the data shouldn’t need recapturing because it never should have left the system.
That’s why our first step in a document operation is never to set up the OCR. It’s to sit with whoever processes those documents every day and separate, paper by paper, the ones that carry new information from the ones that merely re-enter information the company already owns. The latter aren’t automated: they’re cut. And what remains —the documents that genuinely bring something from outside— is a far smaller volume than the team assumed. Technology is worth putting on top of that already-smaller volume.
In one of the invoice-processing systems we put into production, six of the workflow steps disappeared before a single line of code was written. They weren’t automated: they stopped existing. The automation came afterwards, on a workflow that already weighed less.
The bottleneck after: matching and clean entry
This is where most OCR projects that end up in a drawer fall apart. The system reads the invoice perfectly, dumps the fields onto a screen… and then a person reviews them, compares them against the delivery note, checks the order existed, fixes a reference that doesn’t add up, and types them into the ERP. The reading was automated. The work wasn’t.
Matching what the document says against what the system says is the real bottleneck, and it’s where the time piles up and the errors slip in. For a document project to actually work, the data that’s been read enters on its own when everything lines up, and when something doesn’t —an amount out of range, an unknown supplier, a missing field, a format that changed— the system knows and raises its hand. That’s the difference between an OCR and a document operation that genuinely frees up hours: detecting the anomalous and flagging uncertainty explicitly, so people only look at what deserves looking at, not every document by default.
When that stretch is built well, the result isn’t “we read invoices.” It’s that incoming documentation is processed daily and nobody touches it except when the system itself asks for help. In that same invoice system, processing time per document went from around four minutes to around twenty seconds; but that number, the visible one, came after the six steps we removed first, the ones you don’t see.
Production, or it didn’t happen
There’s plenty of content about what AI OCR could do. We prefer to talk about what’s running. Three different systems, three document types —catalogues hundreds of pages long, freight quotes by email, daily operational documentation—, all in real production and all with the same trait: the value wasn’t in the reading, but in having removed the documents that didn’t belong and having built the entry so the data landed clean with no intervention.
The practical takeaway, if you’re weighing OCR for your operation, is simple and runs against how it’s sold: don’t start by choosing a platform. Start by counting how many of those documents shouldn’t even arrive, and by looking at what happens to the data after it’s read. You’ll pick the reading tool in an afternoon. The other part is where the project actually is.
How many of the documents your team processes by hand carry information the company didn’t already have somewhere else?
If you’d like to see this run against your own document workflow, here’s how we approach document processing: we start by separating the documents that bring new data from the ones that just re-enter it, before proposing a single line of automation.