Skip to content
allanninal.dev/build
Collaborate

Part 3 of 7 · Menu cost calculator series ~5 min read

Why prices need a date stamped on them

The difference between a costing system that is useful for two months and one that is useful for years is a stored date and a stored set of prices.

Key takeaways

  • Store the price of every ingredient used, not a reference to the current price.
  • That is what lets a cost change be attributed to a specific ingredient.
  • Recipes are versioned; a recipe change is a new version, not an edit.
  • Surface staleness: a costing older than a month should say so.
  • Weighted average purchase price beats the latest invoice.

Stamped, not referenced

How a dish costing is computed and stored immutablyA vertical chain of five steps entered by a box labelled Cost a dish, today. Step one records the recipe version in use now. Step two copies in each ingredient price rather than linking to it. Step three copies in each yield used. Step four computes the plate cost once. Step five stores it immutably with the date. A note says to copy the inputs in, because a costing that recomputes itself has no history at all.AWS ACCOUNTCost a dishtodayRecipe versionthe one in use nowEach ingredient pricecopied in, not linkedEach yield usedcopied in tooThe plate costcomputed onceStored immutablywith the dateCopy the inputs in. A costing that recomputes itself has no history at all.
Fig 1. How a costing is stored. Copying the inputs rather than referencing them is what makes two costings comparable months apart.
  • Compute
  • Security & identity
  • Analytics
  • Front-end & mobile

What this buys you

Two costings of the same dish, three months apart, with all their inputs stored, can be diffed. The dish went from four sixty-two to five oh eight, and eighty per cent of that is the beef price, twelve per cent is the cream, and the rest is rounding.

Without stored inputs the only available statement is that the dish costs more, which everybody already knew. The attribution is the useful part and it costs nothing except storing a few numbers.

Attributing a change

What drove one dish's cost change, broken down by ingredientA bar chart with five bars showing contribution to cost change in pence. Beef: thirty-one pence. Cream: seven pence. Potatoes: four pence. Yield change: nine pence. Recipe change: minus five pence. A note says forty-six pence of movement explained line by line, and beef is two thirds of it.010203040~31Beef~7Cream~4Potatoes~9Yield change~-5Recipe changeContribution to cost change, penceForty-six pence of movement, explained line by line. Beef is two thirds of it.
Fig 2. One dish’s cost change decomposed. The yield line is included because a yield movement is just as real as a price movement and is usually ignored.

That decomposition answers the only question worth asking when a food cost percentage moves: what changed? Without it the response is a general instruction to watch costs, which nobody can act on.

It also identifies where to spend effort. A dish whose cost is dominated by one ingredient is a dish whose profitability depends on one supplier negotiation, which is worth knowing before the negotiation.

Weighted average, not latest

Using the most recent invoice price makes costings jump around with delivery timing and makes a promotional price look like the new normal. A weighted average over the last few deliveries is more stable and is closer to what the kitchen is actually consuming.

The exception is a genuine step change — a new contract, a supplier switch — where the average lags reality for several weeks. Flagging a price that has moved more than a threshold from the average, so somebody can decide, handles that without needing cleverness.

Versioned recipes

Why a recipe change is a new version

  • The portion went from 180g to 200g. That is a different dish, costed differently.
  • Editing the recipe in place makes every historical costing wrong and unexplainable.
  • A new version keeps both, and the costing history shows exactly when the change happened.
  • Sales data joins to the version, so a margin change can be traced to a recipe change rather than blamed on prices.
  • The old version stays because the menu may go back to it seasonally.
  • One field, one discipline, and it makes the whole history usable.

Surfacing staleness

A costing more than a month old should say so wherever it appears, because a menu priced from a stale costing is the failure mode this system exists to prevent, and it recurs quietly.

Recosting is cheap once the prices are flowing in, so the practical answer is to recost everything weekly and keep every version. Storage is trivial and the history is the asset.

Next: the variable that moves more than price does.

All posts