Why the stock ledger only ever appends
Most systems store a quantity and overwrite it. Hangar stores the movements and derives it. What that buys you the first time a number looks wrong.
Updated August 9, 2026
Ask any warehouse manager about the worst afternoon they have had with their inventory system, and the story has the same shape. A number on a screen is wrong. Nobody can say when it went wrong, who changed it, or what it was before. The system knows exactly one thing: what the quantity is right now. Everything that led to it has been overwritten.
That is not a bug in those systems. It is the design. A row holds a quantity, and every transaction updates the row in place. It is the obvious way to build it, it is fast, and it throws away the only information that matters when something goes wrong.
It is also one of the clearest lines between inventory software and a warehouse management system: one stores what is true now, the other stores how it came to be true.
Movements, not balances
Hangar stores it the other way round. Every receipt, putaway, pick, pack, count and correction is written as a movement, and the quantity in a bin is the sum of the movements affecting it. Nothing is updated in place, because there is no place to update. The record only grows.
That single decision changes what the software can honestly tell you.
An audit becomes a query. “How did this bin get to 240?” is answerable in full, down to which scanner posted which movement and when. Not reconstructed or inferred, just read back.
A correction is a new row. When somebody counts a bin and finds the system wrong, Hangar does not edit history to make it right. It appends an adjustment that points at what it corrects and carries the reason code the counter chose on the scanner. Six months later you can still see both the original movement and the correction, which is exactly what you need in order to work out why it happened again.
Balances are rebuildable. Because quantity is derived rather than stored, it can be recomputed from the record at any time. A derived number and its history cannot drift apart, because they are the same thing.
The part that matters on the floor
There is a practical version of this argument that has nothing to do with audits.
Two pickers reach the same bin at the same time. In a system built on updating a stored quantity, that is a race, and the loser either overwrites the winner or gets an error that makes no sense to a person holding a scanner. Systems handle it with locks, which turn a busy aisle into a queue, or they handle it badly and quietly lose a movement.
When each pick is an appended movement, there is nothing to contend over. Both scans are recorded. The quantity reflects both. Contention on the same bin stops being an exceptional case that needs defending against and becomes the ordinary behaviour of a busy warehouse, which is what it always was.
What it costs
Honesty requires saying what the trade is. An append-only ledger uses more storage than a table of quantities, and reading a balance means summing rather than looking up. Both are real, and both are solved problems: the sums are maintained incrementally, and storage is the cheapest thing in the building.
What you get for it is a system that can always tell you how it arrived at a number. In a warehouse, that is usually the question.
Common questions
- What is an append-only stock ledger?
- An append-only stock ledger records every inventory movement, such as a receipt, putaway, pick, pack or count, as a new row that is never edited or deleted. The quantity in any bin is derived by summing the movements that touched it, rather than stored as a number that gets overwritten. Every balance therefore carries its full history, and the system can always show how it arrived at a number.
- How do you fix a wrong quantity if nothing can be edited?
- With a correction, which is itself a new movement. When a count finds a bin wrong, Hangar appends an adjustment that points at the movement it corrects and carries the reason code the counter chose on the scanner. The original and the correction both stay visible, so months later you can still see exactly what happened and why, which is what you need to stop it happening again.
- Does an append-only ledger make the system slower?
- Reading a balance means summing movements instead of looking up a stored number, and the record uses more storage than a table of quantities. Both costs are real, and both are solved problems: the sums are maintained incrementally rather than recomputed from scratch, and storage is the cheapest thing in the building. In exchange, the number on screen and the history behind it can never disagree, because they are the same thing.
- What happens when two pickers hit the same bin at once?
- In a system that stores a quantity and updates it in place, two simultaneous picks are a race: one scan can overwrite the other, or a lock turns a busy aisle into a queue. In an append-only ledger there is nothing to contend over. Both movements are recorded and the derived quantity reflects both, so contention at a bin becomes ordinary behaviour rather than an error case.