Every wallet balance, payout and card authorisation is a claim about money. The ledger is where that claim is recorded, and where it is proved.
Most teams underestimate it. A balance column works until the first retry, reversal or reconciliation break. Then it becomes the system nobody trusts.
This guide covers what a ledger must do, what building one takes, and how to decide. Buy it and you run on Ledgers as a Service.
What a ledger must do
| The property | Why your product needs it |
|---|---|
Double entry Every transaction writes at least one debit and one matching credit. The two sides sum to zero. | Money never appears or disappears. An imbalance is a bug you can see. |
Balances from entries Balances are computed from recorded entries, not edited in place. | Every balance traces back to the movements behind it. |
Reversals, not edits A mistake is corrected with an opposite entry. The original stays. | Your audit trail survives every correction. |
Idempotency A retried request returns the original result instead of posting twice. | A timeout never becomes a double payout. |
Posted, pending, available Three balances: what has settled, what is in flight, and what the customer can use now. | Cash-out checks the available balance, not the optimistic one. |
Reconciliation Every entry matches an external record: a rail reference, a bank statement, a network file. | Your balances and your bank’s agree, and you can prove it. |
What building one takes
The data model is the easy part. The hard part is everything around it: concurrency, retries, reversals, reporting and reconciliation.
And it never finishes. Uber’s ledger holds more than a trillion entries. Moving it to a new data store took two years, without downtime.
The cost of a first build depends on your team and scope.
Then there are the rails. InstaPay credits in real time and settles later. PESONet clears in three daily batches. Your ledger has to hold both timelines. How the rails move
When to build, and when to buy
| Build if | Buy if |
|---|---|
Where you differentiate How money is recorded is your product, and you can own it for years. | Your product wins on the experience built on top. |
Time to launch You can wait for a ledger before you ship. | You need balances on real rails this quarter. |
Rails You will build and maintain every rail connection yourself. | You want InstaPay, PESONet and QR Ph already posting to the ledger. |
Your engineers You can staff ledger engineering and finance operations permanently. | Your engineers are better spent on the product. |
Most teams should buy the ledger and own everything above it. Products rarely win on their ledger. They often break on it.
What TNKR’s ledger documents
TNKR Ledgers records every credit and debit as a balanced pair. Each ledger account holds its own posted, pending and available balances. See Ledgers
Corrections post as reversals. Every wallet movement posts as a double-entry transaction that sums to zero. See Wallets
Transfer and wallet writes take an Idempotency-Key header. Keys run up to 255 characters, scoped to your secret key and HTTP method.
Webhooks retry up to 12 times with exponential backoff. Deduplicate on the event ID.
Each transfer carries your reference number and the rail’s provider reference number. Match one to your records and the other to your bank statement.
Reconciliation runs against the rail files as they land, so your ledger and the rail agree without a manual pass.
Get started
Read documentation — see the ledger objects, balances and idempotency rules.
Talk to an expert — test your build-or-buy case with our infrastructure team.
Frequently asked questions
Originally published