← All concepts
Data & storage
Double-entry ledger
Record every money movement as balanced debits and credits so money can never appear or vanish.
Instead of updating a balance column, payments systems append entries: debit one account, credit another, summing to zero. Balances are derived from entries, and the full history is an audit trail.
See it in action
Play with the idea, then follow it through a real architecture.
Try it: post a refund
Nothing is ever edited. A refund is new entries that reverse the payment — and debits always equal credits.
| Transaction | Account | Debit | Credit |
|---|---|---|---|
| Payment #1001 | Card clearing | $100.00 | |
| Payment #1001 | Merchant payable | $97.00 | |
| Payment #1001 | Fee revenue | $3.00 | |
| Totals ✓ balanced | $100.00 | $100.00 | |
Balances (derived from entries): Card clearing $100Merchant payable −$97Fee revenue −$3
Laying out diagram…
1/5A $100 card payment is captured.
- Payment service
- — Emits a 'captured' event
- Payment events
- — Ordered per payment
- Ledger service
- — Turns events into balanced entries
- Ledger
- — Append-only journal
- Bank settlement
- — What really moved
- Reconciliation
- — Compares the two nightly
How it works
- Entries are append-only; mistakes are fixed by new reversing entries.
- Periodic balance snapshots keep reads fast.
- Reconciliation compares the ledger with bank settlement files.
Trade-offs
- More rows and stricter discipline than a simple balance field.