Skip to content

Recipe yield and unit

A recipe has a name, an ingredient list, and a yield. The first two are obvious. The third — how much does this recipe actually make, and in what unit? — is the field most cooks fill in casually on the way to saving the form, and the field that quietly decides whether the food-cost percentage on every dish downstream is correct or off by a factor of ten. Yield and its unit are the smallest part of the recipe editor and the most load-bearing.

This page is for two readers. If you’re the owner, “Why this page exists” is for you — start there. If you’re the head chef, jump to “How to use it”.

Why this page exists

Every plate of pasta the till sells costs the kitchen some share of a pot of sauce. Eighty grams off a six-kilogram pot of sugo. Two hundred millilitres off an eight-litre batch of stock. One ball off a fifty-ball tray of pizza dough. The system has to do that division somewhere — and the place it does it is here, in the yield and unit fields of the producing recipe. The recipe says we made six kilograms of sugo and it cost €34.80 in ingredients, the dish says we used eighty grams, and the system divides one by the other to land on the per-plate cost. Get the yield wrong by a factor of ten and the per-plate cost is wrong by a factor of ten too.

The unit matters as much as the number. A sugo that says it yields 6 in kg and a sugo that says it yields 6 in pieces are two different things. The first feeds the pasta dishes at 80 g per plate; the second is uncountable downstream — what does it mean to pull “0.08 pieces” of sugo? The unit is the contract between this recipe and every dish that consumes it. Pick it carefully; change it rarely.

The rule

Yield × cost-per-recipe-unit = total recipe cost. Total recipe cost ÷ yield = cost-per-recipe-unit. The two numbers are joined at the hip — change one and the other follows. Every food-cost figure on every dish that uses this prep is built from dividing this prep’s total cost by this yield. Wrong yield, wrong unit, wrong food cost — everywhere.

What yield and unit are

Yield is the quantity the recipe produces in one full run. 6 kg of sugo. 50 balls of pizza dough. 12 portions of bolognese. 8 L of house stock. The number is the kitchen’s honest answer to how much comes out of this pot, in the unit you’d count it by.

Unit is what that yield is measured in. Five options — kg, g, L, ml, unit — picked from a dropdown. kg and g are for things weighed; L and ml for things measured by volume; unit (also called each, pieces, or portion depending on context) is for things counted whole — pizza dough balls, brioche buns, individual ramekins of crème brûlée.

Together yield and unit define one recipe-unit — the atomic quantity downstream consumers reference. A bolognese yielding 12 in kg means the dishes consuming it pull “in kg” — 80 g of bolognese converts to 0.08 kg, the system multiplies by the recipe’s cost-per-kg, and the per-plate sugo share lands in the food-cost panel. A pizza dough yielding 50 in unit means downstream consumes “per ball” — the pizza recipe pulls 1 ball and the system multiplies by the recipe’s cost-per-ball directly.

The two fields live inside the Yield & pricing card in the recipe editor — the card that also holds the optional selling price and the live cost preview. They’re labelled Yield qty and Yield unit, side by side.

Pick the unit downstream will consume in

The single thing to keep in mind when choosing the unit is how will the dishes that use this prep refer to it? A sauce is pulled by the gram or by the millilitre — pick kg or L. A pizza dough is pulled by the ball — pick unit. A brodo is pulled by the millilitre or the litre — pick L. A spice blend is pulled by the gram — pick g (or kg if the recipe makes a kilogram at a time).

The wrong way to pick is “whatever I weighed it in” — because the unit you weighed in (a 6-kg pot of sugo on a kg-scale) might not be the unit a downstream dish references (80 g per plate). The system handles the conversion as long as the units belong to the same family — kg ↔ g, L ↔ ml. It can’t bridge across families: kg can’t convert to L (mass to volume), and neither can convert to unit (no number of grams equals “one ball” without you telling the system). Cross-family is a dead end; align the unit at creation time and the system handles every conversion forever after.

How to use it

Open the recipe in the editor. Find the Yield & pricing card — it sits below the ingredients list, alongside the selling price field. The two fields are:

Yield qty. Type the number the recipe produces. A target is fine — the kitchen rarely hits it exactly, and the cooks log the actual yield when they tap Log to stock at the end of a batch.

Yield unit. Pick from the dropdown — kg, g, L, ml, unit.

Save. The producing prep item’s unit re-syncs to match — if the recipe says yield in kg, the prep item lists in kg, and the inventory list groups it in kg. Every existing recipe that consumes this prep re-checks its conversion path: lines that work continue silently; lines whose unit can no longer bridge to the new yield unit flag a warning on the recipe row, with the text “g can’t convert to unit” or similar, and fall to zero cost until you correct them.

Changing the unit on an existing recipe

