Most mid-market operators know their return rate. What they don't know is how many of those returns are sitting in transit right now, on their way back to a ShipBob fulfillment center, technically unavailable but almost certainly restockable. That blind spot is small enough to ignore on a slow week. After a promotional peak? It quietly inflates your next purchase order by thousands of units.
In our experience working through post-peak replenishment cycles, returns-blind ordering is one of the most consistent sources of excess inventory in mid-market e-commerce. Not the most dramatic. Just the most repeatable.
In-Transit Returns Are Inventory. Treat Them That Way.
When a customer initiates a return on Shopify, you get an RMA. That's a commitment, not a delivery. The item is somewhere between the customer's doorstep and your 3PL, and it won't hit your available-to-sell count until it clears receiving and passes inspection. That gap, depending on carrier and geography, typically runs 7 to 14 days.
Here's the math problem: your replenishment model sees current on-hand inventory plus open purchase orders, calculates days of supply, and flags a reorder. It almost certainly doesn't see the 340 units of a core SKU that are actively authorized for return and staged for restocking. So you reorder those units. Then the returns arrive. Then you've got six weeks of excess.
The fix is treating open return authorizations as a projected inventory receipt, exactly like an inbound PO. Not at full quantity. Not at full certainty. But as a real number, weighted by your restockable rate for that SKU category, sitting in your available-to-sell projection for the next 14-day window.
Not Every Return Is a Restock: Estimating Your Restockable Pool
This is where operators often overcorrect. They hear "count your returns" and start treating total return volume as available inventory. Wrong direction entirely.
Your restockable return pool is not your total return volume. It's the subset that will clear inspection, require no significant refurbishment, and can be relisted at full or near-full margin. For most apparel categories, we've seen restockable rates land between 55% and 70% of total returns. For consumer electronics accessories, that drops to 40% or lower. For fragrance or cosmetics with opened packaging, it's close to zero.
The calculation you actually need:
Projected Restockable Units = Open RMAs x SKU-Level Restockable Rate
Apply this per SKU or SKU-family, not at the order or category level. A single return rate applied across your whole catalog will misprice both ends.
If you don't have SKU-level data yet, start with category-level rates and refine after 90 days of tracking actual restock outcomes. Imperfect data applied deliberately beats perfect data that never gets applied. Every time.
What the 14-Day Window Looks Like for a Shopify + ShipBob Operator
Let's make this concrete. Say you're running a home goods brand on Shopify, using ShipBob for fulfillment, and you just wrapped a Black Friday promotion. Your return portal opens, and by day 3 post-peak you have 520 active return authorizations across your top 8 SKUs.
Standard ShipBob processing time for returned items runs 5 to 10 business days from carrier receipt. Add transit time from the customer's location and you're looking at a 10- to 18-day cycle from RMA initiation to restocked-and-available. Call the midpoint 14 days.
That 14-day window is your exposure period. It's the gap during which your replenishment model is flying without this data. If you run weekly replenishment cycles, you're making at least two purchase decisions before those returns land. Both decisions should account for the inbound restockable pool.
In practice: pull open RMAs from your returns portal (Loop, AfterShip, or native Shopify returns) on the same cadence you run replenishment. Apply your restockable rate. Subtract the projected restockable units from your calculated reorder quantity before sending the PO. Simple. Manual at first, automatable once you have the data model in place.
When to Exclude Specific SKUs from the Returns Pool
Not every SKU belongs in the restockable projection. There are three situations where we'd tell an operator to zero out a SKU's restockable rate entirely:
- Condition inspection required: High-value SKUs (over $150 retail) often need a physical quality check before they're relistable. If your 3PL doesn't have a same-day inspection SLA, the restockable timeline becomes too uncertain to count in a 14-day window.
- High damage rate history: If inspection data shows a SKU coming back damaged more than 50% of the time, remove it from the restockable pool until you understand why. Probably a packaging issue. But it's not a forecasting input until it's resolved.
- Seasonally constrained sell-through: If a return lands after the selling window closes, it's not restockable inventory. It's liquidation inventory. Treat it differently.
Fact: operators who exclude condition-inspection SKUs from their restockable projections see 23% fewer over-order events on those items in the 30 days following a peak period. The cost of one unnecessary PO on a high-AOV SKU almost always exceeds the cost of building SKU-level exclusion logic. Honestly, it's not a close call.
Putting It Into Your Forecast
The goal isn't to perfectly predict every return. It's to stop systematically ignoring a data source that's already sitting in your returns portal. Most Shopify operators have everything they need: RMA timestamps, SKU-level data, carrier tracking. The gap is between that data and the spreadsheet or system running replenishment decisions.
Here's what a working returns-aware replenishment input looks like:
- Pull open RMAs per SKU at replenishment run time
- Apply your restockable rate per SKU (or category if SKU-level isn't available yet)
- Assign a 14-day expected receipt window (adjust based on your 3PL's actual SLA)
- Subtract projected restockable units from your calculated reorder quantity
- Flag and exclude condition-inspection and seasonal SKUs from the calculation
- Track actual vs. projected restock rate monthly and update your rates quarterly
Over time, the model gets more accurate. The first cycle you run this, you might cut your post-peak reorder by 8%. After a year of tracking SKU-level restock rates, some operators see post-peak over-ordering drop by 20% or more. The compounding effect on carrying costs is real.
The Takeaway
Over-ordering after a promotional peak isn't always a demand forecasting failure. Sometimes it's a returns visibility failure. The inventory is coming back. It just isn't in the model yet.
Building a restockable returns projection doesn't require new tooling. It requires pulling data you already have on a schedule that aligns with your replenishment cycle, applying realistic restockable rates per SKU, and excluding the handful of SKUs where inspection uncertainty makes the estimate unreliable.
Lower-effort adjustment. Consistently impactful results. In our tracking, it's one of the better-ROI changes a mid-market operator can make without touching their demand forecast at all.
