Cycle Stock Inventory Formula: The Calculation, Step by Step

The formula, in the form you'll actually use

Cycle stock is the inventory that cycles between full and empty as you sell it down and reorder more. Two formulas answer two different questions, and most pages ranking for this term only give you one of them.

• Cycle stock as a coverage figure: Cycle Stock = Average Daily Sales × Order Cycle Length (in days). This tells you how many units you need on hand to survive from one reorder to the next.
• Average cycle stock, once you're ordering in fixed quantities: Average Cycle Stock = Order Quantity ÷ 2. Inventory doesn't sit still at the coverage figure — it drains from full to zero between deliveries in the simple model, so the average across the cycle is half the peak. This is the number that shows up in holding-cost and storage-fee math.

Neither formula includes a buffer for demand spikes or late shipments. That's safety stock, and it's a separate calculation you add on top, not a variable you fold in.

Worked example, start to finish

Say a SKU sells an average of 60 units a day, and the order cycle — the full time from placing a purchase order to the replenishment landing and being sellable — runs 30 days.

Cycle Stock = 60 × 30 = 1,800 units. That's the peak: what you need in stock right after a delivery to cover you until the next one arrives.

Average Cycle Stock = 1,800 ÷ 2 = 900 units. That's the figure that ties up on the balance sheet and drives FBA storage costs on average across the cycle — not the 1,800 you ordered.

You can cross-check this against EOQ. Using annual demand of 21,900 units (60/day), an ordering cost of $300 per PO, and a holding cost of $4 per unit per year: EOQ = √(2 × 21,900 × 300 ÷ 4) = √3,285,000 ≈ 1,813 units. Average cycle stock under that policy is 1,813 ÷ 2 ≈ 906 — close to the 900 from the coverage formula, which confirms the order cycle and the EOQ roughly agree. When the two methods land far apart, one of your inputs is wrong.

Where this breaks on Amazon specifically

The order cycle length is the input sellers get wrong most, because on Amazon it's not just supplier lead time. It's production time, plus freight to port or the FBA dock, plus Amazon's own inbound processing time, plus any review buffer before the next PO goes out. Leave out the FBA processing days and the formula understates coverage — you hit zero units before the replenishment is actually sellable, and that's a stockout that kills organic rank exactly when a campaign is scaling, not a slow news day.

Overcorrect the other way — pad the order cycle out of caution — and the same formula now overstates cycle stock. Units sit longer, storage and aged-inventory surcharges accrue, and cash that could fund the next SKU is parked in one that's already moving fine.

The mistake we've made too

Across the more than $500M in managed revenue Full Circle has managed on behalf of 100+ brands, the most repeated error in cycle stock math isn't the formula — it's the order cycle input. Sellers measure it from PO placed to PO placed, not from delivery received to delivery received, and the two dates drift apart every time a shipment splits into multiple ASNs or a carrier misses a window.

We've built replenishment logic that got this wrong in an early version: it counted the reorder trigger from order date rather than landed date, and it ran cycle stock a few days short on exactly the SKUs with the longest inbound chains. The fix wasn't a better formula. It was dating the cycle from the event that actually ends it — stock landing and going sellable — not the event that starts it.

When the number comes back wrong

If your calculated cycle stock says you should be fine and you're stocking out anyway, check the inputs before you touch the formula: is average daily sales calculated over a window that includes a promotion or a lull that isn't representative now, and is the order cycle measured to sellable date rather than ship date.

If cycle stock is sitting high and the SKU isn't moving, the fix usually isn't to order less next time — it's to shorten the order cycle itself, so less capital sits idle between deliveries. Ordering more often in smaller batches lowers average cycle stock directly, provided the per-order cost of doing so doesn't eat the saving.

If ads are pushing a SKU that inventory can't currently support at the calculated cycle stock level, that's usually a timing problem in the warehouse, not a targeting problem in the account — check reorder timing before you check the campaign. If the leak is genuinely in how the ad account is spending rather than in when stock lands, that's a question for Dr. PPC, not an inventory formula.

Where Dr. Stock fits

Dr. Stock, run by Fable 5 out of Full Circle, doesn't replace this formula and doesn't run your warehouse — it's not a 3PL and it's not an ERP. What it watches is the inputs that make the formula go wrong on Amazon specifically: reorder timing against real landed dates, storage and aged-inventory fees, FBA fee errors, and reimbursement recovery on lost or damaged units, with purchasing decisions always going to a human regardless of autonomy setting. Orbit — inventory, finance, ASIN profitability, plus BSR, buy box, price and fee tracking — is included at no extra cost. There's no published price; it's a demo and a first 30 days free, priced on the call. If you're running this formula on a spreadsheet for a handful of SKUs, you don't need it. If the order cycle input drifts weekly across a catalog and nobody's checking landed dates against the calendar, that's the gap it's built for.