Balance-Chain Reconciliation: Prove a Statement Is Complete

The arithmetic that proves a converted bank statement is complete and correct — and the specific case where the balance chain alone isn't enough.

Every bank statement carries a built-in proof of its own correctness. Most conversion tools ignore it. Understanding it will make you much harder to fool by a tidy-looking spreadsheet.

The balance chain

A statement's running balance column isn't decoration — it's a chain of dependent values. For every transaction:

previous balance − debit + credit = current balance

This has to hold on every single row. If it holds from the opening balance through to the last transaction, then every amount was read correctly and every row is in the right order. One misread digit anywhere breaks the chain at that row and every row after it.

That's a powerful property. A single arithmetic walk validates every amount in the file.

Where the balance chain isn't enough

Here's the case that matters, and it's the reason we treat this as two checks rather than one.

Suppose a converter drops an entire page — say rows 40 through 75. Row 39's balance is correct. Row 76's balance is correct. And row 76's balance follows correctly from row 76's own debit and credit applied to... row 75's balance, which is gone. But if the converter simply chains what it has, rows 1–39 and 76–200 each chain internally, and depending on how the check is written, the whole file can appear consistent.

More importantly: the file's own closing balance still matches the bank's, because the last row is intact. A check that only compares opening and closing balances passes a file missing 35 transactions.

The second check: tie-out against printed totals

Bank statements print summary totals — total debits, total credits, sometimes a transaction count. These are independent of the row data.

Sum your extracted debits and compare with the printed debit total. Do the same for credits. If 35 transactions are missing, those sums won't match, no matter how well the remaining rows chain.

This is why we require both: the chain proves the amounts are right, and the tie-out proves nothing is missing. Either one alone leaves a real gap.

Doing this manually

Add a check column In Excel: previous balance − debit + credit. Compare to the balance column.
Look for the first mismatch The first row where they disagree is where extraction went wrong — everything after it is downstream of that one error.
Sum debits and credits separately Compare each against the statement's printed totals.
Count the rows If the statement prints a transaction count, compare it.

Every conversion we run walks the chain and compares the statement's own printed totals automatically, and reports the result on its own sheet — the Completeness sheet — naming the rows that disagree. A file that passes has been checked against the bank's own numbers, not merely produced without an error message.

Frequently asked questions

What if my statement has no running balance column?

Credit card statements often don't. Verification falls back to comparing extracted totals against the printed summary, which is weaker but still meaningful.

What if the statement doesn't print totals?

Then only the chain check is available. You'll be told that verification was partial rather than given false confidence.

What should I do if a file doesn't reconcile?

Check the original PDF for the rows around the first mismatch. It usually indicates either a genuinely unusual layout or, occasionally, a problem with the statement itself.

Convert a statement now

Bank Statement PDF to Excel, or see every format. More in the guides.