Home › Blog › Reconciliation & Verification › The running balance check, explained
How the row by row running balance check works, why it localizes a conversion error to a single row, and how to use it in your own review each month.
By StatementVerified Editorial · November 5, 2026 · 7 min read · Filed under Reconciliation & Verification
A totals check tells you whether a converted statement is wrong. A running balance check tells you where. Many bank statements print a balance after each transaction, and that column is a gift to anyone verifying a conversion, because it turns one end of period comparison into dozens of small comparisons, one per row. The first row where your calculated balance and the printed balance disagree is the neighborhood of the error, and every row before it has already been proven clean. No other single check narrows a search that efficiently.
This guide explains how the check works mechanically, how to build it in a spreadsheet in a few minutes, how to interpret the three patterns a divergence can take, and what to do when a statement does not print a running balance at all. Bookkeepers who internalize this check stop rereading whole statements to find one bad row. They let the arithmetic walk them to the row, confirm it against the PDF, fix it, and watch the rest of the column fall back into agreement, which is its own final proof.
Start with the statement opening balance in the first cell of a calculated balance column. For each transaction in statement order, add its signed amount to the prior calculated balance. Signed means deposits and credits increase the balance and withdrawals, checks, and fees decrease it, following the statement presentation for that account type. In the next column, place the balance the statement prints for that same row. A third column subtracts one from the other. While the conversion is faithful, that difference column reads zero on every row from top to bottom, and the final calculated balance lands exactly on the printed closing balance.
Order is critical. The check only works in the exact order the statement presents transactions, which is not always strictly chronological within a day. Banks typically order same day items by posting sequence, and sorting your spreadsheet by date, amount, or description before running the check will manufacture false divergences everywhere. Keep a pristine copy in statement order for verification, and do any sorting, filtering, or categorizing in a separate copy or a separate column. If you must sort for review, add an original sequence number column first so you can restore statement order perfectly before rechecking.
Pattern one is a single step. The difference is zero, becomes a fixed amount at one row, and stays at that same amount to the end. That means one row at the step is wrong by exactly that amount, through a misread digit, a flipped sign appearing as double, or a dropped or duplicated neighbor. The error is at the step row or the row immediately before it. Pattern two is a step that later returns to zero. That means a temporary disturbance, most often two rows in the wrong order, a transaction placed in the wrong position within the day, or a pair of compensating errors. Inspect the block between the step out and the step back as a unit.
Pattern three is drift, where the difference grows or changes irregularly from row to row. Drift suggests a structural problem rather than a single bad read: amounts taken from the wrong column for a section, a daily balance summary interleaved with activity, or a statement section in a different sign convention, such as a fee schedule presented as positive values that should subtract. With drift, stop hunting row by row. Compare section subtotals against the statement instead, isolate which section introduces the drift, and rebuild that section. Recognizing which pattern you have before you start fixing saves more time than any other part of this method.
You need four columns beside the converted data: sequence, signed amount, calculated balance, and printed balance, plus the difference. The signed amount should come from a single amount column with explicit signs, not from separate debit and credit columns, because separate columns invite a row where both or neither is populated. Write the calculated balance as prior balance plus current signed amount, fill it down without gaps, and paste the printed balances as values so a sort cannot scramble formulas. Then scan the difference column for the first non zero value. That scan, not a visual read of hundreds of rows, is the entire diagnostic step.
Two practical cautions matter. First, rounding: work in full precision and format to two decimals for display, because a column of one cent differences usually means values were rounded during conversion rather than truly misread. Second, blank rows: a blank or subtotal row inside the data will break the fill sequence and create a false step. Remove non transaction rows from the checking copy, but log them, since a removed subtotal is often the checkpoint you will use later to verify that section independently. Keep the checking copy as a workpaper with the statement, so the proof survives after the cleaned import file has moved on.
Some banks, and most credit card statements, do not print a per row balance. You lose the localizing power, but you can rebuild partial checkpoints from whatever the statement does print. Daily balance summaries give you an end of day anchor: sum the signed activity for each date and confirm your calculated balance matches the printed daily balance at each day boundary. Section subtotals give you block anchors for deposits, checks, and fees. Even the single closing balance still gives you the totals check, and combining it with section anchors localizes an error to a section, if not to a single row.
You can also create a checkpoint from the next statement. Its opening balance must equal this closing balance, and its first printed running balances will confirm whether your ending position was right. For credit cards, the equivalent anchors are the previous balance, total charges, total payments and credits, and the new balance printed in the summary box. The summary arithmetic is the same proof in aggregate form. The principle never changes: use every number the issuer prints for human readers as a test of the file you are about to trust, because those printed numbers are the only independent evidence you will ever get.
When the running balance agrees on every row, you hold unusually strong evidence. A conversion could still theoretically contain two errors that cancel within the same interval between checkpoints, but with a checkpoint on every row there is no interval for cancellation to hide in, short of two errors on the very same row netting to zero, which would require the amount itself to be right. That is why a clean running balance result justifies moving quickly to import, while a file proven only by totals deserves a slower preview review, and a file with neither deserves section by section work before it touches the books.
Make the check a habit at intake rather than a rescue at month end. Run it when the statement arrives, while the client still remembers unusual activity and while a fresh statement download is easy to request. Note the result, file the workpaper, and import the proven file. Months later, when a balance is questioned, you will not be reconstructing your confidence from memory. You will open the workpaper, show a column of zeroes next to the statement own balances, and move on to questions that actually need a bookkeeper judgment instead of arithmetic archaeology.
No. The running balance is a verification tool, not import data. QuickBooks and Xero import files should contain date, description, and amount columns only, in the layout each system expects. Keep the running balance check in your workpaper copy, separate from the clean file you upload.
Scattered one cent differences usually indicate rounding during conversion or display formatting hiding extra precision. Recalculate from unrounded values and format only the display. If a single one cent step persists at one row, treat it as a real one cent misread and compare that row to the statement.
No, not in the checking copy. The printed balance sequence follows the bank posting order, which sorting destroys. Add a sequence column in statement order, run the check in that order, and do any sorting for categorization in a separate copy or after verification is complete.
Reconciliation & Verification · November 3, 2026
Why duplicate transactions appear after imports and bank feeds, how to prove a true duplicate against the statement, and how to remove it safely.
Reconciliation & Verification · November 2, 2026
Learn how bank reconciliation works step by step, using the bank statement as the referee for every balance, transaction, and difference for any account.
Reconciliation & Verification · November 2, 2026
Find a missing transaction fast by bisecting the statement balance, comparing mid period checkpoints, and narrowing the window until the row appears.
Convert a statement now and watch the reconciliation check verify it against the statement itself.
Your first conversion is free — no card, no sign-up — and every result is reconciled against the statement itself before you download it.