Eight transactions produce three plausible-looking totals: 900, 870 and 1,120. The first records consumption when the purchase occurs. The second records money leaving the household's combined cash locations. The third mixes those views and counts a transfer and a card payment again. Only the last is inconsistent with the stated rules.
We constructed this ledger and ran a small program to reconcile it. Every amount is an invented currency unit, not a real statement, household survey or saving. The record distinguishes a genuine double count from a difference caused by using another time or account boundary.
Choose the boundary before adding the entries
The example starts with 1,000 in a bank account, 100 in a cash wallet and no card debt. Both cash locations belong to the same household. Opening cash is therefore 1,100. Moving 200 from the bank to the wallet changes their individual balances but not that total.
Our consumption view records a cash purchase when paid and a card purchase when made, with a refund reversing the latter. Card repayment reduces cash and the existing card liability; it is not a second purchase in this view. The cash-flow view instead tracks external cash payments, including the card payment. These are declared rules for this example, not a universal bookkeeping standard.
The CFPB toolkit offers separate spending, bill-calendar, cash-flow and debt tools. It is a US educational resource; our amounts and model are our own. A cash budget and a purchase-date consumption record answer different questions, so their totals do not have to match.
The eight entries, with both sides of each movement
Positive cash change adds to the bank-plus-wallet total; positive debt change increases the card balance. The table uses full currency units. The downloadable CSV and code store integer hundredths of that same invented unit, so divide those amounts by 100 to match this table.
| Entry | Amount | Consumption | Combined cash change | Card debt change |
|---|---|---|---|---|
| T1 Income into bank | 2,000 | 0 | +2,000 | 0 |
| T2 Groceries paid from bank | 120 | 120 | −120 | 0 |
| T3 Bank-to-wallet transfer | 200 | 0 | 0 | 0 |
| T4 Card purchase | 60 | 60 | 0 | +60 |
| T5 Refund credited to card | 10 | −10 | 0 | −10 |
| T6 Payment from bank to card | 20 | 0 | −20 | −20 |
| T7 Rent paid from bank | 700 | 700 | −700 | 0 |
| T8 Food paid from wallet | 30 | 30 | −30 | 0 |
The 20 payment is a model input chosen to leave a visible liability. It is not a suggested payment amount. The example omits interest, fees, statement cycles and actual minimum or full-payment requirements; a real payment decision needs the actual bill and agreement.
Where the mixed total gains 220
Adding every non-income amount and subtracting the refund gives 120 + 200 + 60 − 10 + 20 + 700 + 30 = 1,120. That sum includes the 200 transfer as though money left the household, even though it moved into the wallet. It also counts 20 against the same card purchase already recorded at T4.
Under our consumption rule, the total is 120 + 60 − 10 + 700 + 30 = 900. The excess is 220: the internal transfer of 200 and the payment of 20. Making more categories does not repair that boundary error. The entries must first be classified by what they do to cash, consumption and debt.
A different valid approach can record card payments in a cash budget and leave card purchases out of that cash total. The error is combining the purchase and payment as if they were two separate purchases, not choosing cash-flow records in the first place.
Why the cash total is 870, not 900
Cash actually leaves through T2, T6, T7 and T8: 120 + 20 + 700 + 30 = 870. The card has a net purchase of 50 after the refund, of which 20 has been paid. Its remaining liability is 30. In this zero-opening-debt example, 870 of cash payments plus the 30 increase in debt explains the 900 of consumption.
The closing bank balance is 1,960; the wallet holds 270. Combined cash is 2,230. Subtract the card liability of 30 and the net position is 2,200. The other check reaches the same figure: opening net position 1,100 + income 2,000 − consumption 900 = 2,200.
Neither 2,230 nor 2,200 means that amount is free to spend. The model does not list future bills or reserved money. These figures check whether this particular ledger is internally explained.
Move a payment across the period boundary
If T6 falls in the next reporting period, this period has seven entries. Consumption stays 900, cash payments become 850, combined cash becomes 2,250 and card debt becomes 50. The net position is still 2,200. No new saving appeared: a payment date moved, and the liability remains.
The third scenario starts with an old card debt of 150 and 1,000 cash. Paying that debt produces a cash outflow of 150 and no new purchase in the selected period. Cash ends at 850, debt at zero, and net position remains 850. Calling the outflow zero would hide a real cash requirement; calling it a new purchase would move an earlier period's consumption into this one.
Savings allocations and unknown records need their own treatment
consumer.gov's budget guide explains planning income and expenses and allows savings as an allocation in a budget. Reserving money for a goal can be useful without describing a transfer between owned accounts as consumption. Label which question the worksheet answers: allocation, cash available on a due date, or purchases in a period.
If a card statement shows only a payment and the purchase records are missing, this program cannot infer what was bought or when. Mark that gap for review rather than silently assuming no consumption. Our complete, generated input is what makes the demonstrated reconciliation possible.
Reproduce the checks and inspect the rejected inputs
The transaction CSV, Python code and complete results contain the fixed ledger and all three scenarios. If Python 3 is already available, run python3 ledger-check.py to print the results. It reads no files or account connections and needs no extra package or network access.
We checked each scenario against explicitly specified closing balances and reconciled net position after every entry. Eight altered inputs were rejected: an unknown type, duplicate ID, negative amount, fractional minor unit, unknown cash account, transfer to itself, card overpayment and missing amount. Rejection of card credit balances and cash overdrafts is a limitation of this model, not a statement that banks prohibit them.
The useful result is an explained difference. A 900 consumption record and an 870 cash-flow record can both be right for this ledger. The 1,120 mixed total cannot be justified under either declared view.