The double-entry ledger core from my fintech practice, productised: append-only events, enforced double-entry postings, balances as rebuildable projections, idempotent APIs and reconciliation hooks — deployable in your infrastructure as your product’s money foundation, in weeks. Status: preview — engagement-proven core, self-serve packaging in progress.
Why does every money product rebuild this badly?
Because the deadline arrives before the wisdom does. Every funded product that touches money — wallet, marketplace, lending, SaaS with credits — needs a ledger on day one, and on day one the team builds the obvious thing: a balances table, a transactions table, optimism. It demos perfectly. It survives the first audit because the first audit is polite. Then volume arrives, and with it the double-fired webhook, the refund that skipped the rules, the “quick fix” UPDATE at 2 AM — and eighteen months later the company is living the ledger-drift story, paying senior engineers to do archaeology on their own database.
The pattern is so reliable it has a page on this site, a case study, and now a product. The platform exists so your team ships product features on a foundation that has already survived the hard thinking — the architecture from /services/fintech, pre-built, documented, and yours to own.
What does the Ledger Platform include?
- Event-sourced core. Every money movement an immutable event; corrections are new entries, never edits. Full replay supported — the ledger can rebuild itself from history, which is the property auditors trust and incidents demand.
- Double-entry postings, enforced. Configurable chart of accounts; every event posts balanced debits and credits, with imbalance rejected at the write — structurally impossible, not policed by review. Pacioli’s 500-year-old invariant, compiled.
- Balances as projections. Computed from entries, cached for speed, rebuildable from scratch at any moment. When cache and truth disagree, truth wins by construction.
- Idempotent APIs. Every mutation carries a key, enforced at the storage layer; replays become no-ops and the double-webhook problem dies at the schema, not in a try-catch.
- Reconciliation hooks. Statement and settlement-file ingestion, matching rules, exception queues with reason codes — the recon discipline as first-class platform surface, not an aftermarket Excel.
- Operational surface. Audit query console, maker-checker on manual entries, access trails throughout — the finance team’s questions answered with evidence attached.
- Webhooks and typed errors out. So your product code consumes ledger facts cleanly instead of polling and guessing.
How does it deploy, and who holds the keys?
In your infrastructure, always. Money data never leaves you — which collapses the data-residency puzzle (DPDP in India, GDPR for UK-facing products, PDPL in the UAE all get simpler when there’s no third party holding the books) and removes the per-transaction tax that SaaS ledger APIs charge forever. I deploy it, integrate it against your gateways and products, and hand over a system your team operates — with the platform docs carrying the architecture guides, API references and runbooks.
Migration onto it uses the only method I trust with live money: history replayed as events, parallel-run against your current system until the diff holds at zero, cutover behind a flag. The ledger rebuild ran exactly this playbook; the migration case study shows the discipline at its most demanding.
What’s the honest pitch?
If your roadmap says “fix the ledger” every quarter and it never happens, that’s not a prioritisation failure — it’s that rebuilding a foundation under a live product is genuinely hard, and product pressure always wins the argument. The platform changes the shape of the problem: the foundation arrives built, the migration is a method rather than a leap, and your engineers go back to shipping the product instead of maintaining optimism.
And the proof is unusually public for a money product: the architecture is explained across the ledger design article, the failure modes it prevents in why ledgers drift, and the same patterns documented in production at scale across fourteen company teardowns — Stripe’s idempotency, Nubank’s ledger discipline, PhonePe’s reconciliation at UPI volume. You can audit the thinking before you audit the code. Foundation ready hai.
Who is this for — and who should not buy it?
For: funded products where money moves and the ledger is core infrastructure but not the product itself — marketplaces settling sellers, lenders servicing books, SaaS with wallets or credits, platforms holding user balances. If your engineers are building product features on top of money truth, the platform is the floor under them. Not for: businesses that need accounting software — Tally and its peers already do statutory books well, and this is not that; and not for teams that want a fully-managed SaaS where someone else operates the infrastructure — sovereignty is the point here, and sovereignty includes operating what you own, runbooks provided. If you are unsure which side you fall on, the first call sorts it honestly — including the occasional answer that a well-configured Postgres schema and the recon layer alone will carry you another year.
Related reading
/services/fintech — the practice behind the product · /work/ledger-rebuild — the proof engagement · /blog/ledger-design — the schema, in public · /products/platform-docs — the documentation
The quarterly-promise test
Count how many quarters “fix the ledger” has survived on your roadmap. If the answer is more than one — /contact, and bring your current schema. The first call tells you honestly whether you need the platform, the rebuild engagement, or just the recon layer first.
Questions I actually get
Why not just build the ledger in-house?
You still own everything here — the platform deploys into your infrastructure and the code is yours to hold. What you skip is the two years of hard-won lessons between a balances table and a correct ledger: the idempotency edge cases, the projection rebuild discipline, the reconciliation hooks. You start from year three instead of year zero, with the scars pre-earned.
Why not a SaaS ledger API instead?
Sovereignty. No per-transaction tax to a third party forever, no data residency puzzles — DPDP, GDPR and PDPL all get simpler when money data never leaves your infrastructure — and no business-model risk of your ledger vendor repricing once you are locked in. SaaS ledgers are fine products; they are just not yours.
Will it scale to our volume?
The architecture is Postgres-backed, partition-ready, with balances as cached projections — the same pattern my published teardowns show carrying national payment volume at companies like PhonePe and Nubank. Right-sized deployments start far below that and grow by partitioning, not re-architecture. Scale is a configuration journey here, not a rewrite.
How do we migrate our existing balances and history onto it?
With the parallel-run method: history replayed into the platform as events, balances reconciled against your current system until the diff holds at zero, then cutover behind a flag. It is the same discipline as the zero-downtime migration case study, because your money history deserves nothing less careful.
What is the preview status, honestly?
The core is deployed and battle-tested inside client engagements — the ledger rebuild ran on exactly this architecture. What is still maturing is the self-serve packaging: docs, deployment tooling, the experience of adopting it without me in the room. The preview tag stays until a stranger can demo it unaccompanied, because that is what the tag means on this site.
What does the operational surface include for our finance team?
An audit query console for the questions auditors actually ask, maker-checker on any manual entry, immutable trails on everything, and reconciliation exception queues with reason codes. Finance teams stop being database supplicants — the answers they need are theirs to pull, with the evidence attached.