Balance Continuity Checks: Why Reconciliation Breaks (and How to Fix It)
What a balance continuity check is, why it catches the errors that miss manual reconciliation, and how to use it to validate bank-statement exports before they reach your ledger.
A balance continuity check is one of the oldest controls in accounting, and one of the most commonly skipped. It is also the single fastest way to catch the kind of error that quietly turns month-end close into a forensic exercise. This post explains what a balance continuity check is, why it works, and how to make it part of your import workflow.
What a balance continuity check is
A bank statement has three numbers that should always agree:
- Opening balance carried from the previous statement.
- The sum of all transactions during the statement period.
- Closing balance at the end of the statement.
If opening + sum(debits and credits) ≠ closing, something is wrong. Either a transaction is missing, a transaction is duplicated, an amount was misread, or a fee line was clipped during export.
The check is simple in principle. It is also the check most often skipped, because doing it by hand across a 200-row statement is tedious enough that nobody does it.
Why it catches errors manual review misses
When you read a statement row by row, you are checking each transaction for plausibility — does this amount look right, does the counterparty match a known vendor, is the date in the right range. That is necessary, but it is not sufficient.
Three classes of error survive plausibility review but fail continuity:
- Dropped rows. A transaction on a page boundary is missed because it appears at the very end of one page or the very start of the next. The row count drops by one. The amount is plausible in isolation; the statement just does not tie.
- Duplicated rows. A parser or a copy-paste step emits the same row twice. Each copy looks plausible; the doubled amount is what tips the balance off.
- Misread amounts. A debit of
1,250.00becomes a credit of1,250.00somewhere in the pipeline. The amount is plausible — it is in the right range — but it landed on the wrong side.
Continuity catches all three because it evaluates the statement as a whole, not as a list of independent rows.
A worked example
Consider a Maybank savings statement with:
- Opening balance: MYR 12,450.00.
- Transactions over the month: salaries in, rent out, three card payments, one interest credit. Twenty-three rows in total.
- Stated closing balance: MYR 18,940.50.
Sum the twenty-three rows in Excel. If the running balance is correct on every line and no row is missing, the sum is MYR 6,490.50. Opening plus that sum is MYR 18,940.50 — the stated closing balance. The statement reconciles.
Now imagine one card-payment row — MYR 420.00 — was dropped on the page boundary. The sum becomes MYR 6,910.50. Opening plus that sum is MYR 19,360.50, which is MYR 420.00 off from the stated closing balance. The check fires.
That MYR 420.00 gap is small enough that a manual reviewer can miss it in a 23-row statement, especially if they are looking for plausibility, not arithmetic. The continuity check fires every time.
Multi-currency and other special cases
A balance continuity check has to be done per currency. A multi-currency statement that lists MYR, USD, and SGD transactions on the same page has three independent continuities to verify:
- Opening MYR balance + MYR transactions = closing MYR balance.
- Opening USD balance + USD transactions = closing USD balance.
- Opening SGD balance + SGD transactions = closing SGD balance.
A single statement-level check that sums everything in MYR-equivalent would silently absorb a USD→MYR conversion error. Per-currency checks avoid that.
A second special case is the opening balance row itself. Some statements display the opening balance as a row above the transactions; others bury it in the header. Treat it as a header, not a transaction, when summing — including it as a transaction double-counts it.
Where this fits in the import workflow
The fastest workflow is to run the check before the data enters your ledger, not after. The sequence that holds up in practice:
- Export. Download the bank statement PDF.
- Parse to Excel. Convert it to rows in a spreadsheet.
- Continuity check. Compute opening plus the sum of transactions; compare to closing.
- Investigate any mismatch. If the check fails, the gap (e.g.,
MYR 420.00) usually points to a specific row or page boundary. Re-export and re-check. - Import to ledger. Only after the check passes.
This is the workflow that Transift runs by default — the review screen shows the continuity result before you download the Excel, and any mismatch is flagged inline with the affected row.
Catching it early vs. catching it late
The cost of a continuity check failure depends entirely on when you catch it:
- Caught at import — five minutes to re-export, re-check, and proceed. The error never enters your ledger.
- Caught at month-end close — hours of investigation: which row, which account, which reconciliation entry was based on the wrong number. The error has flowed through payables, receivables, and trial balance.
- Caught at audit — significantly worse. The auditor flags the unreconciled difference, asks for source documentation, and the team spends days reconstructing what happened.
The arithmetic is identical at every stage. The cost is not. That is why the check belongs at the front of the pipeline, not the back.
A simple Excel implementation
If you are running this check yourself in Excel, the formula is:
= opening_balance + SUM(debit_column) - SUM(credit_column)
Compare the result to the closing balance cell. If they differ, the difference is your search radius — look for a missing or duplicated row close to that amount.
For multi-currency statements, run the same formula per currency, filtered by a currency column.
For a tool that runs the check automatically on every parse — Maybank, CIMB, and the other major Malaysian banks — Transift is set up to do exactly this. The balance continuity check is part of the export, not a separate step you have to remember.
What to read next
- Convert Maybank Statement PDFs to Excel — per-bank walkthrough with the specific continuity patterns Maybank statements exhibit.
- Convert CIMB Bank Statements to Excel — same for CIMB, including multi-currency and CIMB BizChannel business accounts.