How we measure accuracy — and why we will not claim 100%
Every tool in this market advertises a field-level accuracy figure, usually 99% or 99.9%. Those numbers are not lies, but they are answering a different question from the one you are asking, and the gap between the two is larger than it looks.
Field accuracy is not statement accuracy
A transaction is about five fields: date, description, money in, money out, balance. A fifty-transaction statement is therefore around 250 fields, and the chance of the whole statement being clean is the per-field rate raised to the power of the field count. At 99.9% per field, only about 78% of fifty-transaction statements come back with no errors at all. At 99%, it is 8%.
To get 99% of fifty-transaction statements perfect you need per-field accuracy of 99.996% — one error in roughly 25,000 fields. Nobody has demonstrated that, and we are not going to pretend we have.
What we report instead
A bank statement carries its own answer key: the running balance column. So rather than quoting a number you cannot check, we re-derive every row from it and report one of three states per row — verified, flagged, or not checkable — along with which whole-statement checks passed and which could not run.
- Verified — the change in the printed balance equals this row’s amount, exactly.
- Flagged — it does not, and we show you the row and the discrepancy.
- Not checkable — payee text, which arithmetic cannot validate. We say so rather than folding it into a percentage.
Why the per-row check is the one that matters
While building this we ran the checker over deliberately corrupted data and found something worth knowing: two equal and opposite errors made the closing balance and the overall total agree perfectly. The extra five pounds entered the ledger and left it again, so both endpoint checks passed on data that was wrong. Only the row-by-row check caught it. A tool that checks just the closing balance will hand you a green light over corrupt figures.
The per-bank numbers
Each bank page carries its own figure: how many statements are in that bank’s test set, what share came back with every row verified, and the date it was last re-tested. When a new statement layout breaks something, that number goes down and the date changes. We would rather publish a falling number than a flattering one.
What we cannot check
Descriptions. Arithmetic can prove an amount and it can prove a date sits in sequence, but nothing can prove a payee name was read correctly. If the payee text matters for your purpose — categorisation, an audit trail, a legal filing — read it. And on any statement with no running balance column at all, the strongest check simply cannot run, which we say on the results screen rather than quietly downgrading what “verified” means.
The benchmark behind this page
The method on this page is tested on a published corpus, with the scoring script and every result — including what it has caught us getting wrong. Read the benchmark and run it yourself.