Cycle count vs physical count: which one, how often, and how to run each

This is a scheduling decision dressed up as a technical one. Both methods produce the same primitive — you scan real units and compare them to what the system claims — so the choice is not about accuracy per unit but about coverage and disruption. Do you true up everything at once and eat a closure, or true up a rotating slice forever and never close? The ERP and warehouse guides that rank for this question answer it for pallet racks and shift teams; below is the answer for a retail catalog running on Shopify, with the real limits of the tools you actually have.

##The two definitions, side by side

Physical count (full / wall-to-wall)

Every variant at every location, counted in one pass at a single point in time. It is exhaustive and unambiguous — one snapshot of the whole business — which is why it is the count auditors and accountants want at year end. The cost is real: to keep the snapshot consistent, stock cannot be moving, so you count with the store closed (evening, weekend, or a dedicated day) and you throw enough people at it to finish before the doors reopen. Shopify's own guidance sizes the effort honestly: roughly 500 variants is a 2–4 hour job for one person, while 5,000+ variants is several days and a team of three or more.

Cycle count (partial / rotating)

A defined slice of the catalog — one vendor, one product type, one tag, one aisle — counted on a schedule, so that over a quarter or a year the whole catalog gets covered piecemeal. No single session closes the store, because a slice is small enough to count around normal trading. Cycle counting trades the one big true-up for continuous small ones, which is what keeps accuracy from drifting between annual counts.

##Which one, when

For most retail Shopify merchants the answer is not either/or: cycle count continuously to keep day-to-day accuracy, and run one physical count a year for the accounts. The cycle counts mean the annual physical count finds a small, explainable gap instead of a year of surprises.

##A cadence you can actually adopt

The common working framework for scheduling cycle counts is ABC classification: rank variants by how much they matter — value, velocity, or shrink risk — and count the important ones more often. It is a widely used operating pattern rather than a Shopify feature, and the exact frequencies are yours to set, but a sensible starting rhythm looks like this:

Treat those cadences as a default to adjust, not a law. The value of ABC is that it concentrates your limited counting hours where a gap costs the most, so an A-class shrink shows up in weeks instead of at year end. On top of the calendar, count on triggers regardless of class:

• Before a major reorder — you are about to commit cash based on the on-hand number, so verify it first.
• After a seasonal peak — high volume and temporary staff are exactly when accuracy drifts, so reset once the rush ends.
• After any variance over 5% — Shopify's own guidance is to recount a gap that big, and a confirmed 5%+ variance in one slice is a reason to count its neighbours too.

##Running each one in Shopify

The full physical count

Shopify's built-in Quick Count is the native path, but its limits decide whether it fits: Quick Count is POS Pro only, handles up to 1,000 variants per session, and does not schedule recurring cycle counts. If you are on POS Pro and your catalog fits under 1,000 variants a session, Quick Count on a POS device is the simplest full count. Past that — no POS Pro, more than 1,000 variants, or multiple people counting at once — you run the full count through the admin or a counting app that paginates the whole catalog server-side and lets several devices count the same session without a per-session ceiling.

The filtered cycle count

A cycle count is a full count with a filter in front of it. Instead of the whole catalog, you scope the session to a slice — one vendor, one product type, one tag, one collection — and count only that. Whatever tool you use, the mechanics are the same as a physical count on fewer lines: scan each unit once, exclude drafts and archived products, and reconcile anything that sold mid-count. The filter is the whole trick; it is what turns an unmanageable wall-to-wall count into a short slice you can run on a Tuesday morning without closing.

##Doing this with Solvi Stocktake

Solvi Stocktake runs both patterns from one place, without POS Pro and without the 1,000-variant ceiling. A full count paginates the whole catalog server-side and persists every scan the instant it happens, so a session survives thousands of variants and multiple counters instead of resetting after a hundred. A cycle count is the same session scoped by vendor, product type, tag, collection, or status — pick the slice, open the session, start scanning. Because each scan captures the on-hand at that moment, counting while the store is open and selling is safe: lines whose Shopify stock moved after they were scanned get flagged to re-verify rather than silently overwritten. Scheduled cadence reminders on the Growth plan close the native gap — the app tells you when a slice is overdue instead of you tracking it in your head. Free covers two counts a month; Starter is $9; Growth is $19 with cost valuation and cadence reminders.

Same primitive either way — scan real units, compare to the system, review before anything is written. The only difference is whether the filter is set to 'everything' or 'this vendor'.