A CFO at a mid-sized lender forwarded me a vendor pitch last quarter and asked for a second opinion before he signed. The headline number was big and round: 99.2% accuracy. The deck looked expensive. He wanted to know if it was as good as it sounded.
It was not. That 99.2% was character-level OCR accuracy on a clean PDF benchmark. In plain terms, it measured how often the system read an “8” as an “8” and not a “B”. It said nothing about whether the invoice number landed in the invoice-number field, whether the line items added up to the total, or whether the GST number matched the vendor on file. On his actual mail, which arrives scanned, re-scanned, and sometimes photographed at an angle inside a warehouse, the real end-to-end number sat near 71%.
Nobody on the vendor side lied. They just answered a question he had not asked. And the reason that gap keeps happening is the word everyone still uses: OCR.
What OCR actually does
OCR stands for optical character recognition, and the name is honest about its scope. It turns an image of text into machine-readable characters. Point it at a scan and it gives you back a wall of letters and numbers in roughly the right order. That is the whole job. It was a genuine breakthrough in the era of fax machines and flatbed scanners, and on a crisp, typed page it is still very good at it.
The problem is what the word now implies. When someone says “we use OCR to process invoices,” they usually mean something far bigger: capture the document, find the right fields, validate them, match against a purchase order, and post the result. OCR does the first slice of that and nothing else. Everything that makes a document useful happens after the characters come out.
The three things OCR was never built to do
OCR does not know what it is reading. It cannot tell you that the string in the top right is the invoice date and not the due date, because it has no idea what a date is for. It also cannot check itself: if it reads a total as 1,800 instead of 18,000, it reports both with the same flat confidence and moves on. And it cannot reason across a document, so it will never notice that the line items sum to a different number than the total it just extracted. None of that is a flaw in OCR. It is simply outside what character recognition was ever meant to handle.
The accuracy number on the deck
Here is the part that trips up buyers. Vendors quote character accuracy because it is the highest, cleanest number they can produce. Your team experiences field accuracy on real documents, which is lower and far more honest. The two get reported as if they are the same thing. They are not even close.
A note on these numbers. These are ranges we see across PTAS projects, not published industry benchmarks. The spread is wide on purpose, because the result depends almost entirely on how clean your incoming documents are. A team that receives tidy supplier PDFs lands near the top of each range. A team drowning in phone photos and faxed copies lands near the bottom. Anyone who quotes you a single, precise figure for “document accuracy” without asking what your mail looks like is guessing.
What agentic document extraction does instead
Agentic document extraction starts where OCR ends. Reading the characters is the cheap part. The work that matters is deciding what each value means, checking it against what else you know, and knowing when to stop and ask. We build it as a short loop that runs on every document.
The loop, in four steps
Read
Pull the text and the layout off the page. This is the OCR part, and it is the easiest part.
Reason
Work out what each value is. Which string is the total, which is the date, which line belongs to which item.
Check
Test the answer. Do the line items sum to the total? Does the vendor match your master? Does the maths hold?
Escalate
When something does not add up or confidence is low, route that one document to a person instead of guessing.
That fourth step is the one OCR cannot offer, and it is the one that makes the whole thing safe to trust. An agent that knows when it is unsure is worth far more than one that is confidently wrong 8% of the time.
One ugly invoice, step by step
Take a real example. A supplier sends a photographed invoice, slightly skewed, with a coffee ring over the tax line and two pages stapled in the wrong order. Watch what each approach does with it.
What plain OCR hands back
A block of text. The total reads 4,800 because the smudge swallowed a digit. The vendor name is spelled two different ways across the two pages. OCR reports all of it at high character confidence, because the characters it could see were sharp. It has no way to flag that the number is probably wrong. The error sails straight into your ledger.
What the agent does with it
The agent reads the same page, then keeps going. It notices the line items add up to 48,000, not 4,800, so the total it read is off by a digit and it corrects the field with a note. It sees two spellings of the vendor, matches both to the same entry in your vendor master, and picks the canonical name. It reorders the pages because the invoice number on page two clearly precedes the detail on page one.
When it stops and asks a human
Now suppose the tax line is genuinely unreadable, not just smudged. The agent does not invent a figure. It posts everything it is sure of, marks the tax amount as low confidence, and pushes that single field to a reviewer with the cropped image attached. A person spends fifteen seconds on it instead of re-keying the whole invoice. That is the difference between automation you can audit and a black box you have to babysit.
Where OCR still earns its place
I am not here to bury OCR. It is a mature, fast, cheap technology, and on the right documents it is the correct tool. If you are digitising clean, fixed-layout forms where you only need the text and no decision rides on it, reaching for an agent is overkill. Use OCR, save the money, move on.
A simple test for which one you need. Ask what happens after the text comes out. If a human still has to read every result, interpret it, and check it against another system, you do not have an OCR problem. You have an extraction-and-judgement problem, and OCR accuracy will not tell you how well it is going. If nobody needs to interpret the output, OCR alone is fine and you should not pay for more.
What to ask before you sign
If a vendor waves a single accuracy number at you, three questions usually settle whether it holds up. First: is that character, field, or document accuracy? The numbers fall fast as you move down that list, and document accuracy is the one your team feels. Second: on which documents was it measured? A clean benchmark set tells you nothing about your faxed, photographed, multi-format reality. Third: what does the system do when it is unsure? If the answer is “it returns its best guess,” you will be paying people to catch its mistakes forever.
The cleanest way past all three is to stop debating decks and test on your own paperwork. Hand over a stack of your real, ugly documents and ask for a field-level breakdown with confidence scores. The number that comes back is the only one that matters.
Common questions
Is OCR the same as agentic document extraction?
No. OCR turns pixels into characters and stops there. Agentic document extraction reads the page, decides what each value means, checks it against your other records, and asks a human when it is not sure. OCR is one early step inside that work, not the whole job.
Why does a vendor’s 99% accuracy number not match what my team sees?
Because that figure is almost always character accuracy on clean scans, while your team lives with field accuracy on real mail. Those are different measurements, and the second is lower. Ask whether the number is character, field, or document accuracy, and on which documents, before you sign anything.
Does OCR still have a use in 2026?
Yes, on clean, fixed-layout documents where you only need the text and no decision rides on the result. There OCR is fast and cheap and good enough. The problem is using OCR accuracy to describe an automation that has to read, judge, and act on messy documents.
How should a finance or operations team start?
Pick one high-volume process where you already know the right answer, such as invoice capture and matching. Run a few weeks of real documents through it, measure field accuracy and the share routed to a human, and only expand once that first one is paying for itself.
The short version: OCR is a feature, not a frame. The moment a document has to be understood and not just read, the accuracy number you should care about is the one measured after the reasoning and the checks, on your own mail. That is the number we hand back, and it is usually the first honest one a buyer has seen.