Reconciliation that names the row
Extraction is imperfect everywhere, in every tool, including this one. What separates them is what happens next. Five checks run on every conversion, and anything that does not add up is flagged at the row rather than averaged into a total.
The five checks, strongest first
They run in order of how much evidence each provides, and each one is skipped rather than failed when the statement does not carry the data it needs. That distinction matters more than it sounds: "we could not check this" and "this does not add up" mean completely different things to the person signing off the books, and collapsing them into one amber warning is how a tool teaches people to ignore its warnings.
- Row-by-row running balance. For every consecutive pair that both print a balance: the previous balance plus this row’s amount must equal this row’s balance. The strongest check there is, because it localises the error to a single row.
- Page subtotals, where the statement prints them. Catches a row lost at a page boundary even when no running balance exists.
- Statement balance. Opening plus the net of every transaction must equal the printed closing balance.
- Printed totals. Total credits and total debits as the bank printed them, against the sum of what was extracted.
- Transaction count, where the statement states one. The cheapest check and the fastest way to notice a dropped row.
Zero tolerance, deliberately
Every amount is held as an integer number of minor units — cents, pence, paisa — and never as a floating-point number. So the arithmetic is exact, and the tolerance for a mismatch is zero rather than a cent.
Tools that work in floating point have to allow a small tolerance because their own arithmetic drifts. That tolerance then hides real errors of the same size. Keeping the numbers exact removes the need for it.
What a failure looks like
The row is highlighted in the grid, and clicking it opens the page it came from with the printed line marked. You see what the bank actually printed beside what was read from it, which turns "the balance is out by 198,000" into "row 47 says 22,000 and the statement says 220,000" in about two seconds.
That pairing — the check that finds it and the source line that proves it — is the whole product. Neither half is much use alone.
Where credit cards fit
Most credit card statements have no running balance column at all, so the strongest check cannot run. That is exactly why there are five rather than one: the statement balance and the printed totals still catch a missing or misread transaction, just without localising it to a row.
The result says which checks ran and which were skipped, so a card statement is never presented as more thoroughly verified than it was.
What reconciliation cannot tell you
Arithmetic only. Verifies that amounts, balances and totals agree. Does not verify descriptions or dates, and cannot detect two errors that cancel out. A transposition that turns a -50 and a +50 into a +50 and a -50 reconciles perfectly and is still wrong. This is a very strong detector, not a guarantee, and the same words appear in the app and in the note written into your exports — because a marketing page that overstates what the product proved is worse than no page.