How to check a bank statement conversion is correct
Three checks you can run on any converter's output, what each one cannot catch, and a statement to test with.
A converter that is right most of the time is the difficult case. If it were wrong every time you would stop using it. Because it is usually right, you keep the output and check it, and checking every line by hand is the work you were trying to avoid.
So the useful question is not how accurate a converter is. It is whether it can tell you when it got something wrong. These are the checks that answer that, and you can run them yourself on output from anything.
Check 1: the running balance chain
Most statements print a balance beside every line. That column is a signature the bank has already computed for you. Each balance should equal the one above it plus the amount on that row, and if it does not, one of the three numbers was read wrong.
With dates in column A, amounts in C and balances in D, put this in E3 and fill it down:
=IF(ROUND(D2+C3,2)<>ROUND(D3,2),"CHECK","")Rounding to two decimal places matters. Comparing the raw numbers produces false alarms from floating point, you learn to ignore the column, and then it is worth nothing.
This is the strongest of the three, because it checks every row individually rather than in aggregate. If your converter does not give you the balance column, ask why. It is on the statement, and it is the thing that makes the output checkable.
Check 2: the declared opening and closing balances
The statement states what you started with and what you finished with. Those two numbers anchor both ends, which the running chain alone does not do: a chain can be internally consistent and still be missing its first or last row.
Put the opening balance from the statement in G1 and the closing in G2:
=ROUND(G1+SUM(C2:C500),2)=ROUND(G2,2)If that is FALSE, something is missing or misread, and the difference is often the thing itself. A gap of exactly one transaction's value usually means one row was dropped. A gap of exactly twice a value means a sign was read backwards, since turning a debit into a credit moves the total by double.
Check 3: how many accounts are in the document
This is the one people skip, and it is how whole accounts go missing.
Banks often put more than one account in a single statement PDF, each with its own opening and closing balance. A converter that reads the first and stops produces a CSV that passes both checks above, because the account it did read balances perfectly. The arithmetic cannot see what was never extracted.
Search the PDF for "opening balance", or for the account number, and count the matches. Then count how many accounts appear in the CSV. If the second number is smaller, the conversion is incomplete no matter how well it adds up.
What these checks cannot catch
Being clear about this is the point. A check you trust further than it deserves is worse than no check.
- Rows dropped from the very start or end, when the statement declares no opening or closing balance. The remaining chain is still internally consistent. Check 2 is what catches this, and it needs the bank to have printed those figures.
- Two errors that cancel out, if all you have is the total. Reading 50.00 as 60.00 on one row and 60.00 as 50.00 on another leaves the sum unchanged. Only the per-row chain in check 1 finds these.
- Anything that is not a number. A date read as 03/04 instead of 04/03, or a description attached to the wrong row, changes nothing arithmetically. Balances cannot help you here. Spot-check dates against the PDF, particularly at the start and end of the period, where an error moves a transaction into the wrong month.
A statement to test with
Here is a statement that looks ordinary and is not. Its last line shows 80.25 paid out against a balance of 915.25, when the line before it left 985.50.
| DATE | DESCRIPTION | PAID OUT | PAID IN | BALANCE |
|---|---|---|---|---|
| 03/04/2026 | TESCO STORES 3456 | 25.00 | 975.00 | |
| 14/04/2026 | SALARY ACME LTD | 10.50 | 985.50 | |
| 25/04/2026 | RENT DD | 80.25 | 915.25 |
985.50 minus 80.25 is 905.25, and the statement prints 915.25. Every number on its own is perfectly plausible. Only the arithmetic disagrees, which is exactly what a misread looks like.
Download it and put it through whatever you use. Check 1 should flag row 3. If your converter hands back a clean CSV with no warning, now you know something about it that its accuracy claims did not tell you.
What happened when we tried this
We put that file through two other converters. Both returned a CSV. One of them displayed "all checks passed" and produced a row whose amount appears nowhere on the statement, with every date moved back by a day.
We are not naming them, because the file is right there and you can see for yourself. That is a better test than anyone's claim, including ours.
What we do about it
Statement Proof runs all three checks on every conversion and refuses rather than giving you a CSV that does not add up. It tells you which of the three strengths applied, because they are not equal, and it names the row that disagrees.
If you would rather run the checks yourself in a spreadsheet, the formulas above are the whole method. They work on anyone's output.