What Is a Cycle Count and How to Run One Without a Warehouse Shutdown

It is the Tuesday after a wholesale ship window closes. The ops lead pulls the open order report and sees fourteen units of a core style allocated to a Nordstrom PO. The 3PL says it has eleven on hand. Shopify is still showing seventeen available to sell. Someone is wrong, and the chargeback window for late shipment closes in nine days. The team spends the afternoon counting one bin, finds twelve, and now has to decide whether to short the PO, pull from DTC, or hold the truck. None of this needed to happen. The brand had not counted that SKU in eleven months.

What is a cycle count in an apparel warehouse?

A cycle count apparel warehouse program is the practice of counting a small, rotating subset of inventory on a recurring schedule, while the warehouse continues to receive, pick, and ship. It replaces the annual or semi-annual full physical inventory, which requires shutting the warehouse down for one to three days, with continuous partial counts that touch every SKU on a defined cadence. The output is a running variance report between system-of-record quantity and physical quantity, broken down by SKU, location, and reason code.

For apparel specifically, a useful cycle count is never just a SKU count. It is a count by SKU plus size plus color plus location, because that is the granularity at which an apparel brand actually sells and ships. Counting 240 units of a style across the warehouse is meaningless if the size 6 in black is short by twelve and the size 10 in cream is over by twelve. The wholesale PO does not care that the totals net out.

Why does inventory truth collapse without cycle counts?

This is breakpoint five of the 6 Breakpoints of Apparel Operations: warehouse execution gets less predictable, and the 3PL blind spot lives here. The brand has a system of record, the 3PL has a WMS, the storefront has its own inventory feed, and the wholesale platform holds allocation against committed POs. Each one drifts. Returns post late. A pick error in the 3PL goes uncorrected for six weeks. A receiving discrepancy on a 4,000-unit PO is logged as a footnote and never reconciled. Without cycle counts, none of those errors surface until the next full count, by which point the variance is large enough that nobody can explain it.

When I started Uphance, the pattern I saw repeatedly was that the ops team at a $15M brand was spending 6 to 9 hours per week reconciling inventory across Shopify, 3PL, and wholesale, and still running a 2 to 3 percent oversell rate at peak. The reconciliation hours are a tax on a missing cycle count program. If the warehouse counted on a real cadence and the variances were posted into the system of record weekly, those hours would not exist. The oversell rate would not be 2 to 3 percent. It would be closer to 0.3 percent, which is the rate at which honest receiving and pick errors occur and self-correct within a week.

What counts as a good cycle count cadence for apparel?

The right cadence depends on velocity. A core program SKU that ships every day needs to be counted more often than a seasonal piece sitting in long-tail storage. The standard framing is ABC analysis: A items are the top 20 percent of SKUs that drive 70 to 80 percent of unit volume, B items are the next 30 percent driving roughly 15 percent of volume, C items are the long tail.

For an apparel brand in the $5M to $100M band, a defensible cadence looks like this:

• A items: counted every 4 weeks
• B items: counted every 12 weeks
• C items: counted every 26 weeks
• Any SKU that hit a stockout, an oversell, or a chargeback in the last 30 days: counted within 7 days regardless of class

That last rule is the one most brands skip, and it is the one that does the most work. Stockouts and oversells are signals that the system quantity is wrong. Counting the SKU within the week catches the error before it compounds across the next ship window.

How do you run a cycle count without shutting the warehouse down?

The shutdown happens because the brand is trying to count everything at once and freeze all movement to do it. A proper cycle count program never freezes the whole warehouse. It freezes one zone, one aisle, or one set of bins for the thirty to ninety minutes it takes to count them, while picks and receipts continue everywhere else.

The operational sequence is straightforward. First, the system of record generates a count list for the day, scoped to a zone and an ABC tier. Second, the WMS or the 3PL portal locks those bin locations from picking and putaway for the count window. Third, two counters walk the zone with handhelds, scan each SKU and bin, enter physical counts, and the system flags variances above a threshold (usually 2 units or 1 percent, whichever is greater). Fourth, flagged variances get a recount by a different person before they are posted. Fifth, posted variances flow back into the system of record with a reason code: receiving error, pick error, return not posted, damage, unknown.

The reason code is what turns a cycle count from a clerical exercise into a diagnostic tool. If 60 percent of variances over a quarter are tagged as returns not posted, the problem is not the warehouse. The problem is the returns workflow. Returns should post to inventory in days, not weeks, and if your reason codes show that they are not, you have just located the breakpoint.

