What the Reconciliation Checks Actually Catch (No Invented Accuracy Number)

By Tarun Vashishth · Published 2026-08-25

This page was originally planned as a data piece — real failure rates for each reconciliation check, drawn from real-world statement volume. It isn't that, and it's worth explaining why rather than filling the gap with a number.

The honest position: there isn't production-scale data yet

This tool doesn't collect any data from real conversions — it can't, by design: nothing is ever sent anywhere, which is the entire point covered on the privacy page. That means there's no server-side log of how often each reconciliation check fails across real statements in the wild, because building one would require exactly the kind of data collection this tool is built to avoid. A converter that both promises never to see your data and claims to have measured its own real-world failure rate is claiming two things that can't both be true. So instead of inventing a number to fill this page, here's what's actually verified.

What's tested today

The parser and reconciliation engine are covered by a suite of automated tests running against synthetic statement fixtures — constructed PDFs with known-correct answers built in, including deliberately broken cases (a statement engineered to fail the balance-chain check, for instance) to confirm the check actually catches what it's supposed to. This verifies the logic is internally correct: given a statement matching a known layout, the parser extracts the right transactions and the reconciliation checks correctly pass or fail. It does not measure how often real-world statements — with scan artifacts, unusual formatting, or layout variants the tests don't cover — trip up the parser in ways that produce a wrong answer instead of a caught error.

What "verified" means on this site, concretely

The supported banks page lists five banks with dedicated layout profiles, each with a last-verified date. "Verified" there means the bank's fingerprint text and section headings have been checked against that bank's actual statement layout as of that date — not that a large volume of real statements from that bank have been processed and measured. Any bank not on that list still runs through the geometric, bank-agnostic parser, which is exercised by the same fixture-based tests but has no bank-specific verification at all.

Why the reconciliation checks matter more because of this gap

Precisely because there's no measured accuracy rate to rely on, the reconciliation checks exist to catch errors on your specific statement, every time, rather than asking you to trust a general number. A statement that fails the opening-balance-plus-transactions-equals-closing-balance check tells you something is wrong with that conversion — regardless of what any aggregate accuracy figure would have claimed. See the verification guide for the full explanation of why this is a stronger guarantee than an accuracy percentage in the first place.

What would change this

If this tool ever adds anonymous, opt-in, aggregate error reporting — with informed consent and no statement content ever transmitted — that would be the mechanism to eventually publish real numbers here. Until and unless that exists, this page will stay what it is: an explanation of what's actually known, rather than a marketing number standing in for it.