If you take one structural idea from anything we publish, take this one. It decides whether food costing works in your business or is permanently approximate.
What you buy and what you sell are different things, and they need to be modelled separately.
The two lists
You buy ingredients: tomatoes, paneer, oil, flour, packaging. They arrive from suppliers, in supplier units, at supplier prices that change.
You sell menu items: a paneer tikka, a thali, a cold coffee. Customers order these. They have a price on a menu.
These are not the same list, and the relationship between them is not one-to-one:
- One ingredient appears in many dishes. Tomatoes go into four different curries.
- One dish uses many ingredients.
- Some ingredients are never sold directly at all — oil, salt, gas.
- Some items are bought and sold with no transformation: a bottled soft drink.
What goes wrong when you merge them
Plenty of systems keep one list of “products” and treat everything as a stock item. It seems simpler. It fails in specific ways:
You cannot cost a dish. If a curry is just a product with a price, the system has no idea it contains 200g of tomatoes and 100g of paneer. Food cost becomes something you calculate in a spreadsheet once a quarter, if ever.
Stock does not move when you sell. Selling a curry should reduce tomatoes. If the system does not know the curry contains tomatoes, your stock is only accurate at a physical count — and wrong every day in between.
Purchasing is disconnected from selling. You cannot answer “how much paneer do I need next week” from sales data, because nothing links sales to ingredients.
The correct model
Three parts:
- Ingredients — what you buy, in the units you buy them, with the prices you pay.
- Menu items — what you sell, with menu prices.
- Recipes — the mapping between them: this dish consumes these ingredients in these quantities.
The recipe is the bridge, and it is what makes everything else possible:
- Live food cost. The system knows what the dish costs from current ingredient prices, so margin is a live figure.
- Automatic stock movement. Selling the dish consumes its ingredients.
- Real purchasing forecasts. Expected sales convert into expected ingredient requirements.
- Menu engineering. Combining sales volume with true cost shows which dishes actually make money — often not the ones that sell most.
Why this is hard to retrofit
It is much easier to build this correctly at the start than to add it later, because merging the two lists is a decision that spreads. Once purchase orders, stock counts, sales and reports have all been built against one combined list, separating them touches everything.
If you are evaluating software, this is worth a direct question: does selling a dish reduce my raw ingredients automatically? If the answer is no, or “you can set that up manually”, you will be doing food costing in a spreadsheet indefinitely.