You can change the unit any time. The save fires the same cascade as any other recipe save: the prep item re-syncs its unit, every downstream recipe re-checks its conversion, the cost numbers all refresh. Lines that were bridging fine in the old unit and break in the new one (a downstream recipe consuming the prep at “100 g” when you flip yield unit from kg to unit) get the warning chip; lines that were broken in the old unit and now bridge (the opposite case) clear automatically.

The one situation the editor refuses is changing the yield unit on a recipe whose output prep item was linked manually rather than auto-created — because the manually-linked item carries its own canonical unit, and the editor won’t unilaterally overwrite it. The save is blocked with a message asking you to align the two by hand.

Recording actual yield at log-to-stock

The recipe’s yield is the target. The actual yield — what really came out of the pot — is what the cook types into the Log to stock dialog when the batch is done. A bolognese targeted at 6 kg often comes out at 5.6 kg or 5.4 kg after a tighter reduction; that’s normal. The system uses the actual yield, not the target, to compute the live cost-per-kg on the prep item — so the dishes downstream cost against reality, not against the recipe writer’s optimism.

What happens behind the scenes

A recipe save with a new yield or unit recomputes two numbers on the recipe itself — totalCost (the sum of every ingredient × quantity × current cost-per-unit) and costPerUnit (totalCost ÷ yieldQty). Both are written to the recipe row and mirrored onto the producing prep item.

The cascade fires next. The system walks every recipe in the kitchen that consumes this prep as an ingredient. For each one, it converts the ingredient line’s quantity into the prep’s new unit (gram ↔ kilo, millilitre ↔ litre — anything inside the same family), multiplies by the new cost-per-recipe-unit, and updates that recipe’s total and per-unit cost. If the consuming recipe is itself a batched prep that other recipes consume, the cascade keeps going. Every menu item that points at any of these recipes picks up the fresh cost on its next read.

A bridge that can’t be built — a kg yield consumed at unit downstream, an L yield consumed at g downstream — is flagged on the affected line and the line falls to zero cost. The save through-rides the warning; the kitchen has to fix the unit one way or the other before the dish’s food cost on the dashboard makes sense again.

When a cook logs an actual yield at the end of a batch, the live cost-per-recipe-unit on the prep item is overwritten with frozenBatchCost ÷ actualYield for the new batch. Every dish that sells from that prep, from then on, costs against the live number — not the recipe target.

Worked example

Sara is writing a new sugo recipe at your venue. She knows the dish that consumes it — Pappardelle al sugo di vitello — pulls 80 g per plate, and she expects to plate the dish thirty to forty times a week. The pot she’ll make in the morning is the four-litre pot the kitchen uses for every sauce batch.

She opens Recipes → + New recipe. Ingredients: 2.2 kg veal shoulder (€11/kg = €24.20), 1 kg tinned tomatoes (€2.50 = €2.50), 600 g onion + 200 g celery + 200 g carrot (€2.10), 500 ml red wine (€2.40), 200 ml olive oil (€1.60), bay leaves and salt (negligible), 1.5 L water. Total ingredient cost: €34.80.

In the Yield & pricing card she types Yield qty: 6, Yield unit: kg. The cost panel on the right ticks live: Total €34.80 · Cost / kg €5.80. Batched: on. Shelf life: 72 hours. She saves.

A new prep item appears in the pantry — Sugo di vitello, L2, Kitchen production category, 0 kg in stock, cost €5.80/kg. She opens Pappardelle al sugo di vitello in the recipes list, adds Sugo di vitello to the ingredient list at 80 g. The cost panel updates: that line reads €0.46 (0.080 kg × €5.80) — the share of sugo on each plate of pappardelle. Combined with the pasta, the parmigiano on top, and the herbs, the dish costs €3.10 to plate against the €19 menu price — 16.3% food cost.

The next morning the kitchen makes the first batch. Wednesday, 8 AM. The cook tapes a sheet to the pot, simmers for four hours, reduces tighter than the recipe targets. At noon the kitchen scale reads 5.7 kg, not the 6 the recipe expected. The cook taps Log to stock, types 5.7, saves. In one transaction:

  • The pantry rows for veal, tomatoes, mirepoix, wine, oil drop by the recipe-target amounts, each multiplied by today’s actual prices. Frozen batch cost: €34.80.
  • The Sugo di vitello row goes from 0 to 5.7 kg of stock. Live cost-per-kg: €34.80 ÷ 5.7 = €6.11/kg — up from the recipe target €5.80/kg, because the same ingredients spread across less yield.
  • Every pasta recipe that consumes the sugo recomputes. The pappardelle line moves from €0.46 to €0.49 per plate; the dish’s total cost moves from €3.10 to €3.13; food-cost percentage ticks from 16.3% to 16.5%.

That evening the kitchen plates 38 portions; the sugo row drops to 2.66 kg of stock. Each plate carries the live €6.11/kg cost, not the recipe target — so the dashboard at the end of the night reads honestly against what really came out of the pot, not what Sara hoped would come out. Two fields on one card; every dish downstream reconciled.