Every POS shows a food cost percentage. In most restaurants we open, that number is wrong — not by a rounding error, but by enough to hide a five-figure annual leak. Here is how the number is built, what UAE-specific things break it, and how to read the gap between the two versions of it.
What the recipes say the items you sold should have consumed, priced at your current invoice prices. It comes out of the POS or the inventory system, and it is only as true as the recipe database behind it.
Cost of the recipes behind items sold ÷ net sales
What really left the store. It needs a stock count at both ends of the period, and it is the number your accountant recognises.
(Opening stock + purchases − closing stock) ÷ net sales
Both are correct calculations of different things. The distance between them is the part worth money: waste, over-portioning, unrecorded staff meals, theft, recipes that were never registered, invoices that never reached the ledger. A restaurant that only looks at one of the two numbers cannot see that distance at all.
Aggregator menu prices are usually marked up, and Talabat, Deliveroo, Careem and Noon keep a commission before paying you. Divide by the gross platform sales and your food cost looks a point or two better than reality. Use net revenue — what arrived in the bank.
Sales must be net of the 5% VAT collected and purchases net of the VAT recovered. Gross sales against net purchases is a silent one-to-two point error that never resolves itself.
Much of a UAE kitchen's basket is imported, and prices move between deliveries without anyone telling the kitchen. If the recipe database still holds last quarter's prices, the theoretical cost is a historical document.
Two brands out of one kitchen, or a second branch borrowing stock, will distort both stores' cost lines unless transfers are recorded on both sides on the same day.
| Step | What to do | What it tells you |
|---|---|---|
| 1 | Take last month's net sales, VAT removed, aggregator commission removed. | The denominator that everything else divides by. Most errors are here. |
| 2 | Add every supplier invoice for the month, VAT removed. Include the cash purchases the manager made from the supermarket. | Purchases. The petty-cash line is the one most often missing. |
| 3 | Take the stock count value at the start and end of the month. | If you do not have both, you cannot calculate actual food cost at all — that is itself the finding. |
| 4 | Actual = (opening + purchases − closing) ÷ net sales. | The real cost of the month. |
| 5 | Read the theoretical percentage off the POS for the same period. | The recipe version of the same month. |
| 6 | Subtract. Multiply the difference by net sales. | The gap in dirhams. This is the number to act on, not the percentage. |
If the answer is uncomfortable, that is normal on a first run. Ninety per cent of the gap usually turns out to be four or five causes, and most of them are data rather than dishonesty.
Every item sold needs a registered recipe with real yields and real portions, including modifiers and the platform-only items. Until this is true, no percentage from the POS means anything.
Invoice prices updated on a fixed day each week, with a price-movement list so the owner sees what went up before the month ends.
A stock count that actually happens, on the same day, by the same method, counting the same units the invoices use. Weekly for the top-value items, monthly for everything.
There is no single right number — it is set by your menu and your channel mix, not by the industry. A cafe selling coffee and pastry runs a very different cost line from a grill house. The number that matters is your own theoretical cost, calculated from real recipes and real invoice prices, and how far your actual cost sits from it. A gap of more than three or four points between the two is where the money is, whatever the headline percentage is.
Yes, but not at the price the customer paid. Aggregator menu prices are usually marked up, and the platform keeps a commission. If you divide food cost by gross delivery sales, your food cost looks better than it is. Calculate food cost against net revenue — what actually reached your bank — and delivery stops flattering the number.
No. Take VAT out of both sides. Sales are counted net of the 5% VAT you collected, and purchases are counted net of the VAT you can recover. Mixing gross sales with net purchases is the most common reason a food cost percentage is off by a point or two for no visible reason.
They are two different calculations. The POS reports a theoretical cost — what the recipes say the sold items should have consumed. The accountant reports an actual cost — opening stock plus purchases minus closing stock. Both can be right and still disagree; the distance between them is waste, theft, over-portioning, unregistered recipes or missing invoices. That distance is the finding, not an error.
Actual food cost needs a stock count, so monthly at minimum and weekly if you can hold the discipline. Theoretical cost can be read any day once recipes and prices are correct. Owners who see it weekly catch a supplier price rise in days instead of at the end of the quarter.
The 10-day Number Audit calculates both numbers from your own data and puts the difference in AED, with the causes ranked. Fixed fee, quoted before we start.
See the Number Audit