· 6 min read
What a reconciliation check really catches
The running-balance identity, four errors it catches (dropped row, duplicate, wrong sign, wrong digit), what it misses, and how to read a flagged row.
Every converter, ours included, can misread a statement. The question is whether the mistake is visible. A reconciliation check makes one class of mistakes visible, the class that changes money, and does nothing for the rest. This article explains exactly which is which, with numbers you can check by hand.
The identity
A bank statement carries its own proof. Next to most transactions, the bank prints the balance after that transaction. That means every row has to satisfy one equation:
balance after this row = balance after the previous row + money in − money out
and the statement as a whole has to satisfy its sum:
opening balance + all money in − all money out = closing balance
The check is nothing more than recomputing the running balance from the rows that were extracted and comparing it with the balance the bank printed, row by row. Where the two agree, the amounts on that row and every row before it are consistent with the statement. Where they first disagree, an error is at that row or just before it.
A worked example
A short statement. Opening balance 1,250.00.
| # | Date | Description | Out | In | Printed balance |
|---|---|---|---|---|---|
| 1 | Sep 1 | Payroll | 2,400.00 | 3,650.00 | |
| 2 | Sep 2 | Rent | 1,500.00 | 2,150.00 | |
| 3 | Sep 3 | Grocery | 86.42 | 2,063.58 | |
| 4 | Sep 5 | Electricity | 133.17 | 1,930.41 | |
| 5 | Sep 6 | Refund | 25.00 | 1,955.41 | |
| 6 | Sep 8 | Card payment | 412.90 | 1,542.51 |
Closing balance 1,542.51. Money in totals 2,425.00, money out totals 2,132.49, and 1,250.00 + 2,425.00 − 2,132.49 = 1,542.51. Every row also matches: 1,250.00 + 2,400.00 = 3,650.00; 3,650.00 − 1,500.00 = 2,150.00; and so on down to 1,955.41 − 412.90 = 1,542.51. This extraction reconciles.
Now break it four ways.
The four errors it catches
A dropped row
Suppose row 5, the 25.00 refund, is not extracted at all. Row 4 still reconciles at 1,930.41. Row 6 is now computed as 1,930.41 − 412.90 = 1,517.51, but the printed balance is 1,542.51. Difference: 25.00. The check flags row 6, and the difference is exactly the amount of the row that went missing before it. The closing sum fails by the same 25.00.
A duplicated row
Suppose row 4 is extracted twice, which happens at page breaks when a transaction is printed at the bottom of one page and the top of the next. After the second copy, the computed balance is 1,930.41 − 133.17 = 1,797.24 against a printed 1,930.41 (the duplicate carries the same printed balance). Difference: 133.17, the duplicated amount, and every row after it stays off by that much until something else goes wrong.
A wrong sign
Suppose row 5 is read as money out instead of money in. Computed: 1,930.41 − 25.00 = 1,905.41. Printed: 1,955.41. Difference: 50.00, which is twice the amount. A difference of exactly double a row's amount almost always means a flipped sign on that row. This is the error that matters most for credit-card statements and for CSV imports, where the sign convention is easy to get backwards.
A wrong digit
Suppose row 3 is read as 68.42 instead of 86.42, a transposition. Computed: 2,150.00 − 68.42 = 2,081.58. Printed: 2,063.58. Difference: 18.00. Two transposed digits always produce a difference divisible by 9 (here 18, which is 9 × 2), an old bookkeeping rule that still works. A single misread digit, say 433.26 read as 43.26, produces a difference of 390.00, which is not a real amount on the statement and does not match any pattern; that on its own tells you to look at the digits of the flagged row.
In each case the check names a row, and the size of the difference tells you what kind of mistake to look for. None of these four errors is visible in a table on its own. A statement missing one row looks exactly like a complete one.
What it cannot catch
The check compares amounts against balances. Anything that does not change the balance is invisible to it.
- A wrong description. "Electricity" extracted as "Electricty", or a payee name cut short, reconciles perfectly. The amounts are right, so the balance is right.
- A wrong date. If the day is misread but the rows stay in order, every balance still matches. Dates that move a row into a different month are a real problem for your books and the check will not see it.
- Two errors that cancel. A dropped 25.00 credit and a dropped 25.00 debit in the same statement leave the closing sum correct. The row-by-row comparison still catches this, because the running balance goes wrong at the first of the two rows, but a check that only compares opening and closing totals would not.
- Statements with no balance column. Most credit-card statements print a previous balance, a new balance and a list of transactions with no running balance in between. There, the only test available is the sum: previous balance + purchases + fees + interest − payments − credits = new balance. A dropped row still fails that sum, but the check cannot say which row, and a dropped row plus a duplicate of equal amount would pass. Some bank statements omit the balance column too. Our converter runs the sum check when there is no running balance and marks the result "closing total checked", so you know which of the two tests was applied. The reconciliation page describes both.
- An error the bank made. The check tests your extraction against the printed statement. If the statement itself is wrong, both agree and the check passes.
- Balances misread the same way as the amount. In principle an extraction could misread an amount and misread the printed balance by a matching error. Both figures would have to be wrong by the same amount on the same row, and the check compares every row, so the row after it would break.
Reading a highlighted row
When a conversion result shows a highlighted row, this is what it means and what to do.
The row is the first place where the computed running balance and the printed balance disagree. The error is on that row, or on a row that should exist between it and the previous one. Read the difference:
- Equal to an amount somewhere near that row: a row was dropped (the difference is its amount) or duplicated (the difference is the repeated amount). Compare the rows around the highlight with the PDF.
- Exactly twice the row's amount: the sign is flipped.
- Divisible by 9: two digits are transposed in the row's amount.
- None of the above: a digit was misread. Look at the amount on the highlighted row against the PDF.
Fix the cell, or re-run the conversion, and the rows after it usually clear at once, because a single early error carries the same difference down the whole statement. If several rows are highlighted with different differences, there are several errors; work from the top.
The errors it finds
The errors this catches are mundane and specific: a 433.26 read as 43.26, a 375.84 read as 275.84, a 91.48 read as 51.48. None of them look wrong on the page. Each of them breaks the running total by exactly the amount of the mistake, which is why the check finds them and an eye scanning a column does not. That is also why scans and photos take a stronger reading pass, and why a flagged row is the useful output rather than an embarrassing one. How we validate releases and scanned statements and phone photos.
The check is not a promise that the extraction is right. It is a promise that if an amount is wrong, you will be looking at the row where it went wrong instead of finding out at the end of the month.