The problem
Who owes what is the question a distributor asks every day, and the answer has to survive an argument: a customer says they paid, a manager says they did not. A single “balance” field cannot help. It says how much, never why.
Only additions
So there is no balance field. There is a journal: every sale, payment and refund is a signed entry, and the balance is the sum of the entries. Nothing in it is updated or deleted. A trigger in the database refuses such a statement outright, so not even our own code can do it by mistake.
A correction is an entry too
Mistakes happen. A wrong entry is not fixed, it is reversed: a new entry with the opposite sign, linked to the old one, with who made it and when. The history stays whole, and the statement a customer receives can show every step.
What it gives
- An answer to “why is this the balance?” for any date.
- A statement the customer can check line by line.
- Payments settled against specific documents.
- No quiet edits: the journal shows who did what.
What it costs
Reading a balance is a sum rather than a lookup, and a correction takes one more step in the interface. We think that is a fair price for numbers that can defend themselves. The same rule holds for cash movements.