Forecasting Returns for Inventory Planning

Most inventory systems treat a return as a surprise. A unit that was sold, counted as gone, and written out of available stock suddenly reappears on a receiving dock, and the system scrambles to slot it back in as if it had fallen from the sky. But a return is one of the most forecastable inbound flows a retailer has. You already know exactly what shipped, when it shipped, and how that category tends to behave. Returns are not random noise landing on your warehouse; they are future inbound supply arriving on a schedule you can predict weeks ahead, if you bother to model it.

The return-lag curve

The foundation of any returns forecast is the return-lag curve: the distribution of how long after delivery a return actually gets initiated. Returns do not happen at the moment of purchase, and they do not happen uniformly. For most apparel and general merchandise, the curve is front-loaded and long-tailed. A large share of returns start within the first one to two weeks after delivery, then a thinning tail runs out to the edge of your return window. The exact shape varies by category: considered purchases like furniture lag longer, impulse apparel returns faster. Your return window length is the hard cap that truncates the tail, which is why a 30-day window produces a tighter, more predictable curve than a 365-day one, and one more reason window length is an operational decision and not just a marketing one.

The practical power of the lag curve is that it lets you convert a shipment cohort into a return schedule. If you shipped 1,000 units of a SKU in a given week, and history says that SKU's category returns at 22% with 60% of those returns initiated within 14 days, you can already sketch how many units come back in each of the next several weeks. Do that across every cohort currently inside its return window and you have a forward curve of expected returns, not a single blended rate but a week-by-week inbound schedule.

A forecasting method you can actually build

You do not need a machine-learning model to start. The first useful returns forecast is arithmetic, and it beats the implicit forecast of zero that most planning systems run on today.

1. 1Start with units shipped by SKU and week, which you already have.
2. 2Multiply by a return rate, ideally at SKU or narrow-category level rather than one company-wide number, since return rates vary enormously by category.
3. 3Spread the result across future weeks using the return-lag curve for that category, so the forecast lands as a schedule rather than a lump.
4. 4Apply a resalable share, the fraction that comes back Grade A or B and can re-enter sellable stock, to separate future sellable supply from units bound for liquidation or refurbishment.
5. 5Layer seasonal and gift adjustments last, because the holiday peak bends both the rate and the lag curve at once.

Refine from there only where it pays. The biggest accuracy gains come from segmenting the return rate and the lag curve by the dimensions that genuinely move them, category, price band, channel, and whether the order was a gift, not from a more sophisticated algorithm applied to one blended rate. A simple model on well-segmented inputs beats a complex model on averaged ones almost every time. Track forecast error the same way you track any other operational metric, alongside the returns metrics that matter, so the forecast earns trust before anyone plans against it.

What a returns forecast actually changes

A returns forecast is only worth building if it changes a decision, and it changes at least three. The first is available-to-promise. Expected resalable returns are future sellable inventory, and a planning system that ignores them will over-order replenishment for any SKU with a heavy return flow, buying units you are about to receive back for free. If you know 180 units of a fast-returning style are coming back Grade A over the next two weeks, some of your replenishment purchase order is redundant, and some of your out-of-stock risk is already covered.

The second is markdown timing. A SKU with a wave of returns about to land has more effective supply than its on-hand count suggests, and marking it down on the on-hand number alone can leave you flooded once the returns arrive. Conversely, a return wave hitting an already-soft seller is a signal to mark down sooner, before the extra units pile up. The third is restock and recommerce capacity: an inbound return wave is a staffing and processing forecast, not just an inventory one. Knowing a peak of returns is three weeks out lets you schedule the grading line and the recommerce routing for it, instead of discovering it when the dock backs up. Supply-chain planning groups such as Gartner have long framed reverse flows as a planning input on equal footing with forward demand, precisely because the two share the same warehouse, the same labor, and the same shelf.

Returns are not a surprise landing on your dock. They are inbound supply arriving on a schedule you already have the data to predict.

The peak-season case, where forecasting pays most

The single highest-value place to run a returns forecast is the holiday peak, because that is where every variable moves at once and the cost of being wrong is highest. Gift returns lag differently from self-purchases; a November gift order may not come back until the first week of January, well after it was delivered, so the lag curve stretches and the January inbound wave is far larger than a naive rate would suggest. A peak-season playbook that forecasts the January return surge from the November and December shipment cohorts lets you staff receiving, pre-position grading capacity, and plan liquidation channels before the wave lands, rather than triaging it in real time. The forecast does not make the returns smaller. It makes them expected, and an expected surge is a capacity plan instead of a crisis.

This is where structured returns data stops being a reporting nicety and becomes a planning input. A forecast is only as good as the return-rate and lag data underneath it, and that data has to be captured cleanly, per SKU, with reliable timestamps, to be worth modeling. The returns intelligence layer we build into ResReturn exists partly for this, clean per-SKU return rates, reason codes, and timestamped lifecycle events that a planning team can pull a lag curve and a resalable share from directly, instead of reverse-engineering them from a payments export that never recorded when the item actually came back.

• Model the return-lag curve, days from delivery to return initiation, per category rather than one blended average.
• Convert shipment cohorts into a week-by-week inbound return schedule, not a single quarterly rate.
• Separate resalable returns (Grade A and B) from the rest, because only that share counts as future sellable supply.
• Feed the forecast into available-to-promise, markdown timing, and grading-line staffing, the three decisions it actually moves.
• Build the holiday forecast from the gift-heavy November and December cohorts, since their return wave lands weeks later and larger than a flat rate implies.