How counting works
A count task covers one location — either the whole location, or, when it's raised against a single variant, just that one line. Counting works the same way on sites using simple or advanced locations, and it needs no freeze: the rest of the warehouse keeps working while a count is open.
What raises a count task
Six things can raise one:
- The overnight coverage schedule, which queues the most overdue storage locations each morning. It runs on every site counting is offered on — warehouse and shop alike — and never queues a receiving, dispatch, in-transit or virtual location.
- A person creating one directly.
- Two one-tap prompts on the pick run screen, offered when a location looks low or empty straight after a pick.
- An automatic signal when a pick comes up short. This does not fire when a picker records a pick of zero — a zero pick can't be confirmed at all, so the commonest kind of short pick, an empty location, never raises a count this way.
- A recount, raised from the review queue against a single variant.
The snapshot and the rebase
Expected quantities are captured the moment a count task is claimed — that's the snapshot. Because the warehouse doesn't stop, stock can keep moving at that location while the count is open, so at submission every line is re-based against anything that moved since the snapshot. This is why counting needs no freeze: the comparison is always against what should be there right now, not against a stale figure from when the task was opened.
The tolerance gate
A variance posts automatically only if it is within both the quantity tolerance and the value tolerance:
- The quantity tolerance is a plain unit count.
- The value tolerance is the variance multiplied by the variant's weighted average cost.
If the variant has no average cost on file, the line always goes for review — an unknown cost can't prove the value tolerance, so it queues rather than posting blind. A weighted average cost of exactly zero is different from having no cost on file: a zero cost passes the value check outright, so a variance on that variant auto-posts as long as it's within the quantity tolerance alone.
Anything outside tolerance waits in the review queue rather than posting. See review count variances for what happens there.
Reaching Posted doesn't always mean stock changed
A count task reaches Posted once every line on it has been resolved — not once stock has actually moved. If every line that went to the review queue is rejected, the task still reaches Posted with nothing changed in stock.
Blind counting
Blind counting is on by default: the person counting doesn't see the expected quantity while they're entering what's physically there. It changes what the counter sees, not the gate itself — a blind count is still measured against the same tolerances once it's submitted.
Coverage
Storage locations are ranked by how long it's been since they were last counted, and the schedule queues the most overdue ones each morning up to a daily budget. The same ranking is what the Counts due card shows, over the same sites: every countable site, warehouse and shop alike. The clock for a location resets when a count against it is submitted, not when it's later reviewed — so a location can look freshly counted even while a variance from that count is still waiting in the queue.
Receiving, dispatch, in-transit and virtual locations are never ranked as overdue and never queued, because what sits in them is passing through rather than stored.
A site using simple locations gets scheduled counts too. Because a never-counted location ranks first, its single main location is typically the first thing the schedule queues.
Locations counting leaves out
Four location types are left out wherever Yessort works out a list of locations for you — the Counts due ranking, the overnight coverage schedule, and a count session scoped to a whole site, to a zone, or to every location holding one SKU:
| Location type | What it holds |
|---|---|
| Receiving | Inbound goods staged after a goods receipt, waiting to be put away. |
| Dispatch | Outbound goods staged before they leave the site. |
| In transit | Units a transfer has dispatched that the destination hasn't received yet. |
| Virtual | Stock held somewhere non-physical. |
Yessort creates these locations for itself, and their contents are mid-flow by definition, so counting one tells you nothing about how accurate your stock is. An in-transit location is worse than uninformative: the units there are the ones a transfer is still accounting for, so a variance posted against it would corrupt the transfer's own record of what has been dispatched but not yet received.
You can still count one of them deliberately. New count and Count now raise a task against the location you name, whatever its type, and a count session given an explicit list of locations uses that list exactly as given.
Tolerances and coverage are set per organisation
The quantity and value tolerances above, and the coverage schedule's daily budget, are all configured once per organisation, not per site — every site works to the same numbers.
Where counting applies
Counting is offered on every site that holds its stock in locations — warehouse and shop sites alike. Virtual sites are the only ones left out: they hold stock at site level rather than in locations, so there is nothing there to count. Counting is a web screen only — there is no offline or phone version.
A shop site is created with a single main location and is normally left that way, so counting a shop usually means counting that one location. Everything else on this page applies to it unchanged: the same snapshot and rebase, the same tolerances, the same review queue — including the overnight coverage schedule, which ranks and queues a shop's location exactly as it does a warehouse bin.
The one narrowing is shared sites: the schedule only queues counts on sites your organisation runs alone. On a site shared under a facility operator, locations are still ranked on the Counts due card and can be counted from a Counts due group, from New count, or in a count session — but a count is never raised against one automatically.
If no countable site is visible to you — because your organisation has none, or because none is in your site access — the Counts due card says exactly that rather than reporting coverage it can't have.
Count sessions
A count session is a named batch of count tasks — for example, a group of locations counted together in one sweep — kept only for tracking progress: how many of its tasks are done, and how many are left. A count session can't be opened, completed or cancelled from the app; once created, it just sits there as a running tally of the tasks inside it.
A different system for shared warehouses
If your organisation shares a warehouse with others under a facility operator, discrepancies at the shared locations there are reconciled through a separate system, not through counting — see count a commingled bin. That system only appears for the organisation operating a shared site — on a site your organisation runs alone, counting is what you use.
Posting a count variance at a location that also holds another organisation's stock of the same shared anchor is blocked, whichever organisation is counting. That stock is reconciled through the operator's commingled count instead, not through an ordinary count here.
To work a count task, see count a location.