Restaurant Inventory Management: Beyond the Weekly Count
Most restaurants count stock once a week. That means the number on the sheet is wrong for six out of seven days.
What restaurant inventory management actually covers
It's three jobs that get treated as one. Knowing what you have right now. Knowing what you should have, given what you sold. And explaining the gap between those two numbers. Most kitchens do the first job on a clipboard, skip the second entirely, and discover the third at the end of the month when it's too late to do anything about it.
The gap has a name — variance — and it's where the money is. A restaurant running 4% variance on a €30,000 monthly food spend is losing €1,200 a month to portioning, waste, and shrinkage it can't see.
Restaurant inventory categories
Before you count anything, decide what you're counting. Most operations end up with some version of these:
Food — proteins. The highest-value, highest-variance category. Usually 30–40% of food spend in a full-service kitchen and the first place a count pays for itself.
Food — produce. Short shelf life, high waste, hard to portion consistently. Count it most often.
Food — dry goods and dairy. Slower moving, easier to count, easier to over-order.
Beverage — spirits, wine, beer. Often tracked separately because the pour is the variance. Wine is usually counted by bottle, spirits by weight or by tenths.
Non-food. Packaging, napkins, cleaning supplies. Rarely worth counting weekly, frequently worth counting before you run out mid-service.
The category doesn't change the maths. It changes the frequency — and how much a mistake costs you.
How to count inventory in a restaurant
The count itself is not complicated. What makes counts unreliable is doing them inconsistently, so the discipline matters more than the technique.
Count when nothing is moving. After close or before open. A count taken during prep is a count of a moving target.
Count in the same order every time, walking the room in a fixed route — walk-in, then freezer, then dry store, then bar. A count sheet ordered by storage location rather than alphabetically will roughly halve the time it takes.
Use one unit per ingredient and never switch. If flour is counted in kilograms, it is always kilograms. Half the variance in a badly run count is a unit mix-up, not a real loss.
Two people, one counting and one recording, if the value justifies it. Solo counting is where numbers get rounded to something plausible.
Enter the actual number, not the expected one. This sounds obvious and is the single most common failure. A count that gets nudged toward what the system says isn't a count, it's a confirmation — and it destroys the only number that was going to tell you something.
Then reconcile. The count either matches what the system expected or it doesn't, and the difference posts as an adjustment against that ingredient. In Gueridon an entered count that matches posts nothing at all, and only the differences are written to the ledger — so the history stays a record of what actually changed rather than a log of every time somebody looked.
How often should a restaurant count inventory?
Weekly for high-value and fast-moving items — proteins, produce, spirits. Monthly for everything else. Daily counts of a short list of critical items are worth it in high-volume kitchens, but a full daily count is a good way to make staff resent the process and start guessing.
The honest answer is that counting frequency is a workaround for not knowing what happened between counts. If usage is being deducted automatically as dishes sell, the count stops being a measurement and becomes a verification — and you can do it less often precisely because you trust it more.
The formulas worth knowing
Actual usage = opening stock + purchases − closing stock. What genuinely left the shelf.
Theoretical usage = what your recipes say the period's sales should have consumed. This requires recipes with real quantities, which is the step most operations skip — and skipping it is exactly why their inventory data can't answer any interesting question.
Variance = actual − theoretical. Anything under 2–3% is normal. Consistently above 5% on one ingredient is a portioning problem, a waste problem, or a theft problem, and the ingredient tells you which by how it behaves.
Food cost % = cost of goods sold ÷ revenue. Useful at the venue level, useless for diagnosis — it tells you something is wrong without ever telling you what.
Inventory turnover = COGS ÷ average inventory value. Low turnover means cash sitting on shelves and produce heading for the bin.
The problem with manual counts
A weekly or monthly count captures a single moment, then goes stale immediately. Waste, over-portioning, and theft all happen between counts, invisibly. By the time a variance shows up, there's no way to tell which shift or which dish caused it.
What changes with recipe-based tracking
When every menu item is built from real ingredients and quantities — the way restaurant inventory management software is meant to work — selling a dish automatically deducts exactly what it used. Stock levels stay current in real time, without anyone entering a number by hand — and a spike in usage on one ingredient points straight back to the dish or shift responsible.
Two details decide whether this works in practice. Quantities have to be per portion size, or a large deducts the same as a small and the whole model drifts. And the deduction has to fire at a moment you choose — when the order is placed, when the kitchen starts it, or when it's served — because a kitchen that voids a lot of orders and one that almost never does want different answers.
Name the reason when you throw something away
Waste recorded as a number is an accounting entry. Waste recorded with a reason is a diagnosis. Expired, burned, spoiled, kitchen error, damaged, spilled — the same €400 looks entirely different depending on which of those it was, and only one of those six is fixed by ordering less.
Recording the reason costs a few seconds at the bin and is the difference between knowing you waste too much and knowing which shift, which dish, and which habit is doing it.
Catching problems before service, not after
Low-stock signals only matter if they arrive early enough to act on — before a shift starts, not mid-service when a guest has already ordered the dish. Setting a minimum per ingredient turns a stock level into a status you can filter on, and turns the reorder decision into a list rather than a memory exercise.
The stricter version of this is letting the menu respond on its own: when an ingredient hits zero, the dishes that need it stop being orderable rather than being sold and apologised for. It's worth switching on deliberately rather than by default — a kitchen whose counts aren't trustworthy yet will 86 half its own menu on bad data.
Common mistakes
Counting everything at the same frequency. Effort should follow value and volatility, not fairness.
Recipes that were written once and never updated. Portion sizes drift, suppliers change pack sizes, and a stale recipe quietly produces variance that looks like theft.
Tracking stock without tracking cost. Quantities tell you what you have. Only cost tells you whether the dish is worth making.
Treating a negative stock level as an error to hide. It's information — it means something was sold that the system didn't think you had, which is usually a missing recipe or a missed delivery.
Adjusting the count to match the system. Covered above, and worth repeating, because it's the one that renders everything else pointless.
Spreadsheet or software?
A spreadsheet is genuinely fine for a small operation with a short menu and one person doing the ordering. It stops being fine at the point you want theoretical usage, because that means maintaining recipes, sizes, and sales data in a sheet that nobody else can safely touch.
The practical dividing line isn't the size of the venue. It's whether you want to know what your stock should be. Answering that requires the menu, the recipes, and the orders to live in the same place — which is the argument for inventory being part of the system that takes the orders rather than a separate tool you reconcile against it.
Where this connects to the rest of the business
Inventory tied to real sales data also feeds restaurant analytics and reporting — knowing not just what sold, but what it actually cost to make. That's the difference between a revenue report and a report that tells you which dish to cut. A dish with a strong margin and weak sales needs a menu decision; a dish with strong sales and a thin margin needs a price or a recipe change. Revenue alone can't distinguish them.