Stock counts

A stock count is the moment the kitchen and the pantry list look each other in the eye. Someone walks the walk-in with a tablet, counts what’s actually there, types the numbers in, and the system writes those numbers over its own — bringing the row in the inventory list back to match the shelf. Without this step, every other number drifts: tomorrow’s order is built on a fiction, tonight’s food cost is off, the dashboards lie.

This page is for the head chef who has to plan the count, and for the owner who has to read the variance report after.

Why this page exists

Even with deliveries logged on receipt, sales deducted by the till, prep deducted by the kitchen, and waste logged by the line, the number on the row drifts. A pot of stock evaporates an extra litre on a hot day. Someone trims a kilo of tomatoes and forgets to log the waste. A cook tastes too generously from the parmesan. A delivery goes in but nobody scans it because the kitchen is slammed. Each of those is small. Multiplied by a hundred rows over a month, the system’s idea of the pantry and the actual pantry stop agreeing.

The stock count is the only operation that doesn’t compute the new stock — it overwrites it. The cooks count reality and reality wins. Everything that lives downstream — the Below par shortlist, the food-cost percentages, the procurement forecast — gets a fresh foundation to compute from.

The other reason this page exists is conversation. A €54 variance on the walk-in for the month isn’t an accounting line; it’s a discussion the chef has with the team the next morning. Where did three kilos of tomatoes go that we didn’t sell or waste? The count produces the question; the count’s variance report makes it visible.

The rule

Current stock is a count of reality, not a derived number. The stock count is the only place that number gets to win the argument with the system. Everything else — deliveries, sales, prep, waste — adjusts the number. The count replaces it.

The two patterns

Full count, monthly. Everything in the pantry, on the same morning, before deliveries. The whole list, every row, walked in order — typically by location, so the cook moves through the walk-in once, the dry store once, the bar once. The full count is the one that catches the drift you can’t see from a single shelf: the slow leaks, the systemic miscounts, the categories where the system has been wrong for weeks.

Spot count, daily or weekly. One category, or one location, counted on its own. The protein shelf on Monday morning. The wines on Friday before service. Just the dry pasta when something feels off. Spot counts are fast — twenty rows, ten minutes — and they’re the right tool when the chef has a suspicion, or when one category is high-value enough to deserve weekly attention without slowing down the others.

The system doesn’t care which pattern you use. Every count, whatever its scope, writes the same kind of correction.

Whatever scope you pick, a count covers the things you can physically count: your bought ingredients and the preps you make in batches and hold — the ragù, the stock, the dough, the tray of tiramisu. It automatically skips made-to-order dishes, the ones plated fresh per order. Those carry no shelf stock to count, so listing them would only be noise on the count screen. (This is the same rule that decides what shows up in the inventory list — a count and the list always cover the same set of rows.)

How to use it

Open /admin/stock-takes from the back-of-house section of the sidebar. The page shows three stat cards at the top — In Progress, Pending Review, Completed — and the history of past sessions below.

Starting a count. Tap + New Stock Count at the top right. A dialog asks for a name (Month-end July 2026, Friday wine count), an optional scope (Storage location drop-down for a location count, Category drop-down for a category count, or All locations / All categories for a full count), and an optional note for the reviewing manager. Tap Start Count. The session shows up as a draft, ready to count.

Counting. Tap the draft to open the count screen. Every row in scope shows the item’s name, the Expected quantity (what the system thinks), and a field for the Actual quantity. The cook walks the shelf, types the number, moves to the next row. The screen marks each row as ✓ Counted once the cook tabs out of the field. Filters at the top let you switch between Counted and Uncounted so a half-finished session can resume where it left off — the count is saved continuously, so closing the tab and reopening on a different device is safe.

Variance — the difference between expected and counted — appears next to each row as the cook types. A small variance is normal; a big one is a flag. The kitchen doesn’t act on variance during the count, it just keeps counting; the report is where the conversation happens.

Syncing a count with inventory. A count is a frozen photograph of the pantry list taken the moment you started it — so if you rename an item, move it to a different shelf, or add a brand-new product after the session is open, the count screen keeps showing what it captured at the start. That’s deliberate: the labels on the screen should match the labels on the shelf the day you counted. But sometimes you want the count to catch up — you tidied a few item names, or a new delivery added products that belong in this count. Tap ↻ Sync from inventory in the header. The system re-pulls every in-scope item’s name, category, location, and expected quantity from the live pantry list: items you’ve already counted keep their counted numbers untouched, items that newly match the count’s scope get added, and uncounted items that no longer belong drop off. A short line confirms what changed (“Synced from inventory — 2 added, 40 updated”). Counted rows are never removed, so you can never lose counting work to a sync.

Submitting for review. When every row is counted (or you’ve decided you’ve counted enough), tap Submit for review →. The session flips to Pending Review and lands in the manager’s queue.

Approving. A manager opens the pending session, lands on the report view, and reads the variance summary — total variance cost, the rows with the biggest gaps, the rows that match cleanly. Tapping Approve & complete opens a short confirmation with one important choice: Apply counts to inventory stock. Leave it ticked (the default) and approving writes every counted Actual into each row’s Current stock — the count wins the argument with the system. Untick it for an audit-only count: the variance report is still saved and the session still completes, but no stock is touched — useful when you want the figures on record without acting on them, or when the numbers look wrong and you’d rather re-count than apply them. Either way the finished report carries a clear banner at the top — Applied to inventory, or Audit-only — your inventory was not changed — so there’s never any doubt about whether a count actually moved your stock. Reject sends the session back for re-counting if something looks off (a wrong unit, a row counted by the wrong cook, an obvious typo).

