Credit Card Accounting - Part 2

Part 1 ended with a requirement list and a question. The requirements: an honest bank journal, one account for the card debt, instalments without corrections, indifference to arrival order. The question: where does the card live inside pre-accounting? Modern pre-accounting stages everything in a staging ledger before it becomes a booking — receipts arrive as open payables, bank lines as cash movements, and a matching engine pairs them into settled transactions. Two designs compete for the card's place in that ledger.

Design one: a ledger per settlement channel

The explicit design says: settlement channels are different worlds, so give each its own staging ledger. A bank ledger holds what today's systems already hold. A credit-card ledger holds the card's purchases and the receipts they settle. An expenses ledger does the same for employees who paid privately. The card statement then touches two ledgers at once — its items settle receipts inside the card ledger, while its total becomes a payable in the bank ledger, waiting for the real lump sum:

It reads beautifully. Matching never crosses a ledger boundary, the card debt sits on its own account, the bank journal stays honest, and the next settlement channel is just the next ledger. But the design hides an assumption in plain sight: every receipt must be routed to the right ledger before matching can even begin. The system must know, upfront, that this restaurant bill was paid by credit card — possibly by which of the company's credit cards.

The fiduciary reality

For a company booking its own purchases the same evening, that may be a reasonable ask. For a fiduciary, it usually is not. Client documents arrive as a stack — paper, email, a folder of PDFs at quarter-end. The receipt itself rarely announces how it was paid: the same restaurant bill could have been settled from the bank account, the owner's private card, one of two company cards, or the petty cash box. The honest answer to "which ledger does this receipt belong to?" is, far too often, "we will know when the money shows up."

And a receipt routed to the wrong ledger does not merely match badly — it cannot match at all, because its counterpart lives in a ledger the matcher never looks at. Every misrouted document must be noticed, pulled out, and re-routed by hand. The corrections this design was built to avoid come back through the side door.

Design two: one ledger, many settlement paths

The generalized design inverts the assumption. There is one staging ledger, and receipts are universal: every receipt becomes an open payable with no opinion about how it will be paid. What varies is the other side. A payment is a cash movement against some balance-sheet account — the bank account when a bank line arrives, the card's liability account when a card statement item arrives, an employee's advance account when an expense report comes in. Matching then decides, entry by entry, who paid what. The receipt learns its payment path from the money — not the other way round:

Arrival order is irrelevant by construction — nothing is booked on match, so nothing depends on who came first. The bank journal and the card account come out exactly as in design one. The instalment from part 1 needs no correction in either design: the unpaid 55 simply stays standing on the card's account until the next bank line clears it.

The waiting game

The price is paid elsewhere. A single ledger in which everything is universal is a waiting room: open payables waiting for cash flows, card items waiting for receipts, settlement totals waiting for bank lines — all in one pool. The intelligence the ledger boundaries used to provide must now live in the matching engine. It scores candidate pairs by amount, by date, by wording, and has to conclude that the 50-franc restaurant payable belongs to the card's 50-franc item — not to the coincidental 50-franc bank movement from the same week. Ambiguity is the failure mode, patience the operating principle. The system grows more elaborate so that the documents may stay simple.

Both designs replicate the card faithfully; they differ in where they demand knowledge. One asks for it at intake, where a fiduciary often has none. The other waits for it at matching, where the cash flow eventually brings it. For a fiduciary workflow — documents from clients, statements from banks and card companies, and nobody in the room who remembers which card paid the restaurant — the second answer matches how knowledge actually arrives: with the money. A system built to wait does not need to ask.