How accurate is it?
Every converter in this category claims 99-point-something percent accuracy and none of them show how they measured it. So here is the method instead of the number: every conversion is verified against the statement's own printed balances, a statement whose math doesn't close comes back marked "review required" with the failing rows highlighted, and a regression suite blocks any change that would extract a single wrong amount or date from the test corpus.
The claim worth making isn't that we're never wrong. It's that when we are, you find out before the numbers reach your books.
The two checks that run on every conversion
Check A — the period
Opening balance + the sum of every extracted transaction must equal the closing balance printed on the statement. This catches a dropped row, a duplicated row, a sign flip, or a misread digit anywhere in the document — any of them moves the total.
Check B — the row chain
For every row that prints a running balance: previous balance ± this amount must equal this row's printed balance. Because the chain breaks precisely where the error is, this turns "something is wrong somewhere" into "row 34 is wrong" — which is what makes a targeted re-extraction, and a one-line human fix, possible.
A statement that fails either check is escalated to a stronger model for the affected pages, then re-checked. What still doesn't close is returned flagged. It is never returned as a clean success.
What the regression suite enforces
5 statement layouts, 144 transactions with known ground truth, run on every change to the extraction code. The suite asserts exact amounts and exact dates for every row — not a tolerance, an exact match — and separately asserts that a deliberately corrupted statement is never reported as reconciled.
| Layout | Rows | What it tests |
|---|---|---|
| plain-balance-col | 24 | Standard layout with a running balance column and minus-sign negatives. |
| parens-negatives | 18 | Negatives printed as (1,234.56) — the format that flips signs in naive parsers. |
| drcr-markers | 20 | DR/CR suffix markers instead of signs, with dates missing the year. |
| no-balance-col | 22 | No running balance column, so only the period check can verify the total. |
| multipage-60 | 60 | 60 transactions across multiple pages with year-less dates. |
These are generated statements with known answers, which is what makes exact assertions possible — and also what limits the claim. They test the parser against layout variation, not against the full mess of real-world bank formatting.
What we haven't measured yet
- A real multi-bank benchmark. Accuracy per bank, on genuine statements, with hand-verified ground truth. This is the number the category actually needs and nobody publishes it, including us — yet.
- Scanned-document accuracy. Scans go through vision extraction and the same reconciliation gate, but we have no published error rate for them.
- Head-to-head comparisons. Not run. A comparison worth reading needs identical inputs across every tool, and we haven't done that work.
Those gaps are listed here on purpose. A trust page that only lists strengths isn't a trust page.
Questions people ask
- How accurate is this bank statement converter?
- On the regression corpus it extracts every transaction with exact amounts and dates, and that is enforced on every code change rather than measured once. The more useful answer is that accuracy isn't the number to ask about: what matters is whether a converter can tell you when it got something wrong. Every conversion here is checked against the statement's own printed balances, and one that doesn't add up is returned marked for review with the failing rows highlighted.
- Why don't you publish a 99.x% accuracy figure?
- Because an unqualified percentage isn't a measurement — it doesn't say on which banks, which layouts, whether scans were included, or how errors were counted. Every tool in this category publishes one and none publish their method. A figure we can't show the working for would be marketing, so we publish the method and the checks instead.
- What happens when extraction gets a number wrong?
- The balance chain breaks at that exact row, which is what makes the error findable. Check B compares every row against its printed running balance, so a misread digit doesn't just fail the total — it points at the row that caused it. The pipeline then re-extracts the affected pages with a stronger model, and anything still unresolved is flagged for you rather than shipped silently.
- Is a reconciled statement guaranteed correct?
- It's strong evidence, not a proof. Reconciliation catches any error that changes a total — a wrong digit, a dropped row, a doubled row, a sign flip. It cannot catch an error that preserves the arithmetic, such as a garbled description or two transactions swapping dates within the same balance chain. That's why the transactions are shown on screen for review rather than downloaded blind.
- How do you measure accuracy on scanned statements?
- Honestly: we don't have a published scan benchmark yet. Scans go through vision extraction and face exactly the same reconciliation gate, so a bad scan read fails the balance check the same way a bad text read does — you find out. Building a real multi-bank scan benchmark is on the roadmap and this page will carry the results when it exists.
- Have you compared this against other converters?
- Not yet, and we'd rather say so than publish a comparison table we made up. A fair comparison needs the same statements through every tool with a hand-verified ground truth, which is real work. When it's done it'll be published here with the source statements described.
Related: what happens to your file and what it costs.