Why “latest price wins” overstates your food cost

The mistake is invisible because it looks like diligence

A new invoice arrives. Chicken has gone up. You update the price on the cost sheet, every dish that uses chicken recalculates, and three of them are now over your food-cost goal. That is the workflow every costing tool sells, and most of the time it is the right thing to do.

But the sheet has quietly answered a question you did not ask. You wanted to know what your chicken costs. It told you what the last delivery cost. Those are the same number only when the last delivery is all the chicken you have.

A worked example

You buy 500 kg of chicken breast at $6.00 per kilogram, a $3,000 line on one invoice. Two weeks later you run short and top up with 10 kg at $9.00 per kilogram, a $90 line on another.

Under latest-price-wins, chicken is now $9.00 per kilogram. Every dish on the menu is instantly costed at that rate, including everything you will cook from the 490 kg of $6.00 chicken still in the walk-in. Your chicken cost has risen 50% on a price that describes 2% of what you hold.

What you actually paid is the total spent over the total bought:

($3,000 + $90) ÷ (500 kg + 10 kg) = $3,090 ÷ 510 kg = $6.06 per kg

On a dish with 180 g of chicken selling for $10, the difference is not academic:

• Before the top-up: $1.08 of chicken, a 10.8% chicken share of the sale.
• Latest price wins: $1.62, 16.2%. An alert fires. Somebody reprices the menu.
• What you paid: $1.09, 10.9%. Nothing has meaningfully changed, because it has not.

The first method reports a 50% jump. The second reports one percent. One of them will send you to renegotiate with a supplier over a delivery of 10 kg.

The rule, stated once

The current cost of an ingredient is the total spent divided by the total quantity, across every purchase in the last 90 days. Not the newest price. Not the average of the prices, which would count a 10 kg top-up as heavily as a 500 kg bulk buy. The quantity-weighted figure, which is the same thing as what the invoices add up to.

Two details make it behave.

The window is anchored on your newest purchase, not on today. A cost should move when something happens: an invoice arrives. If the window slid with the calendar, an old bulk buy would fall out of it one night and every dish would reprice at 3 a.m. with no delivery behind the change. Anchoring on the last purchase means the figure only moves when you buy something, and the number on screen can always be traced to the invoices that produced it.

One purchase in the window is just that purchase. If an ingredient is bought less often than every 90 days, the only honest answer is its most recent price, and the screen should say so rather than imply several prices were blended. In our example, if the next chicken delivery came 91 days after the bulk buy, the $6.00 purchase would leave the window and the cost would become that new delivery alone. That is correct: 500 kg bought three months ago is not what you are cooking with now.

What this does to alerts

An alert that says mozzarella is up 17.9% is describing the supplier’s headline. It is true and it is not what your food cost did.

Say you bought 100 kg at $8.20 per kilogram, and the next 100 kg arrives at $9.67. The supplier has raised the price 17.9%. But half the mozzarella you hold was bought at the old rate, so what the kitchen is paying, across the 200 kg, is $8.94 per kilogram, a rise of 9.0%.

The 9.0% figure is the one that has to appear in the alert, because it is the one that agrees with the dish cost printed beside it. An alert quoting 17.9% next to a plate cost that only moved 9% is two different questions on one screen, and the reader will not know which to trust. Both ends of every comparison have to use the same rule.

What this is not

This is not FIFO, and it does not pretend to be. First-in-first-out costing needs to know what has been consumed, which needs stock counts, which is inventory management. If you already count stock, FIFO is more precise and you should use it. Most independent restaurants do not, and a costing method that requires counts you are not doing will be abandoned within a month.

It is also not an inventory valuation method, which is what most articles on weighted average cost are about. Valuation asks what your stock on the shelf is worth for the balance sheet. This asks a narrower question: when a recipe uses 180 g of chicken, what should that 180 g cost? Weighted purchase cost answers it from the invoices you already have, without asking anyone to count anything.

Where it is genuinely wrong: if you bought 500 kg, used all of it, and then topped up at the higher price, the blend understates your current cost until the bulk buy leaves the window. That is the trade for not counting stock, and it is a smaller error than latest-price-wins makes in the opposite direction on every single top-up.

Doing this on a spreadsheet

Keep one row per purchase rather than one cell per ingredient: date, ingredient, quantity in a consistent unit, line total. The current cost is SUMIFS of the line totals divided by SUMIFS of the quantities, filtered to the last 90 days from that ingredient’s newest date. It is ten minutes of setup and it stops the sheet lying to you on the next top-up.

To get the quantity into a consistent unit, the case price calculator reads foodservice pack notation like 6/5 lb, and the recipe costing guide covers the per-portion side.

How MenuLedger does it

Every confirmed invoice line becomes a purchase record: quantity, line total, purchase date. An ingredient’s current cost is derived from those records by the rule above, recomputed whenever a new one lands, and never edited by hand. The screen shows whether the figure is weighted across several purchases or is simply the latest one, and lists the invoices behind it.

Nothing about that requires you to count stock. It requires you to confirm the invoices you already receive, which is the one piece of data every restaurant has.