Restaurant management in Excel: a food-cost and inventory template that works, where it breaks, and what comes next
Most restaurants run part of the business in a spreadsheet, and it is usually the part that matters most to the margin: what the food actually costs. The till knows what was sold. The supplier invoices know what came in. Somewhere in between, a restaurant inventory spreadsheet tries to work out where it all went.
For a single site with a stable menu and one person doing the numbers, that spreadsheet can be genuinely good — better than the inventory module of a lot of software. Then it stops working, and it stops in the same five places every time.
This is the honest version: a restaurant food cost spreadsheet structure worth copying, the exact point where each part of it fails, and what your options are when it does. No pretence that you need software on day one, and no pretence that restaurant management in Excel lasts forever.
The restaurant spreadsheet template worth copying
You can download plenty of free restaurant management Excel templates, and most of them share one design flaw: a single sheet of ingredients with a Quantity column that somebody overwrites after every count. That one decision makes it impossible to ever explain a variance, so start with five small sheets instead. They take about half an hour to set up in Excel or Google Sheets.
Sheet 1 — Ingredients. One row per thing you buy. No live quantity here, ever.
| Code | Ingredient | Count unit | Cost per unit | Par level |
|---|---|---|---|---|
| BEEF-PAT | Beef patty 150g | each | 1.35 | 80 |
| BUN-BRI | Brioche bun | each | 0.42 | 90 |
| CHED-SL | Cheddar, sliced | slice | 0.18 | 150 |
| FRY-OIL | Fryer oil | litre | 2.10 | 40 |
Count in the unit you actually count in. If you buy cheese by the case and count it by the slice, the cost per unit is per slice.
Sheet 2 — Recipes. One row per ingredient per dish. This is your plate cost.
| Dish | Ingredient | Qty per plate |
|---|---|---|
| Classic burger | BEEF-PAT | 1 |
| Classic burger | BUN-BRI | 1 |
| Classic burger | CHED-SL | 2 |
| Fries | FRY-OIL | 0.02 |
Plate cost for a dish is a SUMPRODUCT of quantity and ingredient cost:
=SUMPRODUCT((Recipes[Dish]=[@Dish]) * Recipes[Qty] * XLOOKUP(Recipes[Ingredient], Ingredients[Code], Ingredients[Cost per unit]))
Put that beside each menu item with its selling price and you have food cost per dish — the number most menus are priced without.
Sheet 3 — Sales. How many of each dish you sold, per day, straight from the till's export. Do not type these in from memory; export them.
| Date | Dish | Qty sold |
|---|---|---|
| 2026-09-15 | Classic burger | 64 |
| 2026-09-15 | Fries | 71 |
Sheet 4 — Movements. Every event that changes stock, one row each. You never edit a quantity anywhere; you add a row here.
| Date | Ingredient | Type | Qty | Reason | Who |
|---|---|---|---|---|---|
| 2026-09-15 | BEEF-PAT | delivery | +120 | Invoice 5521 | AR |
| 2026-09-15 | BEEF-PAT | waste | −3 | Dropped on pass | Chef |
| 2026-09-16 | BEEF-PAT | staff meal | −2 | Family meal | Chef |
| 2026-09-21 | BEEF-PAT | count | 54 | Weekly count | JM |
Type is delivery, waste, staff meal, transfer or count. Counts record what was on the
shelf, not a change.
Sheet 5 — Variance. Derived, never typed. For each ingredient over a period:
Theoretical usage = SUM over dishes of (Qty sold × Qty per plate)
Actual usage = Opening count + Deliveries − Closing count
Variance = Actual usage − Theoretical usage − Recorded waste − Staff meals
That last line is the one that pays for the whole spreadsheet. Theoretical usage is what the recipes say the sales should have consumed. Actual usage is what physically left the shelf. Whatever is left after recorded waste and staff meals is over-portioning, unrecorded waste, or stock walking out of the back door — and now you can see it per ingredient, per week.
This is not a spreadsheet trick. It is exactly how serious restaurant software handles food cost. When we had four AI models build the same restaurant system, two of the strongest builds implemented this same theoretical-versus-counted model, and one tracked stock perpetually, deducting ingredients at the moment of every sale. Both are legitimate. The spreadsheet can only do the first.
Where it breaks
A spreadsheet built that way will carry a single restaurant a long way. It still ends, and it ends predictably.
1. The sales never quite match the till
The whole model depends on Sheet 3 being right, and Sheet 3 is a copy. Someone has to export sales from the till every day and paste them in. Miss a day and the week's variance is nonsense. Rename a dish on the till but not in the spreadsheet and its sales silently drop out of the calculation, so the ingredients look stolen.
The deeper problem is modifiers. The guest who asked for extra cheese, no bun and a side swap consumed a different plate from the one in your recipe sheet. Most till exports give you dish counts, not modifier-level consumption, so every modifier is a small, invisible error in theoretical usage. On a busy menu the errors add up to a variance you cannot explain.
2. Changing a recipe rewrites history
You change the burger to two slices of cheese instead of one. You update the recipe sheet. Every past week's theoretical usage now recalculates using two slices, and last month's variance report quietly changes. The same thing happens when an ingredient's price goes up: every historical plate cost moves with it.
A spreadsheet has no concept of "the recipe as it was on the 15th". Real systems version recipes and price changes so a closed week stays closed. In a spreadsheet you either copy the file every week, or you accept that your history is whatever the current numbers make it.
3. The count is a clipboard
The weekly stocktake is someone walking the walk-in with a printout, writing numbers in the margin and typing them in later. Partial counts, a case counted as twelve eaches in one week and one case the next, the fryer oil nobody measured — all of it lands in Sheet 4 as if it were precise.
There is no count session, no review of the variance before it is committed, and no lock, so a count can be "corrected" three days later when the numbers look bad. At that point the variance report is measuring your willingness to edit it.
4. Nobody records waste during service
Theoretical-versus-actual only works if waste and staff meals are logged, and nobody opens a spreadsheet on a kitchen tablet in the middle of Friday service to record a dropped burger. The waste happens; the row doesn't. So it all lands in the unexplained variance, where it looks exactly like theft, and the one number the spreadsheet exists to produce stops being trustworthy.
5. Two people, or two sites
The moment the head chef and the manager both edit the file, rows go missing. Shared spreadsheets do not lock records the way a database does, and two people adding deliveries at the same time can overwrite each other with no error. A second site is worse: duplicate the file and lose the group view, or add a location column and lose any safe way for each kitchen to enter its own counts. Transfers of stock between sites become two manual rows that never quite reconcile.
What a real one has that a spreadsheet doesn't
We keep a hand-counted inventory of what restaurant POS products actually ship, built from 29 products. Here is how often the core capabilities appear:
| Capability | Products (of 29) |
|---|---|
| Menu categories and items | 29 |
| POS order entry | 29 |
| Service modes — counter, dine-in, takeaway, delivery, QR | 29 |
| Payments | 28 |
| Receipts and kitchen order tickets | 27 |
| Reports derived from order records | 25 |
| Order statuses — new, fired, ready, served, closed, refunded | 23 |
| Kitchen display system | 15 |
| Modifier groups, documented publicly | 10 |
Read it against the five failures and one thing stands out. Every product in the census starts from the order. The sale is recorded once, at the till, with its modifiers, and reports are derived from those order records rather than typed in. That removes failure 1 entirely. A spreadsheet can never do it, because it starts from the stock and works backwards to the sales.
The modifier row is worth a second look. Only 10 of 29 products document modifier groups publicly, yet every restaurant with "no onions" on a ticket needs them. Modifiers are the capability most likely to be missing from a quick build, and they are exactly what your spreadsheet's theoretical usage gets wrong.
Your three options, honestly
Keep the restaurant spreadsheet
Correct if you have one site, a menu that changes a few times a year, one person doing the counts, and a till that exports sales cleanly. Use the five-sheet structure above and run the variance weekly. That is more food-cost discipline than many restaurants with software actually have.
Stop when a second person needs to edit it, when you open a second site, or when you notice you are adjusting counts to make the variance look reasonable.
Buy software
Correct for most restaurants. A modern POS with inventory and recipe costing records the sale once, applies modifiers, versions your recipes and handles counts as sessions. The free restaurant POS software roundup covers what the no-cost tiers actually include and where they stop.
The real cost is fit. You adopt their model of a recipe, a count, a transfer and a service mode. If your operation matches, that is a bargain. If you run something unusual — a commissary kitchen feeding three sites, batch prep with yields, a bar with its own pour-cost rules — you will build spreadsheets around the software, and you are back where you started.
Build it
A year ago this was unrealistic without a development budget. Now a coding agent can produce a working restaurant system in days — but only the right one if you tell it exactly what to build. Left to guess, an agent builds a menu, a till and a pretty dashboard, and skips the parts your spreadsheet was actually doing: recipes linked to sales, a movement log, counts as sessions.
If you build it, build these first
- Orders as the source of truth. Every sale recorded once, at the till, with its modifiers. Everything downstream derives from that record.
- Recipes linked to menu items and modifiers, with versions. "Extra cheese" should consume cheese. A recipe change applies from a date forward, never backwards.
- A stock movement log. Deliveries, waste, staff meals and transfers each write a row. On-hand is calculated from movements, never typed.
- Counts as sessions. Open, count, review the variance against theoretical usage, commit, lock. The lock is what makes the number mean something.
- A daily close. A Z-report that locks the trading day, so yesterday's sales cannot quietly change under this week's variance.
Everything else — reservations, loyalty, delivery apps, multi-site dashboards — is real scope, and optional for a first version.
For the full picture of what a restaurant system involves, see what a restaurant management system includes, and why it isn't one product. To see what different AI models produce from the same restaurant spec, including which of them got recipes and stock right, read the restaurant build-off write-up — all four builds are live and you can sign in.
And if you are building with a coding agent, the Restaurant Management planner is the spec we hand ours: the order lifecycle, the modifier rules and the scope boundaries, written so the agent cannot quietly skip them.