How to Check if a Converted Bank Statement Is Correct
Three checks that show whether every transaction, amount and balance survived the conversion, and what each one does not prove.
On this page
Converting a bank statement from PDF to CSV or Excel is only useful if the result contains the right transactions, the right amounts, and all of them.
The good news is that you can check this properly without comparing every cell by hand. Three checks do most of the work:
- Reconcile the running balance. Confirm each transaction leads correctly to the next balance.
- Compare any totals the statement prints: withdrawals, deposits, transaction count.
- Compare the closing balance. Confirm the converted transactions end where the statement says they end.
Then spend two minutes looking at page breaks and unusual sections.
The first check tells you the extracted rows are internally consistent. The other two give you evidence that the transactions are all there, and that is the difference most people miss.
Why a converted statement can look correct and still be wrong
Conversion errors come in two kinds, and they do not feel the same.
Wrong values are loud. A decimal in the wrong place, a debit read as a credit, a date that turned into the wrong year. These break your totals, and your accounting software usually complains. Annoying, but you find out.
Missing rows are silent. If a converter drops a group of transactions printed in a grid halfway down page two, every row it did keep is still individually correct. Your CSV opens cleanly. Every number in it is right. It is simply not your whole statement.
That second failure is why “the numbers looked fine” is not evidence, and why checking a few rows is not enough.
Check 1: Reconcile the running balance
If your statement prints a balance beside each transaction, the document contains its own integrity test.
The rule:
Previous balance + or − this transaction’s amount = this transaction’s balance
| Previous balance | Transaction | Expected balance |
|---|---|---|
| 2,000.00 | −125.00 | 1,875.00 |
| 1,875.00 | +300.00 | 2,175.00 |
| 2,175.00 | −50.00 | 2,125.00 |
A statement with twenty transactions gives you twenty points where the arithmetic can be checked. A single broken link tells you exactly which row to look at.
Doing it in Excel or Google Sheets
Open your CSV and find two things: the column holding the transaction amount, and the column holding the running balance.
If your file has separate debit and credit columns (for example date, description, debit, credit, balance in columns A to E), put this beside your second transaction row and fill it down:
=ROUND(E2 + D3 - C3 - E3, 2)If your file has a single signed amount column (say amount in column C and balance in column D):
=ROUND(D2 + C3 - D3, 2)Every result should be 0, or within 0.01 for the reason in the next paragraph. Anything
larger is the row to investigate.
Two things worth knowing:
- Round to two decimals. Spreadsheets store money as binary floating point, where
0.1 + 0.2does not exactly equal0.3. Across a couple of hundred rows that drift is enough to fail a strict equality test on a perfectly correct file. Rounding to whole cents removes it. - Allow 0.01. Banks round their own figures. A difference of one cent is usually the statement’s rounding rather than a conversion error. A difference of 4.37 is a real problem.
Reading the result
| What you see | What it means |
|---|---|
| Every row is zero | The transactions you have are consistent with each other |
| Exactly one row is non-zero | Either a transaction is missing at that point, or that row’s amount or direction was misread. The size of the difference is the amount involved, so check the PDF at that row |
| Two rows next to each other are non-zero, by the same amount, one positive and one negative | The balance printed between them was misread |
| Almost nothing reconciles | Usually the row order (see below). Failing that, the debit/credit direction or the number format |
Differences do not carry forward. This surprises people. Each check compares two balances that the statement itself printed, so a problem in one row cannot leak into the next one: the row after it starts again from a balance read straight off the PDF. That is why a missing transaction shows up as a single failure rather than a permanent offset, and why “one row is off, everything after it is fine” is the normal symptom of a dropped row, not a reason to relax.
A failed check does not mean the conversion is unusable. It tells you where to look.
If that looks like more spreadsheet work than you want to do on every statement, DTLOVA’s converter runs this walk for you whenever your statement prints a running balance, and shows you the result before you download anything. When a statement prints no running balance there is nothing to walk, and it says that instead of implying a check it never ran.
Check the transaction order before you conclude anything
Some banks print the newest transaction first. Others print the oldest first.
If you reconcile a newest-first statement as though it ran oldest-first, the arithmetic fails almost everywhere and it looks like the conversion is broken. Usually it is not.
Try the walk in the other direction before concluding anything. A statement that reconciles perfectly backwards was simply printed the other way round. This matters more than you would expect when you convert statements from different banks, because the convention varies.
Check 2: Compare the statement’s own totals
The running-balance check proves the rows you have follow on from each other. That is a real constraint. If a transaction is dropped from the middle of the table, the next row’s printed balance no longer follows from the previous one, and the check fails at exactly that point.
But it only covers content that was in the balance chain to begin with.
Statements routinely print transactions somewhere other than the main table: a cheque listing several columns across, a fees table, a summary block, an entire second account on a later page. Those rows usually carry no running balance of their own. They were never links in the chain, so if they are missed, the chain is left perfectly intact and the arithmetic has nothing to notice.
That is the gap the printed totals close.
This is where the statement’s own summary figures earn their keep. Many statements print:
- total money out (withdrawals or debits)
- total money in (deposits or credits)
- number of transactions
- opening balance
Each is an independent constraint on the whole file rather than on one row. Sum the debit column in your CSV and compare it with the printed withdrawals total. If the statement says 18,171.30 went out and your CSV adds up to 14,671.30, you are missing 3,500, and you now know roughly where to look.
A total that disagrees is a strong signal that rows may be missing, and it catches gaps anywhere in the statement rather than only at the end. It is not conclusive on its own: a mismatch can also come from a misread amount, a debit read as a credit, or the bank defining its total to include something outside the transaction list. But it tells you to look.
Check 3: Compare the closing balance
Finally, compare the endpoints:
- Opening balance. Does your first row start where the statement says the period starts?
- Closing balance. Does your last row land on the closing balance the statement prints?
If the walk reconciles cleanly and ends on the printed closing balance, that is strong evidence the extracted transactions are consistent with the statement and that nothing is missing from the end. If it reconciles but ends somewhere else, rows are missing from the end, and the size of the gap tells you roughly how much went astray.
One honest limit
Matching endpoints is strong evidence, not proof. If the missing rows happen to cancel out (a transfer out and the same amount back in, both dropped), the walk still reconciles and the closing balance still matches.
That is why the totals check above and the visual check below are both worth doing even when the arithmetic is clean. Three checks looking at the file from different directions are much harder to fool than one.
What if there is no closing balance?
Not every statement prints one. When that happens the second check simply cannot run, and the honest conclusion is narrower than it feels:
The transactions extracted are consistent with each other. Whether the file contains all of them could not be confirmed.
Unproven is not the same as wrong, and it is not the same as right. Worth keeping separate in your head if the file is going into bookkeeping, accounts or a tax return.
Check 4: A two-minute visual pass
Arithmetic cannot catch everything. Open the PDF and the CSV side by side and check four things.
Page breaks. Look at the last transaction on each PDF page and the first on the next. Row loss clusters at page boundaries.
Grids and boxed sections. Cheque listings, fee summaries and transactions printed several columns across are harder to read reliably than a plain table, and are worth checking specifically. This is the content the balance check cannot cover, for the reason given above: it was never in the running-balance chain. Your eyes are the only check it gets.
More than one account. If the PDF holds two accounts, each has its own balance chain. Do not combine them and expect a single running-balance check to work.
More than one currency. Adding a $20 transaction to a €20 transaction produces a number, not a check. Split by currency first, then reconcile each separately.
What a “checked” conversion should actually mean
A tool telling you a conversion is checked should be clear about which claim it is making, because there are genuinely different outcomes:
- The balance adds up and ends where the statement says it ends. Both the arithmetic and the endpoint agree. This is the strongest result available.
- The balance adds up, but the statement prints no closing balance to compare against. The arithmetic holds; completeness is unproven rather than confirmed.
- The balance does not add up the whole way through. Something needs looking at before the file is used.
- There was no running balance to check. Nothing was verified, one way or the other.
The distinction that matters most is between the first two. A tool that reports the second as though it were the first is claiming a completeness check that never ran.
How DTLOVA checks your statement
DTLOVA’s bank statement converter runs all three checks before you download anything, and shows each one separately with the number of comparisons it made:
- The running balance adds up. Every row follows from the one before it.
- Matches the statement’s own totals. The printed withdrawal or deposit total agrees.
- Nothing missing from the end. The walk ends on the closing balance this statement prints.
Reporting them separately is deliberate. A single tick would hide which claim is actually supported. When a statement prints no closing balance to compare against, the third check cannot run, and the result says so rather than rounding up to “verified”.
A few details behind that:
- Comparisons are made in whole cents with a one-cent tolerance, so the bank’s own rounding does not register as an error and floating-point drift cannot accumulate across a long statement.
- The row order is read from the arithmetic rather than assumed, so a newest-first statement is not reported as broken.
- Where a statement mixes currencies, the check is declined rather than computed, because a sum across two currencies is not evidence.
- Rows that were found but could not be placed in the transaction table are shown to you in their own list, and you choose whether to include them in the download.
You see all of this before you download, alongside the extracted rows themselves. Every cell is editable, so anything the checks flag can be corrected on the spot rather than after the fact in a spreadsheet.
The two-minute version
- Reconcile the running balance in a spreadsheet. Round to two decimals, allow 0.01.
- Compare the printed totals by summing your debit column against the statement’s withdrawals total.
- Compare the closing balance in your CSV with the one printed on the statement.
- Check a few page breaks and anything printed in a grid.
The first tells you the rows you have are consistent. The next two give you evidence they are all there. The last catches what arithmetic cannot.
For records that matter (accounts, a tax return, a loan application), it is still worth keeping the original PDF beside the CSV.