Ask a restaurant owner how much chicken they have and you usually get a number. Ask how it got there and the answer is a shrug. That gap — between the balance and the story — is where shrinkage lives.
The problem with a single balance
A stock table that stores quantity_on_hand and subtracts on every sale answers one question: how much is left. It cannot answer:
- Was the 4 kg of buff missing because of a sale, a spoilage write-off, or a delivery that was never entered?
- Why is the food cost 41% this month when the menu prices did not change?
- Which supplier shorted us twice in a row?
Every one of those is a movement, not a balance.
What a movement ledger records
Each row is one event, and it has a direction, a reason, a unit and an actor:
| Movement | Direction | Why it exists |
|---|---|---|
| Purchase receipt | in | supplier delivery |
| Sale consumption | out | recipe × quantity sold |
| Wastage | out | spoilage, breakage, staff meal |
| Transfer | in/out | between branches or stores |
| Adjustment | in/out | physical count correction |
The balance is then a SUM() over the ledger, not a mutable column. When the number is wrong, you can open the ledger and read the story backwards until it stops making sense — which is exactly where the problem is.
The three shrinkage patterns this exposes
- Unit mismatch. Buying in kilograms, selling in grams, and typing "2" into a field that means kilograms. The ledger shows a 1000× jump that a balance report hides.
- Unrecorded waste. The kitchen trims 200 g off every fish and nobody logs it. After a month the recipe cost is 15% off and the variance looks like theft.
- Receiving errors. The supplier invoice says 20 kg, the delivery was 18 kg, and the receiver signs without weighing. A receipt that must match a purchase order catches it the same day.
Implementing it without slowing the kitchen
The rule that makes this work in practice: the kitchen never types a stock number. Consumption is derived from recipes and sales, automatically. Humans only record what the system cannot infer — waste, transfers and counts.
That means:
- recipes are maintained once per dish, with yield percentages,
- a sale posts its consumption in the same transaction as the invoice,
- a weekly count becomes an adjustment, not a re-typing exercise,
- variance reports compare theoretical consumption against actual counts.
What to look at every Monday
A ten-minute weekly ritual beats a monthly panic:
- Top five items by variance (theoretical vs counted).
- Any item with more than two adjustments in a week.
- Any recipe whose cost moved more than 8% since last month.
- Deliveries received without a matching purchase order.
None of this requires a data analyst. It requires the ledger to exist in the first place — and a balance column will never be a ledger.