Ask a document-extraction vendor how accurate the software is and you will usually get a percentage. It is a reasonable thing to ask and an almost useless thing to receive, because it answers a question no examiner has ever had at their desk.
The question at the desk is narrower and far more practical. The statement doesn’t balance. Which transaction is wrong?
How a tool answers that — or whether it can answer it at all — is the most useful thing you can learn about it, and it rarely appears on a feature list.
01A total that doesn’t agree is not a finding
Most tools in this category verify at the level of the statement. They total the transcribed transactions, compare that total against the statement’s own, and report whether the two agree.
When they don’t agree, you have learned something real: there is an error. You have not learned where it is. Somewhere among that statement’s transactions a figure came through wrong, and the work of locating it has quietly been handed back to you — which is the work you bought software to avoid. On a production running to twenty statements, that happens twenty times.
The accuracy percentage has the same shape of problem, with an additional one on top. It is produced by the same system that produced the reading, which makes it a self-assessment: software that reads a 3 as an 8 has no independent means of discovering that it did. The score describes how ordinary the answer looked, not whether it matches the ink on the page.
It is worth being precise about what that number measures, because it has changed over the years and the change is often mistaken for progress. Early OCR scored individual characters — how sure the engine was that a particular glyph was a 3 rather than an 8. Current engines are neural and report at coarser units: a word, a line, a table cell, an extracted field. The mechanism is identical. The model emits a probability about its own output, and nothing outside the model is consulted.
There is a documented complication on top of that. Neural networks tend toward overconfidence — the probabilities they report run systematically higher than their measured accuracy, which is why calibration remains an active research problem rather than a settled one. A high score is not a strong guarantee that a value is right. It is a weak signal wearing the clothes of a measurement.
02Every statement carries its own proof — at different resolutions
A bank statement is unusual among documents in that it arrives with arithmetic already printed on it, published by the bank before any software touched the file. That arithmetic is an external reference. It wasn’t generated by the extraction process, so the extraction process cannot flatter itself against it.
What varies — and what almost nothing in this category accounts for — is the resolution at which a given statement provides it.
The generous case. A balance is printed on every transaction line, so each transaction is verified on its own, independently of every other transaction around it. When one is wrong, that transaction is what gets flagged. There is nothing left to narrow down.
No line balances anywhere. Instead, a table at the end of the statement lists one balance per day — a single figure for that date, whether the day held one transaction or nine. Every transaction in the body of the statement sits there with no balance of its own.
The second format is extremely common, and it is the one that usually defeats verification. Faced with it, the ordinary response is to treat the daily table as summary decoration and fall back to checking the statement as a whole — which returns you to a total that disagrees and no idea where.
03The daily balance isn’t a summary. It’s a constraint.
A day’s closing balance is a fact the bank committed to. Every transaction dated to that day has to be consistent with it: taken together, and applied to the previous day’s close, they must produce exactly that figure. One number, published by the bank, that all of that day’s transactions are jointly answerable to.
That is enough to verify every transaction on the day, and eFraud Investigator uses it that way. Transactions are grouped to their dates, ordered, and tested as a unit against the balance the bank printed.
The result differs from the running-balance case in one respect worth stating precisely. Where a balance is printed on each line, the offending transaction itself is flagged and there is nothing further to narrow down. Where only a daily balance exists, what is flagged in red is the daily balance — that day’s transactions are answerable to it jointly, so the group is what the examiner scrutinizes. A few lines sharing one date, instead of a statement.
Doing this reliably is the genuinely difficult part, and it is invisible from the outside. Real banks disagree about date conventions, posting order, how holds and reversals appear, where the daily table sits, and what it is called. Making all of that resolve into a dependable per-day check is involved engineering. On screen it looks like nothing at all: a day that ties, or a day marked in red.
Verifying by statement
- Compares one total against another
- Reports that something is wrong
- Scope of the answer: the statement
- Hands the search back to the examiner
Verifying by transaction
- Tests transactions against the balances the bank printed
- Reports where it is wrong
- Scope of the answer: one transaction, or one day
- Takes the examiner to the row
04The error that reading cannot find
Per-day verification catches something proofreading structurally cannot: the transaction that was never captured.
Checking transcription by eye means comparing what is on the screen against what is on the page, line by line. That method can find a figure that is wrong. It is very poor at finding a figure that is absent, because nothing on the screen draws attention to a line that isn’t there — and an examiner working through a production of statements is reading for errors, not for absences.
A day that will not tie while every transaction on it is correctly transcribed is telling you something precise: one is missing. That is the signal, and without a per-day constraint there is nothing to produce it.
05Where the correction happens decides whether it holds
Locating the problem is half the work. The correction is the half that has to survive examination later, and it is usually designed as an afterthought — a highlighted row in a grid of values, detached from any document.
Corrected that way, the fix is an assertion. You believe you read the page correctly. Nothing records which page you were looking at when you decided.
In eFraud Investigator the correction happens in front of the evidence. The original PDF page sits on the left; your transaction data sits on the right. You read the actual page and make the change against it — any field on the transaction, not just an amount, and you can add a transaction that was missed entirely. Save it, and the change is written to a tamper-evident audit trail: what changed, who changed it, and when.
The correction stops being something you remember doing and becomes something you can produce.
06Three questions worth asking
These sit underneath question one of our seven-question evaluation guide, and they are worth putting separately, because vendors answer them very differently.
- At what level does the software verify its own reading — the statement, or the individual transaction?
- When a statement prints no running balance, what does the software use instead? Ask to see it run on a Daily Balance statement.
- When something is wrong, what am I looking at while I correct it, can I correct any field, and can I add a transaction the software missed?
Bring a real statement to that conversation rather than taking the answers on description. These are all things you can watch happen.
07The short version
An accuracy percentage is the software’s opinion of its own work, and a statement-level reconciliation tells you only that an error exists somewhere in that statement. The statement itself carries better: balances the bank published — on every transaction line in some formats, and once per day in others. Used at that resolution, the answer stops being something is wrong and becomes this transaction is wrong, or this day is — including when what’s wrong is a transaction that isn’t there at all. Then the fix happens beside the page it came from, and goes on the record.
