Thirteen honest answers about OCR, EDI and document automation

OCR — Optical Character Recognition — is the technology that takes an image, PDF or Word doc, finds the characters in it, and reads them. That's all it does. It turns marks on a page into text.

In real-world use, OCR historically required very rigid consistency. You'd be looking for a specific figure, or a specific area of the document you want to pull data from. If the document alters, you need to alter the template so the OCR recognises the document and knows the area it needs to pull characters from. Plenty of legacy systems still require that level of user input.

This has improved vastly with AI, because you're adding intelligence to the OCR. You can now take those characters from an OCR scan and apply your own rules and logic to them. Picture it like having multiple admins, all with different jobs — one is a data extractor, one is a validator, one adds data to the extracted data, like a customer number or an account code.

That's the difference between OCR and document automation. OCR reads. Document automation decides what the reading means, and whether to trust it.

EDI is the third thing. EDI is your database talking to their database. It's mostly trust. It's very complex, and consultants can put checks in, but it requires such a strong business partnership that smaller firms — or firms with a lot of customers — simply don't have it.

OCR reads. Document automation decides what the reading means, and whether to trust it.

Because you may not have the buying power to demand an EDI setup. EDI works when one side of the relationship is big enough to insist on it. If you're not that side, you're waiting for a supplier to build something for you that costs them money and gains them nothing.

However, every business has the power to say: can you send invoices to this email address?

That's the whole shift. EDI is old news, because it doesn't give the flexibility. Email plus OCR plus AI does — and it needs no buy-in from your suppliers or your customers. Nobody has to change their system, sign anything, or run a project. They send the document they were already sending, to a different address.

You may not have the buying power to demand an EDI setup. But everyone has the power to say: can you send invoices to this email?

Lack of knowledge, and lack of trust with these tools. And it's understandable.

It tends to be salespeople who promise the earth, charge a lot up front for setup and consultancy, and then give you a tool that actually doesn't do what was asked. After that's happened to you once, carrying on doing it yourself is a rational decision.

The lock-in makes it worse. Once your data is in, leaving is hard — and the next company tells you that moving to them requires consultancy and money too. So people stay where they are, and the whole category earns its reputation.

Not many — especially when you're adding AI into the mix.

Entering an invoice isn't just the data entry. It's the checks. Making sure line items are correct. Making sure the supplier reference is added so the system knows who this is for. Even for 50 invoices a month, that takes an hour or two minimum.

And it's normally a sit-down task done by an admin who, at the end of the day, is human. They may grow tired. They may miss something. Now you can have this running day and night, and you only have to check when the AI flags something.

It really varies.

A simple totals invoice takes about two minutes. But a multi-line invoice with hundreds of lines — with maths required to check the totals are correct, as well as matching up to a goods receipt — can take anywhere up to 30 minutes. That could contain various metrics and price breaks, all of which need checking.

That spread is the thing most people miss when they estimate their own cost. They picture the two-minute invoice, because that's the one that comes to mind. The 30-minute one is where the month actually goes.

Less than you'd expect. The invoice can be sent in by email. The data can be extracted. The data that isn't on the document — account code, supplier ID — can be added automatically. That data then sits in your ERP, which matches it to the goods receipt. If the data doesn't match, it flags. Invoice entry and goods receipt entry can both be automated.

What can't be automated is the judgement at the end of it.

If the price on the invoice doesn't match the purchase order, software can tell you that. It can't decide whether to accept it, ring the supplier, or hold payment. Someone still has to be accountable for money leaving the business. And if an original is genuinely illegible — a phone photo of a crumpled delivery note, at an angle, in bad light — there's a floor, and the honest answer is that it gets flagged rather than guessed at.

Automation should work for you. It's now cheaper than ever to build and maintain these tools. But incumbents still want to sell you the early-2010s model: cloud plus consultants, big setup fee, long contract. We don't think the software should hold you hostage. We think it should do the job.

