Design review
A read of how money is represented today and where it can drift, ending in a written ledger model — accounts, movements, invariants, and the reconciliation strategy.
Most platforms don't set out to build a ledger. They add a balance column, then a pending column, then a spreadsheet that explains the difference — and by the time anyone calls it a ledger, finance no longer trusts it. We design the thing properly, in one pass.
Someone is reconciling by hand, every month.
Balances are derived by summing rows at read time. It works until a retry, a partial refund, or a race writes the same movement twice, and then nothing can prove which number was ever right.
Conversion happens in application code at varying moments, so the same transaction reports different values depending on who asks and when.
The spreadsheet that corrects the system is the clearest signal the system is not the source of truth — and it is load-bearing long before anyone admits it.
Immutable movements, derived balances, provable totals.
Double-entry movements as the only way money changes hands, with accounts modelled per party and per currency. Entries are appended and never edited, so history is reconstructible and a correction is a new entry rather than a mutation nobody can see.
Currency held as a property of the account rather than converted in transit, with the rate and its timestamp recorded on the movement that used it. Conversion becomes an explicit, auditable event instead of a number that cannot be reproduced later.
Automated reconciliation against provider settlement reports, with breaks surfaced as a worklist rather than found at month end. The goal is that nobody opens a spreadsheet to answer "why don't these agree".
Every movement keyed so a retried webhook or a replayed job cannot double-post, and ordering that holds under concurrency. This is the difference between a ledger that survives an incident and one that quietly diverges during it.
Design review
A read of how money is represented today and where it can drift, ending in a written ledger model — accounts, movements, invariants, and the reconciliation strategy.
Build sprint
Implementation with your team, including the migration path from whatever exists now. Backfilling history into a new ledger is usually the hardest part and the part most plans omit.
Retainer
Ongoing review as currencies, payout methods, and party types are added — each one a change to the money model, not merely a configuration change.
Decades on core financial systems, and a payout platform of our own.
Track record
High-throughput payment systems and real-time transaction pipelines, plus lead and architect work on tax engines at Amazon spanning global, state, and federal jurisdictions — where getting the number provably right is the whole job.
Full track record →In-house venture
A two-sided marketplace we built and operate, with payments and payouts on both sides of the market — so the reconciliation problem described here is one we own rather than one we have only reviewed.
imerzn.com →Sometimes, and we will say so. The design work is the same either way: a product you cannot model your money in is not cheaper than one you can, and the decision is easier once the model is written down.
The cost of retrofitting a ledger rises with the amount of history you have to backfill. Early is cheap. It becomes urgent when the manual reconciliation starts.
Usually yes — writing to both and comparing is the normal migration path, and the comparison is how you earn the confidence to cut over.
No. We build the system your accountants can rely on, and we work with them on the chart of accounts. We are not your auditors and will not pretend otherwise.
Describe how money is represented today, which currencies are involved, and what someone currently fixes by hand. We reply within two business days.