Counting the Shop Without Closing It
Counting stock here is a proper workflow — plans, assignments, blind counts, a freeze that genuinely stops the till, variance thresholds that auto-approve small differences and escalate large ones. One dimension is missing, and it is the one a shop with shifts will look for first.
The annual stock-take is a ritual that produces one number a year, arrives too late to act on, and is wrong in ways nobody can trace — because by the time the count is reconciled, six weeks of movement have happened on top of it. Every shop knows this. Almost none of them switch to counting continuously, because counting continuously requires the system to answer a hard question: what do I do about the sale that happens while somebody is counting that shelf?
This system has an answer, and it is a real one: it stops the sale. That single capability is what makes cycle counting practical rather than theoretical, and it is the thing most worth understanding before you plan your first count.
The shape of a count
A count has more structure than "type in what you found", and each layer of it removes a specific way counts go wrong.
A plan
A reusable definition of what gets counted and how — the scope, whether it is blind, whether stock freezes. You set up "front shelves, weekly, blind" once and raise sessions from it.
A session
One actual count, numbered, with a status that moves from open through submitted to approved and adjusted. It is either a cycle count or a full physical count, and that is a stated type, not a convention.
A scope
Warehouse, location, product category, or an explicit list of items. This is what makes a count small enough to do before opening — one aisle, one category, twenty high-value lines.
An expected-quantity snapshot
When the session starts, the system writes a line for every item-location-batch row in scope, capturing the quantity it believes is there and the unit cost at that moment. The variance is measured against that frozen snapshot, not against a moving figure.
Assignments
Lines can be assigned to specific counters, so two people can count two halves of a store without seeing each other's work or each other's numbers.
A freeze
Optional per session. When on, the items in scope genuinely cannot move — including through the till. See below, because this is the important one.
Variance rules
Thresholds on quantity, percentage and value, scoped by warehouse and category, deciding what auto-approves and what waits for a human.
The adjustment
Approving a session applies the approved lines as stock adjustments. Until that happens nothing has moved — a count is a proposal, not a change.
The division worth noticing: the count proposes and the approval acts. A counted line sits as a proposed variance until a rule or a person accepts it, so a fat-fingered entry is a conversation rather than a stock movement.
The freeze that stops the till
Turn on freeze for a session and the items in its scope are locked. Not warned about — locked. Every stock movement path checks for an active counting lock before it does anything: receipts, issues, transfers in, transfers out, adjustments, and the point of sale.
A cashier who scans a frozen item during a count gets the sale refused with the reason stated: the stock is locked by an active inventory count session. That is inconvenient by design. The alternative — letting the sale through — means the number the counter wrote down was true for about four seconds, and the variance you spend the afternoon investigating is an artefact of your own till.
A count that does not stop movement is not a count. It is a guess taken carefully.
Which is exactly why the scope matters so much. A freeze over one category at seven in the morning costs you nothing. A freeze over the whole warehouse at midday closes the shop. The scoping controls — warehouse, location, category, explicit item list — exist so the freeze can be narrow enough to be affordable. Use them.
Blind counting, and what it is protecting against
In a blind count, the person counting cannot see what the system expects. This is not distrust; it is an acknowledgement of how the human eye works. Shown "expected: 47", a counter who reaches 46 counts again more carefully. A counter who reaches 47 stops. The number on the screen is doing the counting.
Blind counting is enforced at the visibility layer here, not merely omitted from a form. While a blind session is active, the quantities for the items in it are restricted for the users counting them, across the places a quantity would otherwise appear. There is a separate reveal permission for supervisors who genuinely need to see the expected figure, and revealing is a deliberate act rather than a side effect of opening a different screen.
The practical combination for a retail shop: blind, frozen, narrow scope, two named counters, first thing in the morning. Twenty minutes, one category, no arguments about whether the number was real.
Variance rules: deciding in advance what is worth a conversation
The reason most counting programmes die is not the counting. It is the reconciliation. A count of four hundred lines produces sixty variances, of which fifty-five are one or two units of low-value stock and five matter. Reviewing all sixty at the same depth is how a weekly count becomes a quarterly count becomes an annual count.
Variance rules are how you stop doing that. A rule carries a maximum absolute quantity, a maximum absolute percentage and a maximum variance value, is scoped by warehouse and product category, and decides two things: whether a line within those limits auto-adjusts, and whether it requires approval.
| Category | Auto-adjust up to | Effect |
|---|---|---|
| Fast-moving low value | 3 units or 500 in value | The bulk of variances clear themselves; nobody reviews a two-unit difference on biscuits |
| General merchandise | 1 unit or 2% or 1,000 in value | Small differences clear, anything unusual waits for a person |
| High value — electronics, phones | Nothing | Every single variance is reviewed, whatever its size |
| Controlled or licensed goods | Nothing | Same, and for the same reason: the variance is the signal, not the value |
Set the high-value categories to auto-adjust nothing before you set anything else. The purpose of a threshold is to protect attention, and attention on a missing phone is worth more than attention on four hundred lines of stationery.
Running one, start to finish
-
Write the plan once
Scope, blind or not, freeze or not. A shop typically ends up with three or four plans — high-value daily, one category rotating weekly, back store monthly, full physical annually — and raises sessions from them rather than defining a scope each time.
-
Raise the session before the doors open
The moment it starts, the expected quantities and unit costs are snapshotted. Start it at 7:00 for a 7:30 count and the snapshot is the shelf as the system understood it overnight.
-
Assign the lines to people by name
Two counters, two halves, no consultation. Assignment is also what makes the blind restriction meaningful per person.
-
Count and submit line by line
Each line takes a counted quantity, an optional reason and a record of the device it came from. Reasons matter more than they look — "shelf label wrong" and "found in back store" are the two most useful sentences in stock control.
-
Let the rules clear the noise
Lines inside your thresholds are approved automatically. What is left is the list that deserves a person, and it is short.
-
Recount rather than argue
Any line can be sent back for a recount, with a reason. A recount by a different person is worth more than a recount by the same person, though the system will not insist on that — see below.
-
Approve, and only then adjust
Applying the approved lines writes the stock adjustments. This is the only step that changes what the system believes, and it is deliberate and separate.
-
Read the reasons, not just the total
The variance value tells you how much you lost. The reasons tell you why, and only one of those two is actionable.
The missing dimension: shifts
Here is what a shop with two shifts will look for, and not find. A count belongs to a session — a window of time between when it started and when it was submitted. It does not belong to a shift. There is no shift field on a count, and no way to say "count the front shelves at the end of every shift and attribute the variance to the people who were on it".
This is a genuine asymmetry inside the same product, and it is worth naming precisely because the cash side does not have it. A cash drawer session is opened by a named cashier, at a named counter, and its variance is attributed to a person. Stock has no equivalent. So you can tell which cashier's drawer is short and you cannot tell which shift's shelves are.
Cash — attributed to a person
- Opened by a named cashier, who declares the opening float themselves.
- Bounded by the shift — from the moment that drawer opens to the moment it is counted.
- Variance stored against the cashier who closed it, permanently, with their notes.
- Comparable over time, session against session, for the same person.
- Per-shift variance is produced as a matter of course.
Stock — attributed to a count
- Raised by whoever started the session, which is not necessarily who counted.
- Bounded by a time window chosen per count, with no relationship to a shift.
- Variance stored against the session, not against a person or a team.
- Comparable over time only if you scope every session identically by hand.
- No per-shift variance. This is the gap, and it is the one a two-shift shop notices first.
The workaround, and its honest cost
Raise one session per shift with an identical scope, name it for the shift, and record the people on duty in the session notes. The variance figures then compare shift to shift, and the attribution lives in a text field rather than in a column. It works. What you cannot do is report on it — grouping variance by shift means exporting sessions and matching names by hand, because nothing in the data model knows a shift happened.
Other edges worth knowing before you commit
Where the system carries the control, and where you do
Movement blocked during a frozen count
Enforced on every path including the till, with the reason shown to the cashier.
Expected quantity hidden from counters
Enforced at the visibility layer, with a separate supervisor reveal permission.
Small variances cleared automatically
Threshold rules on quantity, percentage and value, scoped by warehouse and category.
An audit trail of the transitions
Session events are recorded as the count moves through its states.
Unfrozen counts staying accurate
Without a freeze the expected snapshot ages as the shop trades. Keep unfrozen counts short, or accept that the variance includes your own sales.
A recount going to a different person
Recounts can be requested with a reason, but nothing prevents the same counter recounting their own line. Assign it deliberately.
Anything weighed being countable
Counted quantities are whole numbers, as all stock is here. The item has to be defined in its smallest unit before the first count.
Counting by shift
Not modelled at all. One session per shift with a naming convention is the whole of the workaround.
The four on the left are why this is a strong module. The four on the right are the ones to write into a procedure before the first count, because none of them will announce itself.
What we do and do not do
What AWRA OpsHub does today
- Count plans and sessions, typed as cycle or physical, numbered, with an approval lifecycle.
- Scope by warehouse, location, category or an explicit item list — narrow enough to count before opening.
- An expected-quantity and unit-cost snapshot written when the session starts, so variance is measured against a fixed baseline.
- A freeze that genuinely blocks movement on every path — receipts, issues, transfers, adjustments and the point of sale — with the reason shown to the cashier.
- Blind counts enforced at the visibility layer, per assigned counter, with a separate supervisor reveal permission.
- Assignments so several people count different lines without seeing each other's.
- Variance rules on absolute quantity, percentage and value, scoped by warehouse and category, controlling auto-adjust and approval.
- Recount requests with a reason, per line.
- Approval then adjustment as separate steps — nothing moves until a session is applied.
- Session audit events recording the transitions.
What it does not do
- No shift dimension. A count belongs to a time window, not a shift, so per-shift stock variance is not produced — unlike cash, where variance is attributed to a named cashier.
- No enforced separation on recounts. The same person can recount their own line.
- Whole numbers only. Nothing weighed can be counted in fractions; the item has to be defined in its smallest unit.
- No count-frequency scheduler. A plan carries a frequency, but nothing reads it, so no session is ever raised for you — somebody starts every count.
- No ABC, velocity or risk class on an item, so you cannot scope a plan to "the A items, weekly". Categories are the substitute, and they are a real field that scopes both counts and variance rules — which is why the category structure advice above matters.
- No shrinkage trend report across counts. Each session holds its own variance quantity and value; a trend across sessions is an export.
The absence of a scheduler is the one that quietly kills counting programmes. A plan does not raise its own session, so cycle counting is a habit a named person owns. Put it on somebody's morning list by name, or it will happen for three weeks and then stop.
Related reading
- How to stop stock shrinkage in Kenyan retail — the five faces of shrinkage, and why counting is the instrument that finds four of them.
- Float, drops and the drawer that will not hand over — the cash equivalent, which does have a shift dimension.
- Seven sizes, one item: retail without variants — how your item list is structured decides how long a count takes.
- Running multi-branch retail in Kenya without losing control — counting across branches, and where transfers go to disappear.
See counting, freezes and variance rules
Plans, blind counts, assignments, a freeze that stops the till, thresholds that clear the noise, and approval before anything moves.
Explore inventory managementFrequently asked questions
Can we count without closing the shop?
Yes, and that is the intended way to use it. Scope a session to one category, one location or an explicit list of items, and freeze only that scope. The frozen items cannot move — including through the till — while everything else trades normally. A narrow count before opening costs nothing; a freeze over the whole warehouse at midday closes the shop, so the scoping controls exist to keep the freeze affordable.
What happens if a cashier tries to sell an item that is being counted?
The sale is refused and the cashier is told why: the stock is locked by an active inventory count session. This applies to every movement path, not just the till — receipts, issues, transfers in and out, and adjustments are all blocked for frozen items. It is inconvenient deliberately, because a count that allows movement produces a variance made partly of your own sales.
Can the person counting see what the system expects to be there?
Not in a blind count. The expected quantities are restricted for the users assigned to count them while the session is active, enforced at the visibility layer rather than just left off a form, with a separate reveal permission for supervisors who genuinely need the figure. Use blind counts as the default — a counter who can see "47" will stop counting at 47.
Do we have to review every single variance?
No, and you should not. Variance rules set a maximum absolute quantity, percentage and value, scoped by warehouse and category, and decide what auto-adjusts and what needs approval. Set generous thresholds for fast-moving low-value stock and set high-value categories to auto-adjust nothing, so review attention goes where it is worth something.
Does approving a count change stock immediately?
No. Counting proposes; applying acts. Counted lines sit as proposed variances until they are approved, either by a rule or a person, and a separate step then applies the approved lines as stock adjustments. Nothing your counters typed has moved any stock until that step runs, which is what makes a mistyped quantity a conversation instead of a movement.
Can we get stock variance per shift?
Not directly. A count belongs to a session — a time window — not to a shift, and there is no shift field on a count. This is an asymmetry inside the product: a cash drawer session is opened by a named cashier and its variance is attributed to that person, while stock has no equivalent. The workaround is one session per shift with an identical scope and the duty names in the session notes, which gives you comparable figures but not a report you can group.
Will the system remind us when a count is due?
No. Plans are reusable definitions of scope and settings, not a schedule, so nothing raises a session on a cadence — a person starts every count. This is the most common reason a cycle-counting programme lapses. Put the first count of the day on a named person's task list rather than relying on the plan existing.