The safety check. Before you can apply a count, the system scans it for numbers that look like a slip of the thumb — a row counted at more than ten times what was expected, or any single line that would swing your stock value by tens of thousands of baht. If it finds any, it lists them right in the confirmation (“3 counts look unusually large”) and asks you to tick a box confirming you’ve checked them before Confirm & complete will go through. It’s the difference between 5 kg of guanciale and a fat-fingered 500: the count that would otherwise quietly add a million baht of cured pork to your shelves now stops and asks first. (Approving audit-only skips the gate, since nothing is being written.)

What happens behind the scenes

When the count is created, the system takes a snapshot of every in-scope row’s current expected quantity. From that moment on the Expected column on the count screen reads the snapshot, not the live number — so a delivery that lands mid-count doesn’t pull the target out from under the counter’s feet. The cooks count one frozen reality; the system reconciles against that same frozen reality.

The one deliberate exception is ↻ Sync from inventory. When you tap it, the system re-runs the count’s original scope (the same location, category, or level you picked when you started) against the live pantry list and reconciles the session’s rows: matching items have their snapshot — name, category, location, units, expected quantity — patched back to current values; newly matching items are inserted as uncounted rows; and uncounted rows that fell out of scope are removed. Any row you’ve already counted is left exactly as it was, including its counted number, so a sync can add and refresh but never erases work. A sync is only possible while the session is still open (draft or in progress) — once it’s submitted or completed it’s a locked record and re-pulling would corrupt the audit trail.

When the manager approves, the system writes one stock adjustment per counted row, reason stock-count-correction. The row’s Current stock becomes the Actual the cook typed. There is no cascade — the cost-per-unit of the row doesn’t change, the recipes don’t recompute, the dashboards don’t move except for the stock-value figures. The count moves quantities, not costs. Costs come from suppliers and recipes; the count just tells reality the right number to be at.

The session, with every counted row and every adjustment, lives in the history list and on each item’s Stock counts tab. When a future debate breaks out — why does this row say 47 today when we counted 50 last week? — the history points at the right session.

Worked example

End of month. The chef walks the walk-in at 7 a.m., before the morning’s deliveries, with a tablet and a cup of espresso. She opens /admin/stock-takes, taps + New Stock Count, names it Month-end May 2026, sets Storage location to Walk-in cold, leaves Category empty, taps Start Count.

The count screen lists 47 rows — every item that lives in the walk-in. Most match within five per cent and she counts through them quickly. Three rows jump out.

Tomatoes, San Marzano tinned. Expected 8 kg, counted 5 kg. The variance is 3 kg, valued at about €15. She moves on; she’ll think about it in the report.

Parmesan, 24-month. Expected 2 kg, counted 2.4 kg. The variance is positive — there’s more on the shelf than the system thought. Probably a delivery that the kitchen put away without scanning two weeks ago.

Guanciale, artisan. Expected 1.5 kg, counted 0. Fully used during a weekend service; the cook who finished it never logged the last cut, never reordered. The kitchen ran out, the line shouted, the chef remembers — but the row never moved to zero.

She finishes the other 44 rows in twenty minutes, submits for review. The owner opens it in the office, reads the report: total variance cost –€54 for the walk-in for the month, mostly on tomatoes, partly offset by the parmesan surplus. He approves. The three problem rows are now at 5 kg, 2.4 kg, and 0 kg respectively; the Below par shortlist correctly flags both tomatoes and guanciale on the next refresh; the food-cost percentages on the dashboard don’t move (cost-per-unit didn’t change, only quantities did).

At 9 a.m. the chef walks the morning brief. Where did three kilos of tomatoes go that we didn’t sell or waste this month? Three answers come back. Two of them — the cook who tastes too generously, the trim from the Sunday lunch prep that nobody logged — are conversations she has on the spot. The third — a wedge of dough that fell on the floor and went straight in the bin — is the team learning to use the waste log in the moment, not at the end of the month.

One count, three honest rows, one conversation. The pantry is closer to reality than it was at 6:59 a.m., and tomorrow’s order goes out from a number that means something.

Fixing a wrong number

Sometimes a count is approved with the wrong figure before anyone catches it — a cook types 500 where they meant 5 — or a single row is simply off and you don’t want to run a whole new count to fix it. You don’t have to. Open the item from the inventory list and tap ⚖️ Correct stock. A small dialog shows what’s currently recorded, lets you type the right quantity in the unit you buy and store the item in, previews the new stock value as you type so a mistyped number is obvious, and saves it straight to the row.

The correction is logged the same way a count is — who changed it, from what to what, and when — so it’s just as traceable. It’s the quick, single-item counterpart to a stock count: the same effect on the number, none of the ceremony. Only owners and managers can do it.

One thing worth knowing: a completed count can’t be “un-approved.” A finished session is a locked record on purpose. So if an applied count left a row wrong, you don’t reopen the count — you correct the item directly with Correct stock, and the old count stays in the history as the record of what happened. If the bad count was approved audit-only, there’s nothing to undo at all: your stock was never touched, and the report is just a note on file.

Inventory — overview — the list whose Current stock column the count rewrites
Editing an inventory item — every counted row’s Stock counts tab shows the history of every session that touched it
Waste log — the place to record stock leaving without a sale, so the next month’s count variance only contains the genuinely surprising drift
Storage locations — the catalogue the Storage location filter on the count dialog draws from
Inventory categories — the catalogue the Category filter on the count dialog draws from
Where your information lives — the five rooms of the system; the count is the only operation that lets the kitchen overwrite a number in the pantry