See your food cost across every location
See food cost across every location: a per-store P&L rebuilds cost of goods from your ledger and a multi-store table ranks each store on food cost and waste.
Running more than one kitchen means your food cost is not one number, it is a spread. One store holds the line while another quietly slips, and the operator who cannot see the spread cannot fix it. This page explains how Misenlogic shows food cost across every location, where each figure comes from, and why the money stays with the people who should see it.
How do I see food cost across every location?
Two views, built from the same record. A per-store profit and loss statement reconstructs cost of goods from your ledger for each location, and a multi-store view ranks your locations on food cost, revenue, variance, and waste for a period, so you can standardize the ones that lead. Because the cost of every recipe stays current, each location's margin reflects today's prices, not last quarter's. And role-based financial visibility is enforced in the database, so a tablet on the line never exposes the P&L.
You are not stitching a portfolio picture together from exports. The same ledger that records a count at open, a batch at midday, and a receipt at the dock is the ledger the food cost is read from at the close, at every store, on the same basis.
What is a per-store P&L built from?
Misenlogic computes a real income statement for a period from your ledger, consolidated across the portfolio or broken out per store, with every figure resolved to its reconciling lines:
- Cost of goods sold is reconstructed as beginning inventory plus purchases minus ending inventory, rebuilt as of the period boundary, not typed in.
- Revenue comes from your invoiced sales for the period.
- Labor comes from the entries you record, so it is only as complete as what your team logs.
- Shrink is rebuilt as its own line from the loss ledger, so waste is accounted for, not buried in cost of goods.
This is a statement you can trace, not a certified or audited financial. It reconstructs the numbers from the records your operation already keeps, and it is hidden from the roles that should not see money.
How does the multi-store view rank locations?
A league table ranks your locations side by side on food cost percent, revenue, variance, and waste saved for a period, groups them into peer cohorts so you compare like with like, and lets every cell click through to the record behind the number. It reports honestly how many stores have filed data for the period rather than implying a full portfolio when only part of it has closed. If you run a single location, you see a discovery state, not a league.
| Location | Food cost % | Revenue | Variance | Waste saved |
|---|---|---|---|---|
| Store A, commissary | 28.4% | $214,900 | -0.6 pt | $3,120 |
| Store B, retail | 31.2% | $186,400 | +1.1 pt | $1,740 |
| Store C, retail | 33.8% | $172,050 | +2.4 pt | $980 |
Example data. Figures reflect each location's computed period statement, not a live feed.
The table is a ranking of already-computed period figures, so it settles as each store's period does. Reading it top to bottom tells you which locations are running the tightest food cost and which are drifting, and clicking a cell walks you straight to the ledger, counts, and recipes underneath it. You standardize the leader's practice, you do not guess at it.
Why does each location's food cost stay current?
Most tools cost a recipe correctly on the day the prices are entered, then let that number go stale across the portfolio. Misenlogic maintains it. Change a vendor's price once, and it flows to every recipe that uses that ingredient, directly or through a sub-recipe, across every location, recomputed on read and fresh at view time, within about a minute. Nothing to re-run, nothing to re-key.
Competitors store a number; we compute it fresh. That is why a food cost read at one store and a food cost read at the next are on the same current prices, and why a location's margin reflects the invoice that landed this morning rather than the one from March. Each recipe's margin is measured against the target you set from its current cost, so a store slipping under target does not hide behind a stale figure. For more on the loop that keeps every plate cost current, see recipe costing.
Can I compare cost of goods the same way at every store?
Yes, because the inputs to every store's cost of goods are built on one discipline. On-hand and stock value are computed from an append-only ledger rather than stored as editable numbers, counts post their variance through one idempotent engine so a re-sent posting cannot double your on-hand, and stock moved between stores travels as a two-leg ship and receive that belongs to neither location until the destination confirms it. The numbers feeding each per-store P&L are assembled the same way, so a comparison across locations is a real comparison, not two spreadsheets kept in step by hand.
Who can see the food cost, and who cannot?
Cost and margin are hidden from the roles that should not see them, and the block lives in the database itself, not just on the screen, so it holds even against direct access to the data. A line cook or a floor manager on a tablet sees the make screen and the counts, never the P&L or the location league. The controller closing the month and the operator ranking the portfolio see the money; the line does not. It is the same record for both, gated at the role level, so you open the portfolio view to your leadership without opening your food cost to every device in every store.
Frequently asked questions
Ready to see your food cost across every location on one record? Contact us for pricing, and we will move your data over as part of onboarding.