The Accurate Bank Statement Converter

Most bank-statement converters fail quietly. A PDF has no real table inside it, just text positioned on a page, so any tool reading it has to reconstruct rows from coordinates — and every so often a row gets dropped, two rows get merged, or a smudged character gets misread. The output file still opens fine, the columns still line up, the numbers still look like numbers. Nothing about the file tells you a row is missing. That is the actual risk with PDF extraction: not that it fails loudly, but that it fails plausibly, and a plausible-looking wrong file is more dangerous than an obviously broken one, because nobody double-checks it by hand.

A row looking right and a row being right are different claims, and only one of them can be checked by a machine. The one thing a converter can actually verify, without knowing your bank or your account, is arithmetic: opening balance plus credits minus debits must equal the closing balance the statement itself declares. If a row was dropped, duplicated, or misread in a way that changes its amount, that equation stops holding — reliably, every time, regardless of how convincing the rest of the page looks. So this tool recomputes that equation itself, on your data, rather than asking you to trust the extraction. For a PDF, it walks the running balance printed after every transaction line and checks each step, naming the exact row where the next printed balance doesn't match. For BAI2, CAMT.053 and MT940 files, which declare only an opening and closing balance rather than one after every line, it runs the same check once per account and names the account and the exact difference. Either way, a mismatch shows up as a red panel with a specific row or account and a specific amount — not a vague "please review" notice.

We do not claim perfect extraction. No text-positioning engine and no OCR model is immune to a smudge, an odd font, or a statement layout it has never seen, and claiming otherwise would just be marketing. What we claim instead is narrower and, we think, more useful: you will know when the result is wrong, because the balance check is arithmetic, not a confidence score or a visual impression. Low-confidence OCR words are dropped from the output rather than silently guessed at, so an unreadable character shows up as a gap in the balance check rather than a wrong digit sitting quietly in your ledger. That is the difference this page is built around — most converters ask you to trust them; this one hands you the proof, or tells you exactly where it's missing.

This also means the balance check can pass on a file that still has a small extraction error in it — if, say, two mistakes happen to cancel out in the same account, or a mismatch falls in a field the check doesn't look at, like a description column. A passing check is strong evidence the numbers are right, not absolute proof, and we'd rather say that plainly than let a green checkmark imply more certainty than it earns. For anything where the exact figures matter — tax filings, audits, client trust accounting — treat a passed balance check as a reason to move forward with confidence, and a failed one as a reason to stop and look at the source file before you do anything else with the result.