How ZeroParse does on 40 real bank statements

What “reconciled” means, and what it does not

A statement usually prints facts about itself: an opening balance, a closing balance, sometimes column totals. Reconciled means we added up the rows we extracted and they match those printed figures. It is arithmetic, not an opinion, and you can redo it by hand on your own file.

It is not a claim that every field is perfect. A description could still be truncated or a date read in the wrong order without breaking the totals. Reconciliation catches the errors that move money — a dropped row, a missed digit, a debit read as a credit — which are the ones that matter most and the ones that are hardest to spot by eye.

Roughly a fifth of real statements print nothing checkable at all. Those come back unverified. That is an honest “we cannot tell you”, and we would rather say it than show a green tick that means nothing.

Where this corpus came from, and how it is biased

These are 40 real PDF statements and 6 real CSV/Excel exports, collected from the founder's own accounts and from family and friends who agreed to share theirs. They span 6 currencies, and 14 of the PDFs are credit-card statements rather than bank accounts.

This is not a random sample and we will not pretend otherwise. It is weighted towards Singapore and India, with statements from the UK, the United States, Australia and Brunei alongside them; it is mostly personal accounts, though a small retail business banks in there too; and it contains no statement from a bank that refused to work — because a file nobody could obtain never entered the set. A vendor's own corpus is the weakest form of evidence there is. It is simply more than anyone else in this category currently shows you, and it grows as real files arrive.

The files themselves are never published, and never will be. They belong to real people. What you see below is derived from them by a generator that reads only counts and verdicts and never reads a filename.

Per-file results: PDF

2,722 transactions across 40 files. 34 were read from the page's own text layer; 6 were scans that needed OCR.

File ids are positions in a sorted list, not stable identifiers — they shift when the corpus grows. “card” marks a credit-card statement, where a purchase is exported as a debit so it lands the right way round in QuickBooks and Xero.

Per-file results: CSV and Excel

1,350 of 1,361 source rows mapped into transactions across 6 files. These are parsed entirely in your browser and never uploaded, which is also why this path is weaker at self-checking: it reads column headers, and a header can be missing or meaningless.

The ones we got wrong

Publishing only the wins would make this page marketing. These are the open problems this corpus currently shows.

• One scanned statement comes back suspect. Our own arithmetic disagrees with the balances it prints, and we have not yet closed the gap. It is counted above as a failure rather than quietly dropped from the sample.
• One CSV auto-maps none of its 621 rows. The bank exports its headers literally as Column 1 … Column 7, and auto-detection matches on header text, so it has nothing to go on. Mapped by hand in the app it takes all 621 rows correctly — but the automatic path is what most people will meet first.
• The CSV path computes no reconciliation verdict at all. That is why nearly every CSV above reads unverified. One of them states its own opening balance, closing balance and withdrawal/deposit totals, and its mapped rows match all three to the cent — but we throw that certainty away today rather than report it. A real gap, recorded rather than hidden.

Check us on your own file

You do not have to take this page's word for anything. Drop one of your own statements in — the same reconciliation check runs on it, and tells you which of the three results above your file got, before you export anything. CSV, Excel and OFX files never leave your browser at all.