Money you can't reconcile is money you don't have

In March the books were off by $61.40 and everyone agreed it was rounding. In April the gap was $412. By June it was $9,300, nobody could say which direction it was wrong in, and the finance lead was spending the first four days of every month rebuilding the quarter in a spreadsheet that only she understood.

Nothing was stolen. Nothing was even broken, exactly. The company, a payments-adjacent platform moving a few million dollars a month, was doing what most young fintechs do: treating the processor's dashboard as the source of truth. Stripe said what came in, the bank said what landed, and the application database said what customers owed. Three systems, three clocks, three opinions, and no referee.

The drift was structural. A charge captured on the 30th settles in July. A refund issued today references a payment from two quarters ago. Disputes claw money back weeks after the revenue was recognized, processor fees come out of payouts in aggregate, and a currency conversion rounds differently on each side. Any one of these is explainable. Compounding monthly, they become a number that walks away from the books a few dollars at a time.

Your processor's dashboard is their ledger. It was never yours.

The fix is the oldest data structure in commerce wearing modern clothes: an internal double-entry ledger, plus a reconciliation loop that runs every single day.

The ledger part means your own system records every money event as balanced entries between accounts. A charge debits a Stripe-receivable account and credits revenue. A payout debits the bank and credits the receivable. Refunds, disputes, and fees are entries of their own, never edits to old rows. Entries are immutable and append-only, and the whole book must sum to zero at any moment; if it does not, the bug announces itself the same day it is born. You can build this on appendonly Postgres tables with database constraints doing the enforcement, and if you want the invariants guaranteed at the storage layer, TigerBeetle is an open-source database built for exactly this workload and nothing else.

The reconciliation part is a nightly job, Airflow or Dagster or a cron script with dignity, that pulls the processor's settlement records, Stripe balance transactions or a bank's BAI2 file, and matches them against your ledger entries one by one. Matched items close. Everything else lands in a break queue: a worklist of specific, dated, dollar-amounted disagreements, each one aging visibly until a human or a rule resolves it.

A break you find in a day is a line item. A break you find in a quarter is an investigation.

What changes is not just accuracy, it is the shape of the work. Month-end close stops being archaeology because the month was reconciled thirty times before it ended. Finance stops maintaining the haunted spreadsheet. And revenue becomes a number engineering and accounting can both stand behind, which matters enormously the first time an auditor, an acquirer, or a banking partner asks how you know your balance is right.

We stood this loop up at a platform caught in exactly the March-to-June spiral described above. The ledger backfill surfaced fourteen months of accumulated breaks in the first week, almost all of them fees and dispute reversals that had simply never been booked anywhere. Total damage was five figures, which stung, and it was the last week the number was ever unknown, which was the point.

The pattern is not glamorous and that is its charm. No model, no dashboard, no AI anywhere in sight, just the discipline of writing money down twice and checking it against the outside world every day. If your reconciliation currently happens quarterly, in a spreadsheet, or never, TensorLabs can stand up the ledger and the nightly loop inside a month, alongside your existing stack rather than instead of it. The money is already moving. What remains open is whether your books know where it went.