How to Run a Retail Stock Take: Full Count vs. Cycle Counting, Step by Step

A retail stock take is a physical count of the inventory you actually have on hand, compared against what your system says you should have. You do it by counting every unit (a full physical inventory count) or a rotating subset of your catalog on a schedule (cycle counting), recording the counted quantity against a barcode scan or SKU list, then calculating the variance between counted and recorded stock so you can fix the records and investigate the gaps. Most independent and multi-location retailers use a mix of both: a full count once or twice a year, cycle counts every week or month in between.

What exactly is a stock take, and why does it matter?

A stock take (physical inventory count) is the process of physically verifying on-hand quantities against your recorded inventory to identify and correct discrepancies. It matters for three reasons that have nothing to do with satisfying an accountant: it catches shrinkage before it compounds, it fixes the bad data that causes overselling and stockouts, and it's the only way to trust your reorder points. A reorder point built on inventory records that are 8% off in real life will trigger the wrong purchase orders every time, no matter how good the forecasting math is behind it.

If you've never counted your inventory, assume your system is wrong somewhere. Receiving errors, unscanned returns, theft, breakage, and staff mis-picks all silently erode accuracy over time, even in stores with a good point of sale. A stock take is how you find out how wrong, and where.

Full physical inventory count vs. cycle counting — which one should you run?

These are two different tools for the same job, and most retailers need both.

• Full physical inventory count: every SKU, every location, counted in one coordinated event — usually after close, overnight, or during a scheduled shutdown. Gives you a complete, point-in-time accuracy snapshot. Labor-intensive and disruptive, so it's typically done once or twice a year (often for year-end accounting or insurance purposes).
• Cycle counting: a defined slice of inventory — a category, a section of the store, or your highest-value SKUs — counted on a rolling schedule (daily, weekly, or monthly) without closing the store. Spreads the work out, catches errors faster, and keeps counts fresh year-round.
• ABC cycle counting: the most common cycle-count method. Rank SKUs by dollar volume or sales velocity into A (top ~20% of value, count monthly), B (count quarterly), and C (count once or twice a year). This puts counting effort where the financial risk actually is instead of treating a $3 SKU the same as a $300 one.

The trade-off is simple: full counts give you total accuracy but cost you a closed day or an overnight labor bill. Cycle counts give you continuous accuracy with much less disruption, but you're never counting everything at once, so systemic problems in low-priority SKUs can hide longer. Retailers running multiple locations especially benefit from cycle counting, because a full count across every store on the same night is a logistics project, not a Tuesday task.

How do you prepare for a physical inventory count?

Bad prep is the number one reason stock takes run long and produce untrustworthy numbers. Work through this before count day:

• Freeze receiving and transfers during the count window, or log every movement that happens mid-count separately so it doesn't get double-counted or missed.
• Process all pending transactions first — finish any open sales, receive any POs sitting in a truck, and complete any transfers in transit so your starting numbers reflect reality.
• Print or verify barcode labels on every SKU you're counting. Anything unlabeled turns into a manual lookup that slows the whole crew down.
• Assign zones and owners — split the sales floor, stockroom, and backstock into sections with one counter (or a counter-and-checker pair) per zone so nothing gets counted twice or skipped.
• Decide on blind counts. A blind count sheet (no expected quantity shown) forces staff to count what's actually there instead of confirming what the system says — it's slower but far more accurate, the same principle used in cash drawer reconciliation.
• Stage a recount plan for anything with a large variance, so you're not guessing whether it's a counting error or real shrinkage.

How do you actually run the count, step by step?

This is the same core sequence whether you're doing a full count or a cycle count — the only difference is scope.