What can't be automated is the judgement at the end of it.

Yes.

The way Harold does it is by recognising that a document is handwritten or badly scanned, and applying enhanced scanning to it — just like a human reaching for a magnifying glass or a pair of glasses. It enhances how it looks at the page to make sure the document gets read properly.

And if it fails, it flags it. That's the whole point. Automation isn't good if the barrier to entry is nothing — no checks, it just writes. Harold does the checks a human would do. It's your gatekeeper.

It varies — with the data coming in, and with the model. AI at the top end can be incredibly accurate, but it's expensive. The key is the AI recognising when it needs to enhance.

So the honest answer is: with one pass, it can be hit and miss. With checks, a smart approach and a gatekeeping mentality, it can be very accurate indeed. And more importantly, it behaves like a good employee — it flags when it isn't sure.

Accuracy on its own is the wrong thing to measure. An extractor that is slightly less accurate but knows which fields it got wrong is far more useful than one that is confident about everything.

Because it assumes the best case. It's the sales pitch we've all sat through — they throw softball tasks and make the claims off the back of a softball task.

Any extractor can hit 99% on a nicely laid-out PDF invoice. But can it be accurate on a 100-line goods invoice with multiple units of measure and key data hidden inside description fields?

So, as usual, blanket sales statements really depend on your position. If you receive lovely invoices, most claims of 99% are correct. But if you're throwing hardballs, you need an honest extractor — one that flags itself, and lets you create checks that block it from entering bad data.

It's also worth saying plainly: there is no agreed standard for what counts as a hard invoice. That's precisely why the number is always quoted without one.

They throw softball tasks and make the claims off the back of a softball task.

Honestly? Yes. Anyone who says otherwise is not admitting where this technology is.

However, that's missing the point. You can set up a system so that the data you're checking is a quick marking exercise — like a line manager, rather than a full line-by-line re-entry. Do the totals match? Do the line items match the line price? Is the tax the correct amount? Are the terms correct?

If a good OCR knows your rules, it will enforce them and ask you to check for it. It's a great admin. It is not a manager.

It's a great admin. It is not a manager.

Another AI. And then you.

Think of the internal workings as a line in a factory. The first person's job is to extract information. The second person's job is to get that information into your company's logic. The third person's job is to add information to it — ACME Supplies is actually A000001. The final person does the validation maths and the checks.

Ultimately, you're the final person on that line. But all those jobs you used to do are done for you before it reaches you. You check those key figures are correct, and move on.

Food and construction.

These are industries supplying large quantities of ingredients and materials in vast units of measure, with key data often hidden inside a description field.

You could have “6x tomato tins” in the description, and then 10 in the quantity field. So in reality it's 60 tins. What's the price per tin? They don't say. The next line could be “5lb sausages”, and the quantity field contains 10 — so it's actually 50lb. But then what's the price per pound? It's so complex, because it varies line to line, and what you want to know as a customer watching pricing varies line to line too.

It's a lot better to be able to go into a meeting with your supplier with really detailed questions on price increases, rather than a blanket “we noticed it's gone up 5%”. You can say: we noticed tomatoes have stayed the same, but sausages are now 50% more expensive per pound. That data is required. It just isn't easy to extract.

You can say: tomatoes have stayed the same, but sausages are now 50% more expensive per pound.

Three-way matching, always. Never pay an invoice without a goods receipt and a purchase order.

The purchase order says what you agreed to buy. The goods receipt says what actually turned up. The invoice says what you're being asked to pay for. A duplicate invoice fails that test immediately, because there is no second goods receipt and no second purchase order sitting behind it — the goods only arrived once.

This is why duplicate detection built purely on matching invoice numbers is weaker than it sounds. Supplier numbering isn't always unique, references get re-used, and the same document can arrive twice by two different routes — once by email and once in the post. Matching back to the receipt is what actually holds.

Three-way matching, always. Never pay an invoice without a goods receipt and a purchase order.