A POS reports a theoretical food cost: what the recipes in its database say a dish should cost to make. That number is only as good as the data behind it, and in most restaurants we audit the data has not been touched since opening week. These are the seven failures we find most often, in the order we fix them.
The menu changed, the portion changed, the supplier changed. The recipe in the POS is still the one the opening chef typed in. Every plate is costed against a dish you no longer serve.
Purchase orders are created and received, but never finalised, so the ingredient cost in the master never moves. Butter went up; the POS still thinks it is last year's price.
Specials, new items, combos added in a hurry. They sell every day and cost nothing on paper, which quietly pulls the whole food-cost figure down.
The recipe says 180 grams; the line plates 220. The recipe assumes a whole fish yields 60% of usable meat; yours yields 45%. Neither is fraud. Both are money.
An ingredient bought by the case and costed by the piece, or a price entered per kilogram against a recipe in grams. Unit errors are how a spreadsheet ends up with a price ten times off.
"Extra cheese", "make it a meal", "large" — each one adds ingredients, and most POS setups add them to the price without adding them to the cost.
This one breaks the actual side. If nobody logs what was thrown away, eaten by staff or given away, the count says the kitchen used more than it sold, and the gap looks like theft when it is mostly untracked usage.
Theoretical food cost comes from the POS: sales × recipe cost. Actual food cost comes from the real world: opening stock + purchases (from invoices) − closing stock (from a count). The difference between the two is waste, theft, over-portioning, unrecorded usage and data errors, in some mix you cannot see until the data is clean.
That is why the fix order above matters. Clean the recipes, prices and units first, and the theoretical number becomes trustworthy. Then the gap to actual stops being noise and starts being a list of causes — which is what the Number Audit produces, in dirhams.
| Side | Built from | Wrong when |
|---|---|---|
| Theoretical | POS sales × recipe cost per item | Recipes, prices, units, yields or modifiers are stale |
| Actual | Opening stock + invoiced purchases − closing count | Counts are skipped, invoices are missing, waste is not logged |
| The gap | Actual − theoretical | Meaningless until both sides are clean; then it is your fix list |
If two or more of these come back wrong, the food-cost figure on your dashboard is not a number. It is a guess.
There is no single number worth chasing: a bakery-café, a burger delivery kitchen and a fine-dining room have different right answers. The useful comparison is your own theoretical food cost (what the recipes say) against your actual food cost (what you bought and counted). The gap between those two is the number that tells you where money is going.
Almost never. The report is wrong because of the data behind it — recipes, prices, units, yields — and that data moves with you to any system. Fix the masters in the POS you have; a migration only gives you a clean-looking report built on the same broken inputs.
For a typical single-store menu, a few weeks of steady work: costing every item that sells, retiring the ones that don't, fixing units and yields, and setting a rule for who updates a recipe when the kitchen changes it. The hard part is not the first clean-up; it is keeping it true afterwards.
That is what Monthly Ops is for: recipe and price masters maintained, purchase-price movements listed, and a variance report each month. The Number Audit is where most owners start, because it puts the current gap in dirhams first.
Ten working days, three gaps in dirhams, fixed fee. Bring last month's POS summary and your supplier invoices.
See the Number Audit