Why Your Recipe Costs Are Wrong: The Unit Conversion Errors Nobody Catches
Most wrong recipe costs are not wrong because someone cannot do arithmetic. They are wrong because a number went into a spreadsheet in kilograms and came out in grams, or in millilitres when it should have been grams, and nothing about the result looked odd enough to question. This is a diagnostic guide: the five unit errors that account for almost all of it, what each looks like from the outside, and a five-minute audit you can run on your own costings today.
Why a wrong cost still looks plausible
The reason unit errors survive is that food costs span an enormous range and our sense of what is "about right" is loose. A slice of cake could plausibly cost 30p or 90p to make. A tray of brownies could plausibly cost £4 or £11. When the sheet says £6.20 you nod, because £6.20 sits inside the range of things that seem sensible.
A factor-of-a-thousand error usually escapes that check in one direction and gets caught in the other. If the mistake makes a cake cost £480, somebody notices within the hour. If it makes the same cake cost 48p, nobody notices at all — the number looks like a pleasant surprise, the margin looks excellent, and you price accordingly. The dangerous errors are always the ones that make things look cheap.
Two other properties make these bugs persistent. They are silent: nothing errors, nothing turns red, the sheet just computes. And they are sticky: once a wrong unit cost is saved against an ingredient, every recipe using that ingredient inherits it, and the error compounds through sub-recipes rather than cancelling out.
The five classic unit errors
1. Buying in kilograms and using in grams
This is the big one, and it is a 1,000× error. A 16 kg sack of strong flour at £14.40 costs £0.90 per kilogram, or £0.0009 per gram. Enter £0.90 into a field that is then multiplied by grams, and 450 g of flour appears to cost £405. Enter it the other way and the flour is effectively free.
The reason it slips through is that the mistake is not in the sum, it is in the label. The spreadsheet has no idea what a gram is. It multiplies whatever you gave it by whatever you typed, and returns a number in the same confident font as a correct one.
It bites hardest on your bulk ingredients — flour, sugar, butter, oil — which are precisely the ingredients that dominate the cost of most baked goods. Get the 5 g of salt wrong and it barely matters. Get the 2 kg of butter wrong and the entire product costing is fiction.
2. Millilitres and grams for liquids
Millilitres and grams are the same number only for water. For everything else, density matters, and food ingredients vary more than people expect.
Note that honey and oil err in opposite directions, so the mistakes do not cancel out across a recipe — they just make each ingredient wrong by a different amount, which is harder to spot than a single consistent bias. If you buy honey by weight and use it by volume, either record the density or standardise on one unit and stop switching.
3. "Each" items with no weight
Eggs, lemons, vanilla pods, sourdough starters, punnets, boxes. An ingredient recorded as "each" with no weight attached cannot be scaled, cannot be reconciled against stock, and cannot be compared with a weighed alternative.
The classic failure: the recipe says "6 eggs", the ingredient record holds "£3.80 per box of 15". Six is then either charged as six boxes (£22.80) or, if someone divided once and forgot, as something meaningless. The fix is to give each item a weight — a medium egg is about 50 g of edible content, a lemon around 85 g whole with roughly 40 ml of juice — and to record both the pack price and the count in the pack, so unit cost per item is derived rather than typed.
4. Pack size versus usable yield
You pay for the pack. The recipe consumes the usable part. Those are different numbers and only one of them belongs in a costing.
A 2 kg whole butternut squash that yields 1.3 kg of prepared flesh has an effective cost per usable kilogram of about 1.54 times the purchase price — a 54 per cent uplift that will not appear anywhere unless you put it there. The same applies to whole chickens, unpeeled roots, tinned goods costed on drained weight, and anything that arrives with skin, stone, shell or brine.
The symptom is subtle: your costings look fine, your gross margin on paper looks fine, and your actual food spend at the end of the month is stubbornly higher than the sum of your costed production. That gap is yield.
5. Waste and trim not accounted for
Related to yield, but distinct: yield is what the ingredient loses on the way to being usable, waste is what you lose after that. Batter left in the bowl, cake trimmed level, a tray that came out wrong, portions that overshot.
Measure it once per category rather than guessing. Weigh what goes in and what comes out on a normal batch, express the difference as a percentage, and attach it to the ingredient. A blanket "add 10 per cent for waste" at the bottom of a costing feels prudent but tells you nothing about which product is actually the wasteful one — and it is usually one or two, not all of them.
Check a recipe with the free cost calculator →
The classic errors at a glance
A five-minute audit you can run today
You do not need to re-cost everything. You need to find out whether you have this class of problem at all, and the fastest way is to test the ingredients where it does the most damage.
- Pick your three biggest-volume ingredients. Flour, sugar, butter, oil — whatever you buy most of. These dominate your costs and therefore your errors.
- Work out cost per gram by hand. Pack price divided by pack size in grams. Write it down with the zeros: £14.40 ÷ 16,000 g = £0.0009/g. Seeing the decimal places makes a 1,000× error obvious.
- Cost one recipe manually. Take your best-selling product, multiply each ingredient's grams by its cost per gram, and total it. Ten minutes at most.
- Compare with what your system says. A difference under about five per cent is rounding. A difference of thirty per cent is a yield or density problem. A difference of a factor of ten, a hundred or a thousand is a unit error, and you now know exactly which ingredient it is on.
- Double the batch and check the per-unit cost. Cost per unit must not move when you scale. If it does, you have an each-item or a fixed quantity that is not scaling with the rest.
- Check one stock figure against a physical count. Stock is the best early warning you have. A number that never falls means usage is being deducted in the wrong unit — grams taken off a kilogram balance. A number that empties after one batch means the reverse.
- Reconcile a month. Add up what you costed for everything you produced last month and compare with what you actually spent with suppliers. The gap is yield and waste, and it is the number that tells you whether your food cost percentage is real.
The software angle, honestly
None of the above is difficult arithmetic. What makes it a persistent class of bug — in spreadsheets and in software alike — is where the conversion happens.
In a spreadsheet, conversion is re-implemented every time you need it: a division by 1,000 typed into this formula, a multiplication by 0.92 typed into that one, an assumption baked into a column heading three tabs away. Each copy is an opportunity to do it slightly differently, and there is no mechanism that forces the copies to agree. When one of them drifts, nothing tells you.
Software has exactly the same failure mode if it is built carelessly. If the costing screen converts kilograms to grams in one place, the stock module does it in another, the shopping list in a third and the label generator in a fourth, then sooner or later one of those four disagrees with the others — and the ingredient is valued differently depending on which screen you happen to be looking at. That is worse than a spreadsheet, because it looks authoritative.
This is why unit conversion should live in exactly one place in a system. FoodCore centralised its unit conversion for precisely this reason: recipe costing, stock, shopping lists, production runs and labels all resolve grams, kilograms, millilitres and litres through the same shared code, so a gram-versus-kilogram mismatch cannot silently distort a cost or a stock level in one part of the product while another part looks fine.
Two honest caveats. First, centralising conversion does not make your input data correct — a mistyped pack price is still a mistyped pack price, and no amount of good engineering will catch it. Second, it does not remove the need to record yield and waste; those are business facts you have to measure, not conversions a system can infer. What it does remove is the specific category of error where the same ingredient means two different things in two different screens.
See how FoodCore handles recipes and units →
Habits that keep costings honest
- One base unit per ingredient. Grams for solids, millilitres for liquids. Convert at purchase, never inside a recipe.
- Record pack size and pack price separately. Never a pre-divided unit cost — let the division be done by something that cannot forget a zero.
- Give every "each" item a weight. Even an approximate one is better than none.
- Write the decimals out. £0.0009/g is harder to get wrong than "about a tenth of a penny".
- Re-cost when prices move, not annually. A costing built on last year's butter price is wrong for a different reason, but just as wrong.
- Sanity-check against the shelf. Once a month, count one ingredient. It takes two minutes and it is the only check that cannot be fooled by a formula.
Recipe costing errors: frequently asked questions
Why is my recipe cost so much lower than it should be?
The most likely cause is a factor-of-1000 unit error: you have entered a price per kilogram but recorded usage in grams, so a price meant for 1,000 g is being applied to every single gram, or the reverse. A 2.5 kg bag of flour at £2.50 is £0.001 per gram, not £2.50 per gram. Get that the wrong way round and a cake either costs pennies when it should cost pounds, or costs hundreds of pounds when it should cost a few. The version that costs pennies is the dangerous one, because you will happily keep selling at a price that loses money. Check the ingredient with the largest quantity in the recipe first — that is where the error does most damage.
How do I convert a kilogram price to a cost per gram?
Divide the pack price by the pack size in grams. A 16 kg sack of strong white flour at £14.40 is 16,000 g, so £14.40 ÷ 16,000 = £0.0009 per gram. Multiply by the grams used: 450 g of flour costs £0.405. The arithmetic is trivial; the errors come from doing it inconsistently across dozens of ingredients, or from typing the pack size in kilograms into a field that expects grams. Record every ingredient in one base unit — grams for solids, millilitres for liquids — and convert once at the point of purchase rather than repeatedly inside recipes.
Can I cost liquids in millilitres if I buy them by weight?
Only if you apply the density, because millilitres and grams are only interchangeable for water. Vegetable oil is roughly 0.92 g per ml, so a litre weighs about 920 g, not 1,000 g — treat it as 1 kg and you understate its cost by around 8 per cent. Honey and golden syrup run about 1.4 g per ml, so a litre weighs around 1.4 kg and treating ml as g understates the cost by roughly 30 per cent. Milk is close to 1.03 g per ml. Either buy and use in the same unit, or record the density once per ingredient so the conversion is applied consistently.
How do I cost an ingredient that is sold each rather than by weight?
Give it a weight. An each item with no weight cannot be scaled, cannot be checked against stock and cannot be compared with a weighed alternative. A medium egg is about 50 g of edible content, a lemon about 85 g whole with roughly 40 ml of juice, a vanilla pod a couple of grams. Record both the each price and the typical weight, then decide which unit the recipe uses and stick to it. The classic failure is a recipe that says 6 eggs while the ingredient record holds a price per box of 15 — six is then charged as six boxes, or as six pence, depending on which way the entry went in.
Should I cost the pack size or the usable yield?
You pay for the pack, so the pack is what leaves your bank account — but the recipe should carry the cost of what it actually consumes, including the part of the pack that never becomes product. A 2 kg whole butternut squash that yields 1.3 kg of prepared flesh has an effective cost per usable kilogram of roughly 1.54 times the purchase price. Cost the recipe on the usable yield and you get a number you can price against. Ignore yield and every trimmed, peeled, boned or drained ingredient in your range is understated, usually by 15 to 40 per cent.
How much waste should I build into a recipe cost?
Measure it rather than guessing, at least once per ingredient category. Weigh what goes in and what comes out for a normal batch, and record the difference as a percentage. Typical figures worth checking against your own: root vegetables 15 to 30 per cent peel and trim, whole chickens around 30 per cent bone, leafy greens 20 per cent or more, and batter or dough scrapings a few per cent of yield. Add the measured allowance to the ingredient rather than adding a vague blanket percentage at the end of the costing, because a blanket figure hides which product is actually the wasteful one.
Does FoodCore handle unit conversion automatically?
Yes, and deliberately in one place. Unit conversion in FoodCore is centralised in a single shared module rather than re-implemented in each feature that happens to need it, so recipe costing, stock, shopping lists, production runs and labels all resolve grams, kilograms, millilitres and litres through exactly the same code. The reason is the class of bug described in this article: when conversion logic is copied into several places, one copy eventually drifts from the others and a gram-versus-kilogram mismatch silently distorts a cost or a stock level. Centralising it does not make your source data correct — a wrong pack price is still wrong — but it removes the category of error where the same ingredient is valued differently depending on which screen you are looking at.
Re-cost your range properly — 7-day free trial →
Further resources
FoodCore is kitchen management software built for small UK food businesses. We handle recipe costing, Natasha's Law labels, allergen matrices and order tracking.
Start free trial →