Inventory management: traditional method vs the Masterestaurant method

What is the best inventory method for an independent restaurant with 12 to 40 tables?

For an independent venue with 12 to 40 tables and a single manager, the best method is a WEEKLY count of the 20 items that carry 80% of your food cost, backed by a living spreadsheet that AI pre-loads with the supplier invoice.

That tapas bar in Valencia billed 41,000 EUR a month, declared 29% food cost and ran at a real 36.4%: 7.4 points, 3,034 EUR every month, 36,400 EUR a year lost to counting on the last Sunday of the month with an exhausted crew. Moving from thirty days to seven takes no software; it takes someone counting for forty minutes each Monday before service. A month is an accounting unit, never an operating one, and no chef fixes in August what slipped away in July. If your menu rests on seven or eight inputs and one supplier, a spreadsheet suits you and software is dead weight.

Best for operations with fewer than eight critical items: the spreadsheet wins outright

A 180 EUR monthly system charges 2,160 EUR a year to watch purchasing that fits in a notebook, and it hands you a chore nobody will do: keeping the item catalogue current every time a supplier changes a pack format. Against typical revenue of 25,000 EUR a month at 30% food cost, those 2,160 EUR equal 2.4% of yearly spend on goods — money that pays off better in a decent scale and in written recipe cards. Diego F. Parra says it in every Masterestaurant diagnosis: you choose the tool by the number of items you actually move, never by the size you wish you had. A restaurant three months old needs its first inventory in week one, even while the menu keeps shifting. Postponing it until everything settles is the most expensive mistake of an opening, because when you finally count and land on 38% food cost, you cannot tell how much comes from the recipe, how much from purchasing and how much from waste.

Best for newly opened venues: your baseline belongs in week one, not once the menu settles

With no baseline there is no diagnosis, only opinion. Start with provisional recipe cards, accept 10% imprecision in gram weights and correct as you go for eight weeks; by the ninth you own a real curve. With back-of-house turnover at 43% a year (meez, Restaurant Employee Turnover 2025), that provisional document is also the only thing that survives when the cook who knew it all by heart leaves in month four. A twelve-unit group with a corporate ERP should build cycle counting INSIDE the system it already owns, rather than stacking another tool on top. Two sources of truth produce two food cost figures, and the manager on shift will always defend whichever number flatters him. The arithmetic is plain: split the 60 or 80 items into five groups and count one group each working day, twelve to sixteen articles daily, fifteen minutes, no kitchen shutdown and no inventory Sundays.

Best for multi-unit groups: a cycle layer inside the ERP, never a second system running alongside

Every item gets touched once a week and the storeroom never faces a workload spike. With managerial turnover at 38% in full service (Black Box Intelligence, Q3 2024, against 31% in 2019), the procedure has to live written in the ERP, because the manager who learned it will be somewhere else within two and a half years. Specialised software — the choice everyone recommends in 2026 — is the wrong call in three concrete cases. First, the seven-item operation described above: 2,160 EUR a year to automate what a sheet of paper settles. Second, the high-turnover kitchen that has never written a single recipe card, since the system will compare real usage against a theoretical figure someone invented, and at 43% back-of-house turnover (meez, 2025) nobody will ever fix those gram weights. Third, the venue billing 41,000 EUR at a real 36.4% food cost with no idea why: there the problem is counting frequency, not data capture, and buying software gifts you a gorgeous dashboard fed with monthly garbage.

When NOT to pick the popular option: three scenarios where inventory software loses?

Repair the process first; automate afterwards what already works. Some signals disqualify a vendor before the demo starts. First one: they sell POS integration but never consume recipe cards dish by dish, so they will never compute a real food cost variance.

Second: the item catalogue loads by hand and the contract excludes migration, which means your manager spends two weeks typing references instead of running the shift. The third flag is per-venue pricing with no cap, lethal the day you open a second or third unit. And the fourth, quietest of all: the system accepts purchase units only, not recipe units, so a 4.5 kg case enters the storeroom as «one case» and you will never know what a tenderloin portion costs. Ask to see those four things on screen with YOUR products. A rough inventory from three days ago beats a perfect one from thirty days ago, and that is the axis of the Masterestaurant method.

Delay weighs more than accuracy: why a rough count from three days ago is worth more

The thirty-day count only serves to write the autopsy; the three-day count still lets you shift Tuesday's order. Put it in money: at 41,000 EUR of monthly revenue, each food cost point is 410 EUR, so a two-point drift caught in week one costs 205 EUR instead of 820. The tension is genuine, because accuracy does matter — a badly calibrated scale ruins the number just the same — yet accuracy without frequency yields reports, while frequency at acceptable accuracy yields decisions. Diego F. Parra orders the pair like this: count often first, count fine afterwards. Reverse that order and you fill folders without moving the margin. Suppose you skip inventory for three months because service is packed and hands are short. In month one your declared food cost holds at 29% and the till covers it. In month two a supplier raises oil by 9% and it escapes you, because the cost price lives on a card nobody has touched since March.

What would happen if you skipped counting for a whole quarter?

By month three, the waste from a fresh product over-ordered every Friday already adds up to 600 EUR and has turned into habit.

You close the quarter at a real 36.4% and 9,100 EUR lighter, and the money is not the worst part: you will negotiate with suppliers, adjust menu prices and compute your break-even on an invented figure. No decision built on an invented figure holds up for more than a quarter running. SCENARIO 1 — you opened three months ago and postponed inventory until the menu settles. That is a new site's most expensive mistake: with no baseline, when you finally count you cannot tell whether 38% food cost comes from your recipe, your purchasing or your waste. Start in week one with provisional recipe cards and fix them as you go. SCENARIO 2 — you signed a 180 EUR/month inventory platform for an operation with seven critical references and one supplier.

When NOT to pick the popular option (and when the popular one is right)?

The spreadsheet wins outright there: the system charges you 2,160 EUR a year to watch a purchase that fits in a notebook, and it adds catalogue maintenance nobody will ever do.

SCENARIO 3 — you run twelve locations on a corporate ERP and want a cycle-count layer on top. Do not add tooling: variance in a group that size is usually born at unweighed receiving and undocumented inter-site transfers, and that gets fixed with a signature and a scale, not another screen. The tension almost nobody resolves: counting more often looks like it steals time from service, and counting rarely looks like it protects service. It runs the other way. A 30-table operation counting 20 references on Tuesday morning spends 45 minutes of a slow shift; that same operation, counting everything on the last Sunday, burns five hours of the week's most profitable shift and gets worse data for it.

When NOT to pick the popular option (and when the popular one is right) — in practice?

A position worth taking: absolute accuracy does not exist, and chasing it is where managers get lost. A count with 3% error run every seven days catches a structural leak sooner than a count with 0.5% error run every thirty.

Frequency beats precision because shrinkage is not an event, it is a slope.