Most recipe costing software demos show the same thing: a dish, a list of ingredients, a cost per portion. That part is easy and every product does it. The differences only appear at the point where your kitchen actually gets complicated.
This guide gives you five tests to run in any demo. They are ordered by how often they catch a product out, and they work whether you are moving off spreadsheets for the first time or replacing something that has stopped keeping up.
Why does recipe costing break when a kitchen scales?
Costing twenty dishes by hand is manageable. Costing two hundred, across three sites, with a supplier price list that moves weekly and a menu that changes seasonally, is a different problem entirely.
The failure is rarely dramatic. It is a stock nobody costed, a yield figure entered once in 2024, a sub-recipe that got duplicated rather than linked. Each is small. Together they mean your theoretical food cost drifts away from reality until the variance number stops being useful.
The Five Layer Test
Recipe costing is five layers deep. Products that only handle the first layer look identical to products that handle all five, right up until you need the other four. Ask for each layer to be demonstrated on your own data, not on the vendor's demo menu.
1. Layer one, the ingredient. Cost per unit, correctly converted between purchase unit and recipe unit.
2. Layer two, the yield. Trim, waste and cooking loss applied so the cost reflects the plated portion.
3. Layer three, the sub-recipe. Stocks, sauces, doughs and prep costed once and linked, never duplicated.
4. Layer four, the price movement. Recipe costs update automatically when a supplier price changes.
5. Layer five, the allergen. Allergen data carried on the ingredient and inherited by every recipe that uses it.
Layer one: does it convert units properly?
You buy in cases and kilograms. You cook in grams and millilitres. Every conversion is a place for an error to enter, and manual conversion is where most spreadsheet costing quietly goes wrong.
Test it by asking the vendor to cost a dish using an ingredient you buy in an awkward unit. A case of twelve, a bag priced by weight but portioned by count, an item sold by volume and used by mass. If the answer involves you maintaining a conversion column yourself, the product has not solved the problem.
Before any demo, it is worth costing two or three of your own dishes by hand so you have something to check against. The free food cost calculator will do that in a few minutes without an account.
Layer two: does it account for yield and trim loss?
This is the layer that catches the most products out. A recipe cost calculated on raw purchase weight will understate every dish that loses weight in prep or cooking, and it will do so consistently rather than randomly.
Illustrative example, not an attributed client figure: a kitchen costing a cooked portion against its raw purchase price on a braise that loses around a third of its weight is understating that dish by a material amount on every cover. The sheet is not wrong by accident. It is wrong by design.
Ask specifically whether yield is set per ingredient, per recipe, or both. Per ingredient only is not enough, because the same product trims differently depending on the preparation.
Layer three: how does it handle sub-recipes?
A sub-recipe is anything you make in-house that goes into something else. Stocks, sauces, doughs, pickles, batch preps. In a busy kitchen these represent a large share of true plate cost and they are the most commonly uncosted item on the menu.
The test is whether a sub-recipe is costed once and linked into every parent recipe, or copied into each one. Copying looks fine on day one and becomes unmaintainable the first time the supplier price of a base ingredient moves, because now you have twelve places to update instead of one.
Ask to see a sub-recipe nested two levels deep. A sauce that uses a stock that uses a mirepoix. Products that handle one level often fall over at two.
Layer four: what happens when a supplier price moves?
Recipe costs are only as current as the prices underneath them. If updating a supplier price means re-costing recipes by hand, the costs will be accurate the week you set them up and progressively less accurate every week after.
What you want is a live price list per supplier, with every recipe that uses an affected ingredient re-costing automatically, and a flag when a line moves beyond a threshold you set. That turns a price increase into a decision rather than something you discover at month end.
This is the point where recipe costing stops being a standalone tool and becomes part of stock control, which is why it sits inside recipe management software connected to purchasing rather than beside it.
Layer five: does allergen data travel with the ingredient?
Allergen management and recipe costing draw on the same underlying data: what is in each dish, in what quantity, from which supplier. Keeping them in two systems means maintaining the same ingredient list twice, and the two will diverge.
The scale of the requirement is not marginal. According to the Food Standards Agency (May 2024), around 6% of the UK adult population have a clinically confirmed food allergy, roughly 2.4 million adults, with more than 30% reporting some form of adverse reaction to food.
Test whether allergen flags are held against the ingredient record and inherited automatically by every recipe and sub-recipe that uses it. Manual re-tagging per dish is the same maintenance problem as copied sub-recipes, with a much higher consequence when it goes wrong.
Spreadsheet or recipe costing software: where the line falls
|
Layer |
What a spreadsheet does |
What recipe costing software should do |
|
Ingredient |
Works, if you maintain the conversion column by hand |
Converts purchase unit to recipe unit automatically |
|
Yield |
Possible, but usually entered once and never revisited |
Yield per ingredient and per recipe, applied at cost time |
|
Sub-recipe |
Copied into each parent, so updates multiply |
Costed once, linked, nests to multiple levels |
|
Price movement |
Manual re-cost, so accuracy decays weekly |
Recipes re-cost automatically, threshold alerts on movement |
|
Allergen |
A separate sheet that drifts from the costing sheet |
Held on the ingredient, inherited by every recipe |
|
Multi-site |
One file per site, reconciled by hand |
One item list, comparable across sites from one dashboard |
What should you ask in the demo itself?
Bring your own data. A vendor demo menu is built to demonstrate strengths. Your menu is built to feed people and it will contain the awkward cases.
• Cost one dish that uses a sub-recipe which itself uses a sub-recipe.
• Cost one dish using an ingredient you buy in an awkward unit.
• Change a supplier price during the demo and ask to see which recipes moved.
• Add an allergen to an ingredient and ask to see which dishes inherited it.
• Ask what happens to costed recipes when the menu changes seasonally.
Also ask how long implementation actually takes and what the support arrangement is once you are live. Onboarding friction is a common reason costing projects stall halfway, and it is easier to ask about before signing than after.
What does good look like once it is running?
Operators using StockTake Online typically identify up to 3 to 8% in recoverable food cost within the first 60 days of going live. As with any range, the starting point matters: a kitchen already costing to sub-recipe level will find less than one working from a laminated card.
The honest test is whether the system changes a decision each week. A dish re-priced because its true cost moved. A supplier increase challenged. A sub-recipe simplified because the costing exposed how expensive it actually was.
For the practical side of costing in a cafe setting, our guide to recipe costing for cafes works through cups, counter and to-go pricing, and the guide to recipe costing compliance across the UK and EU covers the regulatory context in more detail.
If you want to run the five layers against your own menu rather than a demo one, book a demo and bring three dishes with you: your most complex, your highest volume, and the one you have never trusted the cost on.
Key takeaways
• Every recipe costing product handles ingredient cost. The differences appear at yield, sub-recipes, price movement and allergens.
• Yield and trim loss are the most commonly missed inputs and they understate cost consistently rather than randomly.
• Sub-recipes must be costed once and linked, not copied into each parent recipe.
• If a supplier price change does not re-cost recipes automatically, accuracy decays every week.
• Allergen data belongs on the ingredient record, inherited by every recipe that uses it.
• Demo with your own awkward dishes, never with the vendor's demo menu.
Frequently asked questions
What is recipe costing software? Recipe costing software calculates the true cost of each dish from ingredient prices, portion sizes, yield and sub-recipes, and keeps that cost current as supplier prices change. It differs from a spreadsheet mainly in that the costs update themselves rather than being recalculated by hand.
Can I do recipe costing in a spreadsheet instead? For a small, stable menu, yes. Spreadsheets handle layer one well. They struggle with nested sub-recipes, weekly price movement, allergen inheritance and multi-site comparison at the same time. Most operators move when maintaining the sheet costs more time than it saves.
Does recipe costing software handle allergens? It should. Allergen data and costing data describe the same ingredients, so keeping them in separate systems means maintaining the same list twice. Look for allergen flags held on the ingredient record and inherited automatically by every recipe and sub-recipe.
How long does recipe costing software take to set up? The honest answer depends almost entirely on the state of your ingredient list and supplier data going in. A clean, current item list shortens implementation considerably. Ask any vendor what their typical timeline is for a kitchen of your size, and what support you get during it.
Does recipe costing software need to connect to my EPOS? It does if you want variance. Recipe costs give you theoretical cost. Sales data from EPOS tells you what you should have used. Without that connection you can cost dishes accurately but cannot compare theoretical usage against actual usage.