Recipe Costing for Menu Modifiers: One Setup, Every Variation

Cost the base recipe once, then add each modifier as its own small cost on top. A burger has a fixed base of patty, bun, cheese and sauce, costed as one recipe. Extra patty, bacon or a larger size each carry only their own added cost. The combination the customer orders is simply the base plus whichever modifiers they chose. This keeps you from building a full recipe for every possible variation, which multiplies fast: three sizes, four sauces and three spice levels already make 36 combinations, but only nine building blocks to maintain.

A prep recipe is a small recipe in its own right, with its own ingredients and yield, that finished dishes pull in as a single line. A house sauce, a marinated patty or a batch dough are all prep recipes. Because several dishes share the same component, you cost it once and reuse it everywhere it appears. When the sauce ingredients change price, every dish that uses it recosts on its own, so you update one prep recipe instead of dozens of finished dishes. This is what keeps a modifier-heavy menu manageable.

Because the number of variations multiplies far faster than you can maintain. Three sizes, four sauces and three spice levels already give 36 combinations, and each new option multiplies the rest. Build a full recipe for every one and a single ingredient price change means editing all of them. Operators who try this often give up and drop parts of the costing to keep it manageable, which loses accuracy. Keeping one base and costing each modifier as an add-on covers every combination from a short list of building blocks instead.

Track each ingredient by its running average cost and its last purchase price, per branch, so a price change flows through automatically. Every recipe, prep recipe and modifier add-on that uses that ingredient recosts on its own the moment the price moves. You do not re-enter anything by hand. Because costs are held per branch, the same modifier can cost slightly more at one site than another and both stay correct. Set a target food cost per recipe and the system flags any variation whose actual cost climbs above it, so you catch drift on the dish that caused it.

When each recipe and its add-ons are linked to the matching POS menu item and modifiers, a sale depletes the exact ingredients used. Order a burger with bacon and the sale removes the base ingredients plus one rasher, not a generic burger. Two things follow. Your theoretical food cost reflects what was actually sold, down to the modifier, and your stock counts line up with the menu because every variation deducts what it uses. If a POS cannot pass clean modifier data, fix that first, because both costing and stock accuracy depend on it.

Yes. Each recipe can be assigned to specific branches with independent selling prices, target food cost percentages and tax rates. Ingredient costs are also held per branch, based on what that location actually pays its suppliers. So the same burger can cost more to make at one site than another, and carry a different menu price, while both stay accurate. This matters for multi-site groups where supplier prices and menus vary by location. You manage one recipe library, but the numbers reflect each branch's real costs rather than a single blended figure.

There is no single right number. You set a target per recipe, per branch, based on the margin you want on that dish. A premium item and a high-volume staple can carry different targets, so a blanket figure across the menu rarely fits. What matters is that you set a target and track against it. Supy alerts you when a variation's actual cost climbs above its target, so you act on the specific dish while you still can, rather than finding out at month end. Review the targets whenever supplier prices move materially.