The 30-second version
Most converters extract transactions and stop. Reconciliation — the step that verifies the numbers add up — is what catches silent errors before they reach your accounting software. This post explains what reconciliation actually checks, the three verdicts you should expect, why "99% accuracy" isn't enough on its own, and what to do when the verdict comes back red.
Most bank statement converters do one job: they look at a PDF and produce a table. That's extraction. It is genuinely useful — and it's also where most tools stop. The harder problem starts the moment you try to use that table.
Because here's the thing nobody tells you when you're shopping for a converter: when an AI or a parser misreads a single digit on a single row of a 200-row PDF, every downstream process silently goes wrong. Your QuickBooks reconciliation breaks. Your management accounts show the wrong cash position. The auditor finds it three months later. You spend an afternoon hunting down which row of which statement is off.
Reconciliation is the bit that prevents that. And it's the bit most tools skip.
A converter that doesn't reconcile is a converter that confidently hands you wrong numbers — and trusts you to spot them.
What "reconciled" actually checks
At minimum, a reconciled statement passes two tests:
- Bookend totals.The opening balance plus the sum of every transaction must equal the closing balance (within a couple of cents for rounding). If it doesn't, at least one transaction is wrong, missing, or duplicated.
- Chain integrity.If the bank prints a running balance after each row, every row's balance must equal the previous balance plus its own amount. The first row where the chain breaks is — almost always — the row that was misread.
These tests aren't glamorous. They're also why our pipeline catches errors that pure extraction tools quietly ship through.
A worked example: how a chain break pinpoints the misread row
Imagine a five-row statement. The bank prints an opening balance of 1,000.00and a closing of 1,242.10. Five transactions. The extractor pulls this:
| # | Date | Description | Amount | Balance |
|---|---|---|---|---|
| 1 | 2026-04-02 | Salary | +2,000.00 | 3,000.00 |
| 2 | 2026-04-05 | Rent | −1,200.00 | 1,800.00 |
| 3 | 2026-04-12 | Tesco | −42.10 | 1,757.90 |
| 4 | 2026-04-18 | Utilities | −115.80 | 1,632.10 |
| 5 | 2026-04-26 | Refund | +10.00 | 1,242.10 |
Row 4's printed balance (1,632.10) doesn't equal row 3's balance minus row 4's amount (1,757.90 − 115.80 = 1,642.10). The chain breaks here. The reconciler highlights row 4 — and an accountant looking at the source PDF sees the amount was actually 105.80, not 115.80. One typo in the OCR. Without the chain check, that error reaches QuickBooks and stays there.
Notice row 5 looks fine on its own (1,632.10 + 10.00 + the extractor having drifted ten units sets up the closing at 1,242.10 incorrectly — but row 4's break is where the diagnostic actually fires).
Why the chain-break rule is surprisingly powerful
On a 100-row statement with a running balance, a single misread digit creates a break at exactly that row — and every row after stays internally consistent with the break. That makes the original misread pinpointable, not just "somewhere in the file". Tools without a chain check have no way to localise the error; they can only tell you something's off, not what.
The three outcomes a reconciler should produce
- Reconciled. Bookends match exactly, chain is intact, no row is flagged. Safe to import into accounting software without review.
- Reconciled with flags. Bookends match, but at least one row is uncertain (low confidence, ambiguous date, unusual format). Review only those rows.
- Needs review.Bookends don't match. Treat the output as a draft. Investigate before importing.
On StatementEdge, you see one of those three states as a green / amber / red badge on every conversion. The reconcile state also flows into the exported file — your CSV header carries it, your .qbo carries it, your Xero CSV carries it. The accountant downstream sees the verdict, not just the data.
When reconciliation is genuinely hard — the formats that fight back
Not every bank makes this easy. A few format patterns turn reconciliation into a nontrivial extraction problem before you can even start checking the maths:
- Money-In / Money-Out columns (most UK and Irish banks). The extractor has to pick which column to treat as positive and which as negative before any sum is meaningful. Get that wrong and the chain is wrong from row 1.
- Dr / Cr suffix notation(German Soll/Haben, Indian Dr/Cr, Brazilian Débito/Crédito, Mexican Cargo/Abono). The amount is unsigned; the sign comes from a separate column or a one-letter suffix. Strip the suffix and you've lost the sign.
- Multi-currency segments (HSBC, common business accounts in Singapore, UAE, Hong Kong). The PDF interleaves transactions in two currencies. Reconciliation has to happen per currency, not globally.
- Mid-statement balance resets (some Indian co-operative banks and older corporate accounts). The running balance restarts at a sub-period. A naïve chain check fires false positives at every reset boundary.
- Scanned PDFs from older corporate accounts. No text layer at all — every row goes through OCR, which has different failure modes than text extraction. Reconciliation here is what saves you from a model that's confidently wrong about a column edge.
Why this matters more than "higher accuracy"
Vendors quote accuracy numbers — 95%, 97%, 99%. Those numbers are interesting but misleading on their own. 99% accurate on a 200-row statement is roughly 2 wrong rows. Without reconciliation, you have no way to know which 2 they are. With reconciliation, the system tells you the moment a number doesn't add up.
Accuracy is necessary; reconciliation is the safety net. We think both are table-stakes. If your current converter doesn't do the second one, you're carrying the risk yourself — every import becomes a manual cross-check against the source PDF, which defeats most of the time you were trying to save.
What to do when you get a "needs review" verdict
Don't throw the file away. A "needs review" result is still a useful starting draft. The pipeline already did 95% of the typing for you; the manual step is finding which rows broke the chain and what they should have been. The workflow:
- Open the exported CSV alongside the source PDF. The reconcile badge flows through to the file header.
- Find the first flagged row. Flagged rows are highlighted in the web UI and tagged in the exported file. The first one is almost always the earliest break in the chain.
- Fix that one cell.Re-run the chain math from there. If the remaining chain reconciles, you're done with one fix. If a second break appears further down, you have a second misread; repeat.
- Save and re-import.Most "needs review" conversions resolve to clean after fixing a single row.
Don't overwrite the reconcile badge by accident
If you edit the CSV and remove the reconcile-status header line, downstream tools won't know the file was once flagged. Keep the badge in place even after manual fixes so the next accountant looking at the file knows it's been touched.
What an accountant should look for in any converter
- A visible verdict on every conversion — not just the table.
- Flagged rows highlighted in the UI, not buried in a sidebar.
- Verdicts carried through to the exported file (CSV header, QBO memo, Xero notes).
- A "needs review" output that's still useful as a starting draft, not an error message.
- Locale-aware bookend parsing — the converter has to find your opening and closing balance reliably, which is harder than it sounds on multi-page statements.
- Per-currency reconciliation on multi-currency statements, not just one global sum that hides the actual error.
You can test all six against a real statement, right now — drop one onto our converter. The reconciliation badge is the first thing you'll see on the results page.
Further reading
- Why your QuickBooks import keeps failing — the most common downstream pain that reconciliation prevents.
- AIB, Lloyds, Barclays → Xero: the 2026 workflow — per-bank format traps that make reconciliation worth its weight.
- How to choose a bank statement converter — broader evaluation checklist.
- Our security posture — how we handle the actual PDFs you upload before, during, and after conversion.