Build or buy a ledger: the ten problems you inherit either way

A ledger is one of the most tempting things to build in-house, because the first version is small. Two tables, a balance check, an API. Most teams that build one get it working in a week. The next eleven months are spent discovering the problems that were not in the week.

Here are the ten, in the order teams usually meet them.

1. Rounding. Money stored as an approximate number loses fractions on every calculation. Nobody notices until an audit, after millions of transactions, when the books are off by an amount that cannot be explained or repaired without replaying history.
2. Books that do not balance. The application checks that debits equal credits; the importer written later does not. One path around the check is enough.
3. Overdrafts under load. Ten requests read the same balance at once and all approve a spend. Standard code gets this wrong, and the textbook fix collapses under traffic on busy accounts.
4. Retries that pay twice. A timed-out request is retried, and the record of the first attempt and the money movement are separate steps. A crash between them pays twice or reports a payment that never happened.
5. Ghost entries. A declined transaction leaves half an entry behind, creating money that does not exist.
6. One customer seeing another. A shared ledger is one missing filter away from showing one business’s money to another.
7. A history that can be edited. Access control is not immutability. If deletion is possible, some day it will happen.
8. The account everyone touches. A shared control account is in every transaction. Lock it and throughput dies; do not lock it and overdrafts return.
9. Changing the schema in production. A financial system cannot pause, and a careless change to a live table stalls everything in flight.
10. Proving the books are right. Even a correct ledger needs an independent, continuous check that the totals match the entries. Without it, corruption is found months late.

The pattern

Problems one to five are visible in the first months and get fixed, usually correctly. Six and seven are discovered by incidents. Eight and nine arrive with growth. Ten is discovered by an auditor or never. The build is not expensive because any one problem is hard; it is expensive because each fix interacts with the others, and a team that has solved eight of ten has a ledger that is wrong in the two ways that are hardest to see.

What buying should mean

Buying a ledger is only worthwhile if the vendor has solved all ten in a way you can check. That means each problem maps to a mechanism, each mechanism is enforced by the database rather than by convention, and each is guarded by a test you can read about — ideally one that was run adversarially by someone who wanted it to fail.

That is the standard Ledger holds itself to. The why Ledger page pairs each problem with what Ledger does about it, the guarantees page names the enforcement and the check, and the assurance pages publish the audit history, including the round that was refused.

A fair way to decide

Where the year goes

The estimate of a year is not a guess about typing speed; it is where the ten problems fall on a calendar. The first month produces a working ledger that handles the happy path. The second and third fix rounding and balancing once the first reconciliation report disagrees with itself. Overdrafts under load appear when traffic does, which is usually the first successful marketing campaign, and the fix touches locking, ordering and every hot account. Retries that pay twice are discovered by a customer, never by a test, and the fix is a redesign of the write path rather than a patch.

By the second half of the year the team is solving problems six to ten: isolation, immutability, the hot account, live schema changes and continuous reconciliation. Each of those is a piece of infrastructure in its own right, and each interacts with the others. The people doing this work are the same people who were supposed to be building the product.

Questions for a vendor demonstration

If you decide to evaluate a hosted ledger, the demonstration should be run by you, not by the vendor. Bring these:

• Post an unbalanced transaction directly, bypassing their API if they will let you, and watch it fail.
• Send the same transfer twice with the same key and confirm nothing moved the second time. Then send a different transfer under the same key and confirm it is refused.
• Hit one account with twenty simultaneous spends that together exceed its balance. Count exactly how many succeeded.
• Ask for the balance as it stood yesterday at a given minute.
• Ask to see the record of the last audit and what it found. A vendor with no findings to show has either never been audited or is not telling you.

Ledger will pass the first four on any tenant you are given, and the fifth is published.

Write down the ten problems and, for each, who on your team will own it in year three. If the answer is a name, build. If the answer is a shrug, buy — or at least try Ledger against your own test plan first. It is free today, and access is a conversation away.