Cycle Counting vs Annual Stocktake
The annual stocktake finds a year of errors at once, explains none of them, and shuts the operation to do it — cycle counting finds them weekly, warm, and attributable. How the two compare and how to switch.
An annual stocktake counts everything, once, usually over a shutdown weekend at year-end. Cycle counting counts a small slice of stock continuously — a section a week, a category a day — so everything is verified on a rolling schedule without ever stopping the operation. Both aim at the same target: a stock record that matches physical reality. Only one of them tells you why they diverged.
The core problem with the annual count
A variance found in December could have happened in any of 300 days, under any of a dozen causes — theft, miscounted receiving, unrecorded damage, a unit-of-measure error in March. With the trail cold, the investigation is a shrug and a write-off, and the same causes run undisturbed into the new year. The annual count is not a control; it is an annual measurement of how absent the controls were.
| Dimension | Annual stocktake | Cycle counting |
|---|---|---|
| Frequency per item | Once a year | Weekly to quarterly, by item importance |
| Operational cost | Shutdown, overtime, all hands | 15–30 minutes a day inside normal work |
| Variance age when found | Up to 12 months — cause unknowable | Days — CCTV, memory, and documents still exist |
| Effect on behavior | A season of panic, then relaxation | Continuous: everyone knows counting is always happening |
| Record accuracy between counts | Decays all year | Held continuously high |
| Auditor's view | Accepted, with attendance | Preferred, when the program is documented and disciplined |
Designing a cycle count program
- Classify by importance (ABC): the 10–20% of items carrying most of the value or risk (A) count monthly or better; mid-tier (B) quarterly; the long tail (C) once or twice a year. High-risk items — bar stock, meats, fuel, fast movers — count daily regardless of value class.
- Blind counts: the counter records what they see without the system quantity on the sheet. Counting toward a known number produces the known number.
- Same-day variance handling: investigate, then adjust with a reason code from a fixed list — the adjustment discipline that keeps write-offs from laundering causes.
- Rotate counters and separate duties: the storekeeper's own stock is periodically counted by someone else; the record-keeper is not the verifier.
- Track accuracy as a KPI: percentage of items counted within tolerance, trended by section and by month — the number tells you where process is broken before the money says it loudly.
You still count everything once
Cycle counting starts from a verified baseline — one full, honest count (the last annual stocktake you will ever need). After that, the rolling program keeps the baseline true, and year-end becomes a review of count records rather than a warehouse shutdown. Many auditors accept exactly that, given a documented program with good accuracy history — agree it with yours in advance.
What cycle counting requires
One honest precondition: a live perpetual inventory record. If stock movements are batched into the system weekly, every count "variance" is partly just recording lag, and the program measures noise. Real-time movement capture — sales moving stock at the till, receipts at the door, issues at the store — comes first; the counting workflow then verifies a record that is at least trying to be true.
What AWRA OpsHub does today
- Count plans scoped by warehouse, location, category or an explicit list of items, so a rolling programme is a configuration rather than a spreadsheet.
- Blind counting that is genuinely blind. The expected quantity is withheld from the counter, and revealing it requires a separate permission. This is enforced, not advisory.
- Count sessions, assignments and lines, so a count belongs to a named person and a specific location rather than to the room.
- Variance rules with thresholds on absolute quantity, percentage and value — each rule can auto-adjust within tolerance or force approval beyond it.
- An audit event trail on the count itself, separate from the resulting stock adjustment.
- Items locked while being counted, so a sale mid-count cannot silently invalidate the result — the lock reaches the till, which refuses the sale with the reason stated rather than letting it through.
- A per-line recount request with a reason, which moves that line to a recount-requested state, records who asked for it and writes an audit event. A formal second-count step, not a re-run of the session.
More we can add to your workspace
- An accuracy KPI: a count-accuracy percentage, a trend over time, and a scoreboard by counter and location. Variance is visible per count today; the programme-level metric is the build.
- A count scheduling calendar. Plans define scope, not a recurring date — the rhythm is yours to run. A plan does carry a frequency, but nothing reads it, so no session is ever raised for you.
- An ABC, velocity or risk classification on an item, so a plan cannot be scoped to "count the A items weekly". Use categories as the substitute — they are a real field and they do scope both counts and variance rules.
- An enforced separation on a recount. The same person can recount their own line; assigning it to somebody else is a procedure, not a rule.
- A shift dimension. A count belongs to a session — a window of time — not to a shift, so per-shift stock variance is not produced, even though the cash drawer does attribute variance to a named cashier.
The blind-count permission is the part worth checking on a demo, because it is the one control that makes every variance figure afterwards mean anything — and it is also the one most systems describe as blind while showing the expected quantity in a column somewhere.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsCounting verifies the record; it does not by itself stop the record drifting. The five procedural leaks that cause the drift are covered in stock control in Kenya.
Retire the shutdown weekend
Cycle-count plans with genuinely blind entry, variance rules that force approval beyond tolerance, and reason-coded adjustments — counting as a routine, not an event.
See cycle counting in AWRAFrequently asked questions
Can cycle counting fully replace the annual stocktake?
Operationally, yes — a disciplined program keeps records more accurate than any annual count. Whether it replaces the year-end count for audit purposes depends on your auditor accepting the program's documentation and accuracy history; many do. Agree the evidence standard with them before you cancel the shutdown.
How many items should we count per day?
Work backwards from the schedule: if A-items must be counted monthly and you have 400 of them, that is ~20 per working day, plus a rotating slice of B and C. Most SME stores land at 15–30 minutes of counting a day — one person, inside the quiet hour.
What accuracy rate should we target?
Mature programs run 95%+ of counted lines within tolerance. Below 90%, stop expanding the program and fix the process feeding it — receiving, issuing, or adjustment discipline — because you are counting a broken pipeline faster, not fixing it.
What do we do when a count finds a big variance?
Freeze, recount (different person), then investigate before adjusting: recent receipts, issues, transfers, and unit-of-measure errors explain most large variances — theft explains fewer than assumed but is confirmed the same way. The adjustment posts only with the investigation's reason attached.
