A Credit Card Statement Has No Running Balance. Prove It Anyway.
We check every bank statement we convert against its own running balance. Each balance is the one above it plus the money in or minus the money out, so a reading that adds up from the first balance to the last found every row and put each one on the right side. We wrote about that check here, and it is the reason we can tell a customer which rows are proved instead of asking them to trust us.
A credit card statement prints no running balance. Every row is a purchase, a payment, a refund or a fee, and nothing on the row says what the account stood at afterwards. For a long time that meant a card reading could not be proved at all. This is how we prove them now, and the two bugs that hid a whole bank’s cards from the check.
One equation instead of one per row
What a card does print is a summary box. Previous balance, payments and credits, purchases and debits, interest, fees, new balance. That is one equation for the whole statement: the previous balance, plus everything charged, minus everything paid or refunded, has to equal the new balance, to the cent.
A real one, from a business Visa: 4,875.01 owed at the start, 4,875.01 paid, 806.14 of purchases and a 29.00 fee, 835.14 owed at the end. A reading of that statement passes only if its rows reproduce those figures exactly.
One equation is weaker than a running balance. It proves the totals, not where each row sits, and two mistakes that cancel would pass. So we ask for one more thing: the total of one side has to be printed somewhere on the statement as well. With the net exact and one side pinned, the other side is pinned too, and a payment filed as a purchase can no longer hide.
The words on the page pick the formula
A bank account and a card run in opposite directions. On an account, money in raises the balance. On a card, money in lowers what you owe. That matters more than it sounds: a bank account read with every row on the wrong side passes the card’s equation. The arithmetic alone cannot tell you which statement you are holding.
So the statement’s own vocabulary decides. Minimum payment, credit limit, payment due date, cash advance: two different card words before we treat it as a card. One is not enough, because a few bank accounts print “new balance” too.
The side panel that ate the payment
A customer’s statements from one Canadian bank’s business card all came back unverifiable. The readings had something in common that turned out to be the clue: not one statement had a single credit. A month of card activity with no payment is possible, but month after month of them is not.
The layout explained it. The transaction table runs down the left of the page, and a panel runs down the right: contact numbers, the credit limit, the interest rates and the summary box itself, printed on the same lines as the transactions. Read as flat text, those lines merge. Our line reader took the credit limit for a purchase of 5,000.00 and the box’s totals for more purchases. The payment fared worst: its amount is printed on the line under the reference number, so it never sat next to its own date and was dropped. The statement went to a model, and the model dropped the payment as well.
The fix reads the layout instead of the flat text. Each line is cut where the table heading’s AMOUNT column ends, which removes the panel without guessing at it. A row has to be exactly two dates, a description and one amount on one line. A minus sign means money in. A description that runs onto the next line joins its row, and the long reference number printed under every row never does. Then the reading is used only if it ties to the box.
The proof did not know the bank’s words
The second bug was quieter. The box check looks for where the statement says it starts, and it knew “previous balance”. This bank prints “Previous Statement Balance”, and on personal cards “Previous Account Balance”. So even a perfect reading of these cards could never be proved, by our rules or by any model. One phrase fixed it.
The lesson is about how a check fails. A proof that cannot run looks exactly like a statement that has nothing to prove. Our health report counts “unverifiable” as a result of its own for that reason, because a run of them from one bank is not a quirk of the statements, it is a hole in the checker.
Where real statements come from
We do not keep customers’ PDFs, so we cannot test against theirs. What we can do is find real statements that are published on purpose. Some public bodies post their corporate card statements every month for transparency, and three of those from the same bank became test fixtures, with the cardholder, card numbers and address masked.
Across the 266 files we measure every reader change against, nothing else moved. The rules now settle 120 of 231 statements on their own, up from 117, and those three are the difference. A statement the rules settle is read in milliseconds and costs nothing, so this is a fix that also saves money on every card from that bank.
If you are building one of these
What we would tell ourselves a year ago:
- Prove cards from the summary box, and require one printed side total as well as the net, or a row on the wrong side passes.
- Let the statement’s words pick the account formula or the card formula. The arithmetic cannot.
- Cut a side panel off at the table heading’s amount column, not at a guessed width.
- Treat a run of unverifiable results from one bank as a bug report.
- A month of card activity with no credits at all is the tell for a dropped payment.
- Look for statements that were published on purpose. Some public bodies post theirs every month.
Try it on a card
Drop a card statement into the credit card statement converter and the preview says whether the summary box proves it. RBC cards in particular now read with the free rules: see the RBC converter. To check a statement you already have, verify it against its own balances.