What a register of balances is
Some numbers in a business are not facts you look up. They are the result of everything that ever happened to them.
How many points this customer has. How much of this item is in that warehouse. What this counterparty owes us. How much of the department's budget is left. Nobody enters those numbers; they are what is left after a long series of additions and subtractions, and their whole value is that the series adds up.
That is a register of balances, and this module is one - built once, for every application on the platform that needs to keep a running total.
Why not just a column
Because a balance kept as a number you overwrite goes wrong, and it goes wrong quietly.
Two operations arrive at once and one of them is lost. A correction is applied twice because somebody clicked twice. A refund is entered but the reason is not, so six weeks later nobody can explain the figure. The balance says 4,300 and no one can prove it should. And the worst version: the number is fine but nobody can tell you why it is fine, so nobody trusts it and a parallel spreadsheet appears next to it.
The failure is not carelessness: a single mutable number carries no record of how it got there, so nothing can check it.
Double entry, and what it buys
The answer is four centuries old and it has not been improved on: never change a balance - record a movement. Every movement has at least two sides, and they sum to zero. Points do not appear; they move from the issuing account to the customer's. Stock does not vanish; it moves from the warehouse to the shipment. Money owed does not decrease; it moves against a payment.
Three things follow:
- A balance is never asserted, it is derived. It is the sum of the movements that produced it, and every one of those movements is still there with its date, its amount, its reason and whoever caused it. "Why is it 4,300" is a query, not an argument.
- An error is detectable from the inside. Because the sides of every movement cancel, the total across all accounts of an asset must be exactly zero. If it is not, something is wrong - and you learn that from the register itself, without a bank statement or a stock count to compare against. The platform checks this on a schedule.
- The past does not move. A correction is a new movement that reverses an old one, not an edit to what was recorded. So a period you closed stays closed, and a report run today about last quarter says what it said last quarter.
Reservations: the part people forget
The other half of a real balance is what is spoken for but not yet spent.
The customer has 5,000 points and a pending order for 2,000 of them. The warehouse has 40 units and 30 are allocated to shipments that have not left. The budget has 200,000 and half is committed to approved purchase orders.
The platform tracks held amounts separately from movements, so the journal stays a pure record of what happened, and the number everyone needs is one subtraction away: available = balance minus held. Two people cannot spend the same unit, and nothing has to be posted and then unposted when a cart is abandoned.
Where to go next
- What you can do - the shapes this covers: points and loyalty, stock with batches and expiry, settlements, limits - and how a document like a cart or an order sits above it.
- Under the hood - what makes it correct under concurrency: integer amounts, ordered locks, database-enforced isolation, and reconciliation that reports rather than repairs.