Ingredient Costing Method: Live Purchase Price vs Fixed Cost, and Which Recipe Items Belong on Each

Purchase Price vs Fixed Cost: What You Are Actually Choosing

An ingredient costing method decides how each item's cost is set inside your recipes. There are two options, chosen per item: the Purchase Order method prices the ingredient from your actual purchase orders on a rolling weighted-average, so the cost moves as suppliers reprice; the Fixed method holds a stable cost per unit that you set by hand and it stays put until you change it.

The important word is per item. This is not one global switch for the whole menu. A single recipe can pull a live purchase price for its fresh fish and a fixed cost for the packaging it ships in, at the same time. So the real question is never "which method is better" in the abstract. It is "which method belongs on this ingredient", answered one line at a time across your item list.

Getting that answer right matters because the costing method is what connects a supplier invoice to the gross profit figure you make pricing decisions on. Put a volatile ingredient on a fixed cost and its recipe keeps reporting yesterday's margin while today's invoice quietly climbs. Put a stable, contracted item on a live cost and you invite noise into a number that was not actually moving. Neither error announces itself. Both show up later on the profit and loss, after the decisions have been made. If your recipes still live in a workbook, the same tension plays out in a harder form, which we cover in why static recipe costs go wrong when supplier prices move.

Why a Live Cost Lags a Single Invoice

The most common source of confusion with live costing is that a recipe does not instantly show the price on your latest invoice. That is by design. The Purchase Order method costs an ingredient on a rolling weighted-average of what you have actually bought, not on the newest delivery alone, so the cost catches up gradually rather than jumping with every order.

A worked example makes it concrete. Say you are holding 20 kg of an ingredient already valued at an average of $8.00 per kg, and a new delivery arrives: 10 kg at $5.00 per kg. The new rolling cost is not $5.00. It is the combined value of both, ($8.00 across 20 kg plus $5.00 across 10 kg), divided by the 30 kg you now hold, which works out to $7.00 per kg. One cheap delivery moved the cost from $8.00 toward $5.00, but only part of the way, because you are still carrying older, dearer stock.

This is exactly why a dish can look artificially cheap for a while after a single low-priced delivery, then drift back up as that stock is used and the average normalises. It is also why "the recipe cost looks wrong" is usually not a bug. It is the weighted-average doing its job. Once you can see this happening in the numbers, the live cost stops being mysterious and becomes a running read on what your stock genuinely cost you, which is the number you want when supplier prices are the thing moving.

What Stale Costs on Volatile Items Do to Gross Profit

Here is where the wrong method gets expensive. Many operators update recipe costs by hand, quarterly at best, which lets up to three months of supplier price drift build up before anyone reprices. On a stable item that is harmless. On a volatile one, fresh produce or proteins that reprice week to week, three-month-old costs can misstate a recipe's gross profit by 5% to 10%. On thin virtual-brand or delivery-only margins, an error that size is enough to turn a brand that reads as profitable into one that is quietly losing money on every order.

The stakes scale with volume. Consider a small multi-site group spending around $45,000 a month with suppliers. A 5% cut in cost of goods, the kind that comes from simply pricing against current costs instead of stale ones, is worth roughly $27,000 a year. That is not a rounding item. And the exposure is largest exactly where visibility is weakest: it is common for the single highest-volume item on a menu, something selling 2,000 units a day, to have no properly calculated build cost at all, so its margin was never actually known. Costs that only move when someone remembers to move them are the same pattern behind supplier prices drifting up before anyone notices.

This is the core argument for putting volatile items on the live Purchase Order method: it removes the human step. The cost updates because you received stock, not because someone found time to reprice. If your recipe costs should update automatically when supplier prices change, this is the method that does it.

Before You Blame the Method: Check the Base Cost Is Right

There is a trap worth naming before you switch anything. When a recipe cost looks obviously wrong, the instinct is to reach for a Fixed cost to "stabilise" the number. Often the method was never the problem. The base item was set up wrong, and a fixed cost would simply freeze the error in place.

Two setup mistakes account for most of it. The first is a unit mismatch: a case of 12 packets bought at $24.00 gets logged as if $24.00 were the cost of one packet, instead of the correct $2.00 per packet. That single line overstates the ingredient 12-fold, and every recipe using it inherits the inflation. The second is a structural mistake: a prepped, semi-finished component gets set up as a raw material instead of as a sub-recipe, so its real build cost, the ingredients plus the prep, never flows into the finished dish.

The fix is sequence, not method. Audit your sub-recipes first, confirm each base item's pack size and cost are right, and only then look at the finished recipes built on top of them. Clean item setup is also what keeps costing, gross profit reporting and stock counts agreeing with each other, which is the job of well-maintained recipes and prep recipes in your inventory. Switch a badly set-up item to Fixed and you have not stabilised anything. You have just made the wrong number harder to notice.

Which Items Should Track Live Price, and Which Should Hold Fixed

With the base costs trustworthy, the per-item decision comes down to two questions: how much does this ingredient's price actually move, and do you have a real agreement holding it steady. Plot an item on those two axes and the method chooses itself.

Track live (Purchase Order) for anything volatile and bought at spot or market prices: fresh produce, seafood, proteins, and any ingredient whose invoice changes noticeably from order to order. These are the items where a live cost earns its keep, because the whole point is to feel the market as it moves rather than three months late. Hold Fixed for items where the price genuinely is not moving: staples on a signed fixed-price contract, packaging, and dry goods you have locked for the season. For these, a live cost only adds noise to a number that was already stable, and a clean fixed cost is the more honest read.

The edge cases resolve with the same test. A normally stable item that comes off contract moves back to live until you sign the next agreement. A volatile item you have just locked a short-term price on can hold Fixed for the length of that lock, then revert. The rule is not the ingredient category, it is the answer to "is a real agreement holding this price still right now". Looking further out, scheduled future supplier prices, the ability to see a recipe's margin impact before an agreed price change takes effect, is on the roadmap rather than shipped today, and will make the Fixed-versus-live call easier to plan around when it lands.

So the rule is short. Choose the live Purchase Order method when the price moves and nothing is holding it still, so your recipe cost tracks the market on its own. Choose Fixed when a genuine agreement is holding the price steady, so you are not importing noise into a number that is not really changing. Everything else is an edge case that the same question settles.

To check where you stand, run a five-line audit. Pull your five highest-spend ingredients and, for each, ask whether its recipe cost has moved in the last three months. If a volatile item has not moved, it is almost certainly sitting on a stale cost that is overstating your margin, and it belongs on live pricing. If a genuinely fixed, contracted item is jumping around, check its base setup before anything else. That five-line audit will usually find more margin than a menu-wide reprice, and it tells you exactly which method each item should have been on all along.