UK
A reconciliation accuracy benchmark measures one thing precisely: after a bank-statement PDF is converted to a spreadsheet, does the data still balance? Opening balance, plus every credit, minus every debit, should equal the closing balance the bank printed. That identity is the benchmark. When the maths closes, no transaction was lost and no amount was mangled badly enough to break the sum. When it doesn't, something went wrong, and the file is unsafe to post no matter how clean it looks. This article sets out the method for running that benchmark on any converter. It deliberately publishes no headline percentage, because a number without a stated statement set, an error rule and a date is a claim, not a measurement.
Here's the part most accuracy tests miss. The running balance is an answer key the bank already wrote into the document. You don't need a human to hand-key a "correct" version first. The statement checks itself.
What a reconciliation benchmark actually scores
Most accuracy claims you'll read are field-level spot checks. Someone picks a sample of cells, compares each against the source, and reports the share that matched. That tells you how cleanly the tool reads characters. It does not tell you whether the spreadsheet is complete.
A reconciliation benchmark scores something stricter and more useful: completeness and arithmetic integrity at the level of the whole statement. The unit is the statement, and the result is binary. Either the converted lines rebuild the bank's own closing balance, or they don't. Run that across a defined set of statements and the headline metric falls out naturally — a reconciliation pass rate, the share of statements that balanced end to end.
Why does this catch what spot checks miss? Because the most dangerous extraction error leaves no wrong cell to find. If a converter drops a transaction entirely, every remaining cell can be perfect. A field-level audit sampling those cells sees nothing wrong. The spreadsheet simply has fewer rows than the PDF, and only the running balance reveals the gap. A dropped 640 supplier payment doesn't announce itself; the closing balance just won't tie, and that mismatch is the only signal you get.
So the two approaches answer different questions. Field accuracy asks "are the cells right?" Reconciliation asks "is anything missing, and do the amounts add up?" The second question is the one that protects your accounts.
The running-balance identity, stated plainly
Every bank statement carries the same arithmetic backbone:
- Opening balance — the figure carried in from the previous period.
- Movements — every credit (money in) and every debit (money out), in order.
- Closing balance — opening, adjusted by all the movements.
Most statements also print a balance after each individual line, which is a stronger version of the same check: you can reconcile transaction by transaction, not just end to end, and pinpoint the exact row where the maths first diverges.
This identity is what makes reconciliation an objective ground truth. Compare it with the usual way of scoring a converter, where a person types out the true statement so the output can be diffed against it. That reference is slow to produce, subjective at the edges, and impossible to scale past a handful of files. The running balance needs none of that. The bank already did the arithmetic and printed the result. A reconciliation check just rebuilds the sum from the extracted lines and sees whether it lands on the same closing figure.
Export Bank Statement runs this check on every conversion. It reconstructs the running balance from the extracted transactions and compares it against the figures on the statement. Agreement means every transaction is accounted for. Disagreement means the statement is flagged, so you look before you trust it. That's the difference between a file that looks fine and a file that's provably complete.
Why reconciliation beats field-level spot checks
A field-level accuracy figure is the easiest number to publish and the easiest to inflate. Here's why it flatters, and why a reconciliation pass rate is the harder, more honest signal.
Field-level spot check | Reconciliation benchmark | |
|---|---|---|
Unit measured | Individual cells | The whole statement |
Catches dropped rows | No — a missing row has no wrong cell | Yes — the balance won't tie |
Catches amount errors | Only if the cell is sampled | Yes — any amount error shifts the sum |
Needs a hand-keyed reference | Yes | No — the bank printed the answer |
Scales to many statements | Poorly | Yes — the check is automatic |
Risk of a flattering result | High — sampling hides the rare bad row | Low — one bad row fails the statement |
The deciding row is the second one. Dropped transactions are the failure that quietly does the most damage, and they are exactly the failure a cell-by-cell audit is blind to. We've seen statements where every visible figure was correct and the file still wouldn't reconcile, because a single line had vanished at a page break. No field check would have caught it. The balance did, immediately.
Reconciliation isn't a perfect, all-seeing metric, and a benchmark that pretends otherwise loses credibility. Two limits are worth stating outright:
- It proves completeness and amount integrity, not description quality. A merchant name read as "AMZN Mktp" instead of "Amazon" still reconciles, because the sum only sees numbers. Descriptions need their own check.
- Two errors can cancel. A line read 10 too high and another read 10 too low will still balance. It's rare, rarer still on a long statement, but an honest benchmark names it rather than claiming the check is infallible.
Neither limit undoes the point. Reconciliation is the strongest single objective signal, it scales, and it catches the one error that hurts most.
How to evaluate whether a converter reconciles
If you're benchmarking converters yourself, or reading someone else's results, these are the things that separate a real reconciliation test from a marketing line. Use it as a checklist.
Criterion | What a credible benchmark does | Red flag |
|---|---|---|
Defined statement set | States how many statements, which banks, which countries, text PDFs versus scans | "Reconciles every time" with no sample described |
Pass rule | Defines the tolerance — exact match, or a stated rounding allowance | "Accurate" left undefined |
Pass rate reported | Gives the share of statements that reconciled end to end | A vague claim with no rate |
Failure transparency | Shows what the tool does when a statement doesn't balance | Silent failures, or a quiet "best guess" |
Document mix | Separates text PDFs from scanned/OCR statements | One blended figure hiding scanned-doc weakness |
Date and version | States when it ran; parsers and OCR change | Undated claims that could be years old |
The most revealing test isn't in the table, though, and it's free: feed the converter your hardest real statement and see what it does when the numbers don't tie. A tool that silently outputs whatever it read, balanced or not, is asking you to trust it blind. A tool that flags the mismatch is doing the job. The behaviour on failure tells you more than any pass-rate boast.
Three things genuinely move the reconciliation result, and they're worth knowing before you test:
Page breaks. Long, multi-page statements are where rows get dropped or duplicated. A subtotal carried across a break, a transaction split over two pages, a repeated header read as data — each can break the closing balance. This is reconciliation's home turf, because a row lost at a page break leaves no wrong cell behind.
Number formatting. Decimal commas versus points, thousands separators, currency symbols inside the cell, trailing "CR" or "DR" markers. Any of these can be misparsed, turning 1,234.56 into 1.23 or flipping a debit into a credit. Each one shifts the sum, so the reconciliation check is built to surface exactly these. For the full catalogue of what goes wrong, see common reconciliation errors.
Combined debit/credit columns. Some banks print money-in and money-out in one column with a sign rather than two separate columns. Misread the sign and the amount lands on the wrong side of the ledger — the figure is right, the direction is wrong, and the balance won't close.
For the manual side of the same discipline, the bank reconciliation checklist walks through verifying a statement by hand.
Where the tool fits — and where it stops
Export Bank Statement converts bank-statement PDFs to clean Excel and CSV, reads scanned and photographed statements via OCR, and runs the running-balance reconciliation on every file so you know whether the output is complete before you rely on it. It also exports in the native bank-import CSV format for Xero, QuickBooks and Zoho Books.
The honest boundary: it does not push transactions into your accounting software through a live bank-feed API — that route needs partner certification we don't claim. The workflow is convert, confirm it reconciles, then import the CSV. You import data you've already seen verified, rather than trusting a sync you can't inspect.
CTA: Run your own reconciliation benchmark — convert your toughest statement and check whether it balances. The per-file result is your pass rate, measured on the statements you actually handle.
Frequently asked questions
What is a reconciliation accuracy benchmark?keyboard_arrow_down
It's a structured measurement of whether a converted bank statement still balances against its own running total. The test rebuilds opening balance plus every credit minus every debit and checks that it equals the printed closing balance, across a described set of statements. The headline metric is the reconciliation pass rate — the share of statements that balanced end to end — reported with the sample, the pass rule and a date.
How is reconciliation accuracy different from extraction accuracy?keyboard_arrow_down
Extraction accuracy measures whether individual cells were read correctly. Reconciliation accuracy measures whether the whole statement still adds up. The gap matters because a dropped transaction leaves every remaining cell correct, so a field-level check passes while the statement is incomplete. Reconciliation catches that missing row because the closing balance won't tie.
Why use the running balance as the ground truth?keyboard_arrow_down
Because the bank already printed the answer. Opening balance plus every transaction must equal the closing balance, so the statement carries its own answer key. Scoring against it needs no hand-keyed reference copy, it's objective, and it scales automatically across a large test set — which is why it's the strongest single signal of a converter's completeness.
Can a statement reconcile and still contain errors?keyboard_arrow_down
Yes, in two narrow cases. A misread description still reconciles, because the running balance only checks amounts, so description quality needs separate scoring. And two equal-and-opposite amount errors can cancel out — rare on a long statement, but possible. Reconciliation is the strongest objective check, not a guarantee against every error type.
What reconciliation pass rate should a converter have?keyboard_arrow_down
There's no single right number to quote, and any figure stated without its sample, pass rule and date should be treated with suspicion. What matters more is the method behind the rate and the tool's behaviour on failure. A converter that flags statements that don't reconcile is more trustworthy than one claiming a high pass rate but outputting unbalanced files silently. Test it on your own hardest statements and read the per-file result.
Does Export Bank Statement publish a reconciliation pass rate?keyboard_arrow_down
No, by choice. A blended pass rate is misleading without the statement set, document mix, pass rule and date behind it, and the same tool reconciles a clean text PDF more readily than a low-resolution scan. Instead, the product gives you a per-statement reconciliation result — an objective pass or fail on your specific file — which is more useful than a generic figure to take on faith.
Try it on your own statement
Clean Excel/CSV, with every transaction checked to balance.