The usual framing is a contest: which one makes fewer mistakes. It's the wrong question, partly because the answer depends entirely on the document, and partly because the two make completely different kinds of mistake.
The more useful comparison is about where the human effort ends up, and what each approach does when it's unsure.
First, a distinction that matters
"OCR" gets used to mean two different things, and conflating them causes most of the disappointment in this area.
Optical character recognition turns pixels into characters. It looks at a shape and decides it's a 7. That's largely a solved problem on clean print, and has been for years.
Extraction decides that a particular number on the page is the invoice total rather than the subtotal, the VAT, a line amount, or last month's balance. That requires understanding the document's structure, and it's where the actual difficulty lives.
A tool can have excellent OCR and poor extraction. It will read every character on the page correctly and still put the wrong number in the total field. When people say "we tried OCR and it didn't work", this is usually what happened.
Modern extraction doesn't really work by reading characters and applying rules — it interprets the layout. Which is why performance on an unfamiliar supplier's template is much better than it was a few years ago, and why template-based tools that needed configuring per supplier have largely been superseded.
What each is genuinely better at
Manual entry is better at:
- Judgment. Deciding this invoice belongs to the Manchester job, or that this VAT isn't recoverable. That's business knowledge, not document reading.
- Recognising what a document is. An experienced bookkeeper spots a statement, a pro-forma or a duplicate immediately, often from a glance.
- Genuinely bad inputs. A crumpled photo of a handwritten receipt taken in a van. A person can usually make it out. Extraction gets less reliable exactly where legibility drops.
- Context from outside the document. Knowing this supplier always bills a month late, or that this one was disputed.
Automated extraction is better at:
- Not getting bored. Accuracy on the fortieth invoice equals accuracy on the first. Human error rates climb through a long session, and the errors cluster near the end.
- Long strings. IBANs, account references, VAT numbers. These are where manual entry is weakest, because there's no meaning to check against — the eye has nothing to catch on. Transposed digits in a bank detail are a classic manual error, and a deliberately altered one is worse.
- Consistency. The same field extracted the same way every time. Two people entering the same document may not agree on what goes in the reference field.
- Speed and volume. Obviously, and it's the least interesting advantage.
- Knowing when it's unsure, which is the one worth dwelling on.
The part that's usually missed
A person entering an invoice knows when they're guessing — but that knowledge stays in their head. It doesn't reach the ledger. The record looks identical whether they were certain or squinting at a fax.
Extraction models produce a confidence score per field as a by-product of how they work. That information can be surfaced. So you can have a record that says: certain about the total, certain about the date, not certain about the bank account.
That's genuinely new, and it's more useful than a small difference in raw accuracy. It turns checking from "re-read the whole document" into "look at this one field".
It only helps if the tool actually shows it. Most average the per-field scores into a single document figure, which throws away the part that was useful — one number for a document tells you nothing about which value to check.
The errors are shaped differently
This is the real difference, and it's why "which is more accurate" doesn't get you anywhere.
Manual errors are random and plausible. A transposed digit. The right value in the wrong field. A supplier's previous balance entered as the total. They're rare, and each one looks completely normal in the ledger — nothing marks it out for review.
Extraction errors are systematic and often flagged. If it misreads one supplier's layout, it will misread that layout consistently, which makes the problem findable and fixable. And a well-built tool tells you where it was unsure, so a portion of its errors arrive pre-identified.
A rare invisible error can easily be worse than a more frequent visible one. A flagged uncertain field costs you thirty seconds. An unflagged wrong bank account costs you the payment.
The honest comparison
The one worth doing isn't automation against your current process at zero automation. It's automation against the work that's left:
- Reviewing fields the tool flagged
- Handling documents that read badly
- Coding decisions for unfamiliar suppliers
- Everything that isn't an invoice — statements, credit notes, duplicates
- Approvals, which don't change either way
That residual is real, and any comparison ignoring it is overselling. The gain is that the routine majority stops needing a person, and attention concentrates on the exceptions — which is where it was always most valuable.
When manual entry is still the right answer
Genuinely, sometimes it is.
Low volume. Under about twenty invoices a month, the setup and review overhead probably isn't worth it. Time a batch before assuming otherwise.
Highly unusual documents. If most of your purchases come as handwritten dockets, expect a lot of exceptions.
Very few suppliers, all identical. Ten invoices a month from the same five suppliers, same format, same coding, is already quick — and supplier defaults in your accounting package will get you most of the remaining benefit for nothing.
How to actually test it
Not on the vendor's sample documents. On yours, including the awkward ones.
Take twenty real documents — a photograph, a multi-line invoice, a credit note, a statement, something in a language you don't read — and run them through. Then count one number:
How many could you post without opening the original?
That's the comparison. It accounts for accuracy, confidence reporting and residual work in a single figure, and it's specific to your documents rather than someone else's average.
Cribble scores every field separately and flags the ones it isn't certain about, so what needs checking is a short list rather than the whole document. Reads PDF, JPG, PNG and XML, tested across English, French and German. Send us your worst three if you'd like to see the output.