Photo: Google Gemini · AI-generated
Ask a restaurant operator what they have in stock. You will get a number. That number is wrong, and everyone knows it.
This is not sloppiness. It is what happens when software built for boxes is pointed at food.
Most inventory systems rest on one assumption: the thing you buy is the thing you sell. Buy 40 units, sell 12, you have 28. That model is correct for phone cases. It is wrong for almost everything in a kitchen.
You never sell what you bought
You buy a 20 kg sack of flour. You sell croissants.
Between those two facts sits a recipe, a yield, and a person. The sack becomes dough. Some dough is lost on the bench. Some croissants burn. The portion is 62 grams in theory and whatever the baker’s hand says in practice.
So stock cannot be counted in the unit you purchased. It has to be modelled twice: as the thing you bought and as the thing you sell, with a recipe converting between them. Get that conversion wrong by three percent and your food cost is wrong by three percent — on every item, every day, silently.
This is why “we’ll just add inventory to the system later” tends to fail. Recipes are not a feature bolted on top of stock. They are the thing that makes stock mean anything.
Stock has a clock
The second difference is harder. A phone case does not expire. Cream does.
That means a quantity on its own is not a fact. Twelve litres of cream expiring Thursday and twelve expiring next month are different stock, and any system that stores them as “24” has thrown away the information that decides what you cook tonight.
Perishability changes the data model, not just the reporting. Every batch needs its own identity and date, movements have to be tracked per batch, and the system has to answer “what is closest to expiry” as easily as “how much is there”. Retrofitting that into a design that assumed one number per item usually means rewriting the core, which is why it so often doesn’t happen.
The count is a story about the past
Stock is not measured, it is inferred. You count on Sunday, then trust the system until the next count.
Everything in between comes from events — deliveries in, sales out, waste, transfers. If any of those event streams is missing or disagrees, the inferred number drifts, and nobody notices until the physical count contradicts it.
That is why the point of sale matters more than it looks. When we built Dinifi, a mobile-first POS and ordering platform for restaurants running across handheld POS, in-store iPads and menu displays, the interesting part was consistency: every device had to record the same event the same way. A sale rung up on a handheld and the same sale on a counter station cannot become two different facts. If they do, the stock number downstream is already fiction.
Multi-site multiplies all of it
Now run this across several sites and legal entities.
Geek ERP, which we built for a UAE hospitality group, had exactly this shape: allocation, ordering, inventory and billing across multiple companies in one group, each with its own structure and cost centres. The hard question was never “how much do we have” — it was “whose is it, where is it, and which entity carries the cost”. Transfers between sites are the awkward case, because one movement has to be a reduction in one place and an increase in another without briefly existing twice or not at all.
Before you buy forecasting
Predictive ordering and demand forecasting are real, and they work. But they sit on top of everything above.
A forecast is only as good as the consumption history behind it, and consumption history is exactly what recipes, batch tracking and reliable event capture produce. If those are shaky, a forecast does not fix the problem — it dresses it up and gives it a confidence interval.
So the sequence matters. Model the recipe. Give stock a clock. Make every device agree on what happened. Then forecast.
None of this is exotic engineering. It is custom work because the shape of the business genuinely differs from the shape of off-the-shelf inventory software — and pretending otherwise is what produces a stock report everyone quietly ignores.
If you are building or replacing food and beverage systems, we should talk.