Making a Ledger, a Billing System and an Audit Agree on Every Balance

Sun, 18 Oct 2026 00:00:00 +0000

Two systems that read the same events should end up in the same state. They often don’t, and the reason is rarely the code. It’s the order. A withdrawal that comes before a deposit gets declined; the same withdrawal after it goes through. If the ledger and billing see those two in a different order, they disagree on the balance, and both are right about what they saw.

This worked example has four branches and 300 accounts. Over four hours they produce 100,929 transactions: deposits, withdrawals that are declined when the balance is short, and 929 reversals that undo an earlier transaction and name it as their parent. The branches’ clocks are up to 0.8 seconds apart, so 77 reversals are stamped before the transaction they undo. The ledger and billing each get the transactions through their own queue, with their own delays. Later an auditor replays the four branch logs. Those were exported at least once, so 2,510 of their lines are there twice.

Audit on Inorderly.com

Making a Ledger, a Billing System and an Audit Agree on Every Balance