Cycle counting vs. physical inventory count: which one actually catches shrinkage
iotoms team · October 7, 2026 · 5 min read
A janitorial and food-service supplies distributor runs four retail counters alongside its delivery routes, selling everything from case-pack paper towels to single units of degreaser to contractors who walk in without an appointment. Once a year, the week after New Year's, every counter closes for two days for the full physical inventory count. Staff pull double shifts counting shelves by hand against a printed list, re-counting anything that looks off, and reconciling the result into the books a week later.
The count always finds variance. Some of it is explainable — a case that got double-entered during receiving, a SKU that was discontinued and never zeroed out. Some of it isn't. A few hundred dollars of a fast-moving sanitizer line is just gone, with no return, no damage report, no obvious explanation. Nobody can say when it went missing, because the last time anyone counted that shelf was twelve months ago.
The count that arrives too late to matter
That twelve-month gap is the actual problem, not the missing sanitizer. Whatever caused the shrinkage — a miscounted delivery, a return put back on the wrong shelf, a void that wasn't really a void — happened at some unknown point in the past year. By the time the annual count surfaces it, the person who could explain it has moved on, the receiving paperwork has been shredded per retention policy, and the register logs from that period are long gone from anyone's attention. The count is accurate about the present and useless about the cause.
It also costs more than the two closed days suggest. Staff who count shelves for eight hours straight get tired and sloppy by hour six, so the count itself introduces new errors that have to be caught on a second pass. Closing the counter for two days during a slow week still means two days of walk-in sales lost to whichever competitor is open. And because the count happens once, every SKU gets the same attention regardless of whether it's a twelve-dollar bottle of glass cleaner or a case of bleach that moves fifty units a week — the count spends as much time on dead stock as it does on the inventory that actually drives the shrinkage number.
What changed: counting in slices instead of all at once
The owner's bookkeeper, after reading about how warehouses handle this, proposed splitting the count into small daily pieces instead of one annual event — cycle counting instead of a full physical inventory. The two aren't really competing methods so much as different tools: a physical count touches every SKU at once, a cycle count touches a slice of SKUs on a rolling schedule, so the whole catalog gets covered gradually without ever closing the doors.
The slices weren't random. They ranked every SKU by a mix of sales volume and dollar value — the classic high-velocity, high-value items first — and put those on a weekly count, mid-tier items on a monthly count, and slow movers on a quarterly pass. The sanitizer line that went missing would have been counted every week instead of once a year, which turns a twelve-month blind spot into, at worst, a seven-day one.
Counting happened during the first twenty minutes of the slowest shift, not as a special closed-door event — a handful of bins, checked against what the system expected to be there, logged, done. Anyone could do it; it stopped being a once-a-year ordeal that needed temp staff and became a small recurring habit built into a normal day.
The other change was what happened when a count didn't match. Instead of a vague note for "the annual reconciliation," each variance got a name attached — who counted it, what the system expected, what was actually on the shelf — and someone owned chasing it down within the week, while the receiving slip or the return log from three days ago still existed and the person involved still remembered the shift. Most turned out to be simple: a transfer between counters that hadn't been logged, a price-check item put back on the wrong peg. The ones that didn't have an easy explanation were the ones worth escalating, and there were far fewer of them because the easy ones got caught before they could compound into "the sanitizer is just gone."
Running both, not choosing one
None of this replaced the annual count entirely — it still runs, mostly for the accountants and for the SKUs too obscure to make any cycle schedule. But it stopped being the only check, and stopped being the first time anyone learned something was wrong.
A cycle counting setup that holds up:
- Rank SKUs by sales velocity and dollar value, not alphabetically or by category — that ranking decides count frequency, not a fixed schedule for everything.
- Count a small slice every day or week as a normal task, not a scheduled shutdown that needs extra staff.
- Compare against the system's expected on-hand at the moment of the count, not a stale printed list from last week.
- Attach a name and a deadline to every variance — unowned discrepancies just get re-explained the same way next time, which is no explanation at all.
- Keep one full physical count a year for audit and for the long tail of slow-moving SKUs no cycle schedule reaches.
iotoms keeps a live perpetual count behind every counter sale, so a cycle count is a comparison against what the system actually expects right now rather than a guess, and variances land as a named, dated exception on one of the 48 built-in reports instead of a mystery discovered a year later.