Who owns the cycle count when a 3PL is in the loop?

From conversations with apparel founders and ops leaders, this is where most programs fall apart. The brand assumes the 3PL is counting. The 3PL is counting, but only at the bin level and only on its own cadence, and the results never flow back into the brand’s system of record at SKU plus size plus color granularity. The brand’s WMS shows one number, the 3PL’s WMS shows another, and the variance is invisible until a chargeback hits.

The POV here is simple. The brand owns inventory truth. The 3PL operates the warehouse, but the brand owns the count cadence, the variance threshold, the reason codes, and the reconciliation back into the system of record. If your 3PL contract does not include scheduled cycle counts at SKU plus size plus color granularity, with results delivered weekly in a format your system can ingest, the contract is incomplete. This is the conversation most brands avoid because it feels confrontational. It is cheaper than the chargebacks.

For brands running multiple 3PLs or multiple warehouses, this gets harder, because the count schedules and the variance formats differ across providers. The answer is to standardize the count report format on your side and require both 3PLs to deliver into it. The brand sets the schema. The 3PLs comply.

What does a cycle count program look like inside the order and allocation flow?

A cycle count is only useful if the resulting quantity correction reaches the order and allocation systems before the next pick wave. If you count a SKU on Tuesday morning, find a variance of negative six, and the corrected quantity does not show up in Shopify or the wholesale allocation pool until Thursday, you have already oversold for two days.

This is why the cycle count needs to be wired into the same system that holds your channel-aware ATS, your wholesale-committed pool, and your DTC available-to-sell number. Counted quantity in, corrected ATS out, within the hour. If the counter writes the variance into a spreadsheet that gets emailed to the ops lead who updates the ERP on Friday, the program is generating data, not preventing oversells.

This is also where the 3PL blind spot of breakpoint five gets resolved or stays unresolved. The cycle count is the mechanism that closes the loop between physical reality in the warehouse and digital reality in the order system. Skip it and you are running on faith.

How do drops and same-day fulfillment change the cycle count math?

For a brand running scheduled drops with same-day fulfillment expectations, the cycle count cadence on drop-eligible SKUs has to compress. A drop SKU that will sell 800 units in the first four hours cannot tolerate a stale count. The week before a drop, every SKU in the drop needs to be counted, every bin location confirmed, every wave plan validated against physical quantity. This is not optional, because the chargeback cost of a missed ship promise on a drop is not just the chargeback. It is the customer who got the email, paid, and is now waiting on an order the warehouse cannot fulfill.

Same logic applies for brands with international fulfillment and duties prepaid at checkout. A short pick that triggers a partial shipment changes the duty calculation and the customs paperwork. A cycle count program that catches the variance the week before is cheaper than a customs hold the week of.

What does a cycle count program look like for a multi-entity wholesale operation?

For brands running multiple legal entities, multi-brand catalogs, or a B2B portal serving multiple buyer tiers, the cycle count problem multiplies, because the same physical inventory may be allocated across several wholesale pools and a DTC pool simultaneously. A count variance of negative four units does not just reduce available inventory. It forces a decision about which allocation pool eats the shortfall.

The rule we recommend: shortfalls get pulled from the pool with the latest ship window, not the largest pool or the highest-margin pool. The reason is operational rather than commercial. The latest ship window has the most time to recover through inbound receiving, a substitution, or a customer conversation. Pulling from the soonest ship window guarantees a chargeback. This is the kind of policy that has to be written down before the variance happens, because in the moment the team will default to whoever is shouting loudest.

What this means for an apparel operations team

A cycle count program is not a warehouse project. It is an inventory-truth project that happens to live in the warehouse. The cost of not having one is measurable: 6 to 9 hours per week of reconciliation, a 2 to 3 percent oversell rate at peak, and a steady drip of chargebacks that the team learns to absorb as a cost of doing business. None of that is necessary at the $5M to $100M scale.

The architectural fix is to wire counting into the same system that holds your orders, your wholesale allocation pool, your channel-aware ATS, and your 3PL feed, so that a counted variance flows into a corrected available-to-sell number within the hour. If those systems are separate, the cycle count generates data that arrives too late to prevent the next oversell. If they are connected, the cycle count becomes the mechanism that keeps breakpoint five from breaking.

The team that owns this is usually the ops lead, not the warehouse manager. The warehouse executes the count. The ops lead owns the cadence, the threshold, the reason codes, and the policy on which allocation pool absorbs a shortfall. Get those four things written down, scheduled, and connected to the system of record, and the annual shutdown count goes away on its own.