• 1. Lock the scope. Define exactly which SKUs, categories, or zones are in this count. For a cycle count, this comes from your ABC schedule; for a full count, it's everything.
• 2. Close out open transactions. Finish sales, receive open purchase orders, and settle in-transit transfers so the count reflects a clean snapshot.
• 3. Scan or count each SKU by location. Use a barcode scanner against each item's barcode rather than typing SKUs manually — manual entry is where most counting errors come from. GS1 barcode standards exist for exactly this reason: consistent, scannable identifiers reduce miskeys.
• 4. Record quantity per bin or zone, not just a store-wide total. A total-only count tells you *that* something's wrong but not *where* — zone-level counts make root-causing shrinkage possible.
• 5. Enter counts against the system's expected quantity to generate a variance report automatically, rather than reconciling by hand in a spreadsheet.
• 6. Recount anything above your variance threshold (many retailers use a rule like ±2 units or ±$25 of cost, whichever is larger) before accepting it as real.
• 7. Post adjustments once variances are confirmed, so on-hand quantities reflect the physical count and every adjustment leaves an auditable record of what changed and why.
• 8. Unfreeze operations — resume receiving and transfers once counts are posted.

How do you calculate and interpret inventory variance?

Inventory variance is the difference between the quantity your system says you have and the quantity you physically counted, expressed as units or dollars. The formula: Variance = Counted Quantity − Recorded Quantity. A negative variance means you have less than the system thinks (shrinkage, unrecorded sales, or damage); a positive variance means you have more (usually a receiving or return that wasn't logged).

To judge whether your inventory is healthy, calculate a count accuracy rate: Accuracy % = (SKUs with zero or acceptable variance ÷ total SKUs counted) × 100. A well-run store with a real point of sale and disciplined receiving typically runs in the mid-to-high 90s. If you're seeing accuracy in the 80s or lower, don't just fix the numbers — dig into the pattern:

• Is variance concentrated in one category or one location? That points to a process problem there, not random loss.
• Are variances mostly negative (missing stock) or split between positive and negative? Mixed variance often means data entry or receiving errors rather than theft.
• Are high-value or high-theft SKUs (see our guide to retail shrinkage and cycle counting) driving a disproportionate share of the dollar variance even if unit counts look fine?
• Does the variance show up right after a specific event — a new hire, a POS outage, a vendor switch — that narrows down the cause?

How often should you count — and does it change by store type?

There's no universal number, but a workable default for most independent and multi-location retailers is: full count once or twice a year, A-category cycle counts monthly, B-category quarterly, C-category once or twice a year on a rotating basis. Adjust from there based on risk:

• High-shrinkage categories (small, high-value, or easily concealed items) warrant more frequent counts regardless of ABC tier.
• Stores with high staff turnover should count more often — new staff are more likely to make receiving and scanning errors.
• Multi-location retailers should stagger cycle counts across stores rather than syncing them, so your inventory reports always have recently-verified data from at least some locations to compare against.

How does Retailer OS handle stock takes and variance?

Retailer OS is built to run counts against the same live inventory record your point of sale and online store already use, rather than a separate spreadsheet that goes stale the moment someone rings a sale.

• Per-item, per-location stock with a full movement ledger — every sale, transfer, receipt, and adjustment leaves an audit row, so when a count comes back off, you can trace exactly what happened to that SKU since the last count instead of guessing.
• Barcode scanning and label printing for fast, accurate counting on the floor — count against the same barcodes your team already scans at checkout.
• Inter-location transfers with in-transit tracking, so stock moving between stores or a warehouse doesn't get miscounted as a variance in either location.
• One shared, real-time inventory number across every store, warehouse, and stockroom — critical for multi-location retailers running staggered cycle counts, since every location's count posts to the same source of truth.
• Reorder points, par levels, and AI-assisted reorder suggestions (the suggestions come with an AI plan) that get more accurate the moment a stock take corrects the underlying on-hand numbers — a count isn't just cleanup, it's what makes your replenishment trustworthy again.
• Stock counts with system, counted, and variance side by side, by location, so each zone or category you count lands in the system as a recorded variance instead of a clipboard tally — one of the daily store routines Retailer OS runs.

Because inventory, POS, online store, and marketplace sales all run on the same catalog in Retailer OS, a count you run today reflects every channel you sell through — not just what happened at the register.

For a broader look at keeping inventory accurate across multiple stores between stock takes, see our guide on multi-location inventory without spreadsheets, and if shrinkage is driving your variance, our retail shrinkage and cycle counting guide breaks down the specific causes and fixes.