Why the annual shutdown count fails.
A traditional year-end count locks the doors, pulls 30 staff in for a Saturday, and counts every SKU in every aisle in one painful sweep. By Monday morning the variance report shows 800 SKUs off by some amount, the team cannot remember what happened nine months ago for any of them, and you adjust the books with a single massive journal entry that your auditor cannot meaningfully test.
The deeper problem is that the count tells you what is wrong but not why. Was it shrinkage, miscounted receiving, transfers booked to the wrong branch, or just keying errors at POS? With a year of activity to review, nobody investigates. The variance gets posted to Inventory Adjustment, gross margin takes a hit, and the same problems repeat next year.
The cycle count alternative.
Cycle counting splits your catalog into chunks and counts a different chunk every working day. A 5,000 SKU shop counting 25 SKUs per day per branch covers everything in 200 working days — roughly once a year — without ever closing. Variances surface within days of when they actually happened, while staff still remember the receiving error or the transfer that went sideways.
The math is forgiving. Even if you only count for 15 minutes a day, on the right SKUs, you catch the 80% of value problems in the first 20% of effort. You also build a continuous data trail your auditor loves: 250 small documented adjustments across the year is far easier to defend than one giant year-end correction.
Picking what to count when.
Use ABC analysis to drive the schedule. A items are roughly the top 20% of SKUs that produce 80% of revenue or value — count these monthly. B items are the next 30% — count them quarterly. C items are the long tail — count them once or twice a year. A pharmacy with 12,000 SKUs across 8 branches might end up counting 60 A-class SKUs per branch per week, which is two staff for one hour each shift.
Layer in event-driven counts on top: any SKU that hit a negative on-hand, any SKU after a stock transfer dispute, any SKU flagged by the system as having unusually high adjustment history. These are not in the schedule but they pay back the most. Nonari can flag these automatically based on transaction patterns.
- A items: monthly cycle count, full physical once a year
- B items: quarterly cycle count, sample audit annually
- C items: semi-annual cycle count, statistical sample only
- Event-driven: any SKU that hit zero or negative gets counted within 48 hours
How to run the count without disrupting sales.
Pick a slow window — first hour after opening for most retail, last hour for restaurants. Freeze movement on the SKUs being counted: no sales, no transfers, no receiving on those specific items for the duration. Modern POS lets you flag a SKU as "in count" so a cashier scanning it gets a soft warning. Everything else keeps trading.
Have two people count independently. Person A counts and writes the number on a slip. Person B counts and enters into the system without seeing A. Variances between the two slips get a third count by a supervisor. This is slower per SKU but eliminates the most common error mode: one tired person miscounting and nobody catching it.
A worked example: 8 branches, 6,000 skus.
A clothing chain in Manchester has 8 branches, 6,000 active SKUs, and used to do a full holiday week shutdown count every year. They switched to ABC-driven cycle counts. A items: 1,200 SKUs counted monthly = 60 per branch per working day, takes 30 minutes per branch in the morning. B items: 1,800 SKUs counted quarterly = 30 per branch per working day, another 15 minutes. C items: 3,000 SKUs counted twice yearly = 25 per branch per working day, another 10 minutes.
Total time investment: under one hour per branch per morning. They no longer close for stock count. Variance recovery improved by 38% in the first year because issues were investigated within days, not months. Same number of staff hours, just spread across the year instead of one painful Saturday.
Posting the variance the right way.
When a count comes back short, the journal is straightforward. Suppose a branch counts 47 units of an item but the system says 50, at a WAC of GBP 2.00. The 3 missing units are GBP 6.00 of inventory that has to come off the books.
Debit Inventory Adjustment Expense GBP 6.00. Credit Inventory (BranchInventory) GBP 6.00. If the system is set up properly, this posts automatically when the count is finalized — you do not write the journal by hand. Nonari posts every count variance to Inventory Adjustment by default, with the count document attached for audit trail. Surplus counts (where you find more than the system says) reverse the same accounts.
Targets that tell you the program is working.
Healthy cycle count programs hit a few benchmarks. Variance rate below 1% by value on A items, below 2% on B, below 3% on C. Investigation rate above 80% — meaning at least 4 out of 5 variances get a documented root cause. Time-to-investigate below 7 days from count to closure. If you are missing these, the program is running but not paying back.
Track these monthly per branch. Branches with chronic high variance usually have a specific cause: a weak receiver, a busy back door, a particular SKU category that moves too fast for the current process. The point of cycle counting is not to count perfectly — it is to find these patterns early enough to fix the process, not just adjust the books.