Build the component once, then use its output.

Treat the component as a costed output

A sub-recipe turns a set of ingredients into a defined output that another recipe consumes. The output might be sauce, dough, cooked rice or a prepared filling. Its cost depends on the ingredients entering the batch and the usable amount leaving it.

Create the component separately when it is genuinely shared. That keeps the relationship visible when a purchase price or preparation yield changes. A parent recipe should consume the component's output, rather than storing a copied total that can become detached from the underlying ingredients.

Name the component clearly enough to distinguish its state. Raw dough, baked base and finished pizza are different outputs. A generic name that hides the stage can make a technically valid unit conversion apply to the wrong material.

Build the component from its purchase inputs

Enter each ingredient's purchase pack, price and applicable edible yield. Add the quantity required for the full component batch. Use the preparation basis that matches those quantities, and avoid applying a whole-product trim factor to an already prepared purchase.

A volume-to-mass conversion needs an ingredient-specific density. The app does not assume that every liquid or powder weighs the same as water. If the relevant density is unknown, measure the ingredient and use a compatible mass or volume basis.

Review the component's total ingredient cost before dividing by output. Include minor but real ingredients where they are measurable. Do not assume a sauce is complete merely because the most expensive ingredient has been entered.

Measure the finished output

Weigh or measure the output in the form used by parent recipes. Evaporation, material left in equipment and rejected product can change the usable batch yield. The amount written on an old recipe is not a substitute for a current measurement.

Choose a yield unit that works for routine portioning. If the kitchen portions the sauce by grams, recording finished mass avoids an unnecessary density conversion. If it portions by volume, measure finished volume consistently or establish a valid density for the finished preparation.

The app deliberately rejects incompatible sub-recipe dimensions without a conversion basis. A recipe's output grams cannot automatically be turned into milliliters just because both values are numeric. Keep the units compatible or change the recorded output basis after measuring it.

Work a shared-sauce example

All numbers here are illustrative inputs. They describe a simple cost relationship, not a standard sauce formula or expected kitchen yield.

The unit cost is $12 divided by 2,000 g, or $0.006 per gram. Multiplying by the plate's 100 g gives $0.60. The plate can then add its other ingredient lines to form a complete portion cost.

If the same batch ingredients produce only 1.8 kg, the 100 g sauce portion costs about $0.6667. The purchase cost did not change; fewer usable grams carry that cost. This is why finished yield belongs in the component record.

Add the component to a parent recipe

In the recipe book, create the sauce and set its finished batch yield. Create or select the plate recipe, add an ingredient or sub-recipe line and select the sauce. Enter the amount used by the full parent batch, not only a single serving unless the parent batch itself is a single serving.

Keep the parent's finished yield and portion size separate from the sub-recipe's yield. A parent batch can consume part of a sauce batch and produce several plates. The cost calculation follows the amount used, not the number of times the sauce recipe happens to be listed.

Do not also add the sauce's original ingredients to the parent for the same quantity. That would duplicate the charge. Additional butter or seasoning added at service can be a separate parent line if it is genuinely outside the component recipe.

Follow a price change through the dependency

Assume the sauce batch cost rises from $12 to $14 while its 2 kg yield stays unchanged. The 100 g portion rises from $0.60 to $0.70. Every parent using that same quantity should reflect the additional $0.10.

The app's price-impact workspace previews affected recipes before the ingredient change is applied. This is useful when the changed ingredient appears through several levels of preparation. Review the affected amounts and margins rather than updating copied totals manually.

The scenario uses current recipe quantities and yields. If the kitchen also changed the preparation process, update that evidence separately. A price scenario should not be mistaken for a complete explanation of a cost movement that includes several changes.

Avoid circular and missing relationships

Dependencies must run in one direction. A sauce cannot contain a plate that already contains the sauce, because the cost would refer back to itself without a defined starting point. The app rejects circular references visibly.

Likewise, a parent cannot be calculated from a missing ingredient or missing sub-recipe. Deleting a referenced component is blocked until its uses are removed. That protects the relationship from silently turning into a zero-cost line.

When importing a backup, the complete set of references is validated before replacement. A file that contains a parent but omits its child component should be corrected as a whole rather than partially imported into a misleading ledger.

Separate prep from menu analysis

A shared component affects the food cost of offered menu items, but it is not necessarily a menu item itself. In menu engineering, exclude prep-only recipes from the selected category. Otherwise they can alter the popularity threshold despite never being available for guests to order.

If a component is also sold independently, decide whether it belongs in the category being reviewed. Use actual units sold for that offered item, and keep the parent recipes' sales counts separate. The same recipe structure can support several operating uses, but the analysis must define which one it is measuring.

Use the recipe-costing guide to establish the purchase inputs and the yield-testing guide to measure output. Build and test the dependency in the browser ledger, then export a backup that preserves both parent and child recipes.

Keep an output specification with the name

A component name should point to a repeatable preparation and output state. If a sauce is reduced further for one dish, that output may need a separate recipe rather than sharing an unchanged density or yield with a looser version. Record the quantity and unit used by the parent at the stage it actually consumes. This makes the relationship understandable to another cook and prevents a common name from masking physically different components in the cost model.