OCR is more than reading PDFs
Making a scanned document searchable and making it usable are different problems. The first has been solved for twenty years. The second is what actually removes work from a business.
5 August 2026 · 3 min read
A common request sounds like this: "we have thousands of scanned documents, can you OCR them?"
We can. It usually will not help much on its own, and it is worth explaining why, because the gap between what OCR does and what the business actually needs is where most document projects quietly fail.
What OCR gives you
OCR turns a picture of text into text. Run it across an archive and you can search the archive. That is genuinely useful and it is where a lot of projects stop.
But consider what someone was doing with those documents before. They were not searching them. They were opening each one, finding four specific values — a date, a reference number, a quantity, a total — and typing those values into a spreadsheet or a system.
Make the archive searchable and that person is still opening each document and still typing four values. You have improved the archive. You have not touched the work.
The part that is actually hard
The hard part is not reading the characters. It is knowing what they mean.
The same value appears in a different position on every supplier's paperwork. One calls it Invoice No., another Bill Reference, a third puts it in the header with no label at all because it is obvious to a human. Dates arrive in four formats. Quantities sometimes carry units and sometimes do not. Half the documents are photographs taken at an angle on a phone.
The traditional answer was templates: configure a rule for each supplier's layout saying which region of the page holds which field. This works, and then a supplier changes their letterhead, or a new supplier is onboarded, and someone has to configure another template. The maintenance grows with the number of sources, which is exactly the wrong direction.
What changes when the document is understood rather than scanned
This is where AI does something OCR cannot. Instead of matching a position on a page, it reads the document the way a person does — working out what kind of document this is, then locating the required information wherever it happens to sit and whatever it happens to be called.
No template per supplier. A layout it has never seen before is not a special case.
In practice that means output is not text; it is structured data. Named fields, correctly typed, with a reference back to the page and position each value came from, so any number can be traced to its source and checked.
The two details that matter in production
Two things separate a demonstration from something a business can rely on.
Traceability. Every extracted value keeps a pointer to where it came from. When a figure looks wrong six months later — and eventually one will — the question "where did this come from?" has an answer that takes seconds rather than an afternoon.
Knowing when it is unsure. A system that is confidently wrong is worse than one that does nothing, because the error propagates quietly. Anything ambiguous, low quality or unexpected is flagged for a person rather than guessed at. The volume of flagged items is small; the trust it buys is not.
The test to apply
Before commissioning any document project, ask what happens to the output.
If the answer is "we will be able to search it", you have a search project, and OCR alone may be enough.
If the answer is "we will stop retyping this into another system", you need the document to be understood, not merely scanned — and that is a different piece of work with a different cost and a much larger return.
Documents are not the point. The information trapped inside them is the point, and it is only worth anything once a process can use it without a person in the middle.