Three Reasons Your Replenishment Triggers Misfire in Apparel

A planner at a $15M contemporary brand pulls the Monday replenishment report. Six core SKUs have tripped the reorder trigger. She places the PO with the factory in Portugal, eight weeks out. On Wednesday, the wholesale team confirms a 1,200-unit Nordstrom reorder that was sitting in a quote, not a sales order. Two of the six SKUs she just ordered are now short for the wholesale commit, and three of the other four were tripped by a returns batch the 3PL had not yet posted, units that were physically in the building but invisible to the system. By Friday she is on the phone trying to expedite air freight on goods she did not actually need to reorder, while explaining to the wholesale director why a confirmed PO is going to ship partial.

This is a replenishment trigger apparel teams set with good intentions and watch misfire inside six weeks. The rule is not the problem. The data underneath the rule is the problem.

What is a replenishment trigger in apparel, and why is it harder than it looks?

A replenishment trigger is an automated rule that flags a SKU for reorder when sellable on-hand inventory crosses a threshold, calculated from forward demand over the supplier lead time plus a safety buffer. In a single-channel DTC business with one warehouse and a domestic supplier, the math is tractable. You know what you have, you know how fast it sells, and you know when the next batch arrives.

Apparel breaks all three inputs. On-hand is split across a 3PL, a wholesale-committed pool, in-transit containers, and returns in various states of disposition. Forward demand is not a smooth curve because drops, markdowns, and wholesale reorders create spikes that look nothing like the trailing four weeks. Lead time is not a number, it is a distribution, because factory capacity, fabric availability, and ocean freight move independently of your plan.

When I started Uphance, the pattern I saw repeatedly was operators trying to solve a replenishment problem at the rule layer when the issue was three layers down, in the inventory truth itself. This is Breakpoint 3 of the six breakpoints of apparel operations, and it is where most $10M to $20M brands lose the plot.

Reason one: your on-hand number is not a sellable number

The single most common reason a replenishment trigger misfires is that the system is comparing the threshold against gross on-hand, not against sellable on-hand. Those are different numbers in any brand running wholesale and DTC simultaneously.

Consider a SKU sitting at 800 units in the 3PL. The trigger threshold is 400. The system says you are fine. But 350 of those units are allocated against an open wholesale PO shipping in two weeks. Another 90 are on a held order for a marketplace integration that has not pushed the deduction yet. Your real sellable position is 360, and you should have reordered three weeks ago.

The inverse misfire is just as common. A SKU shows 280 on-hand, below the threshold, and the system fires a reorder. But 150 of the apparent shortfall is a returns batch that was received at the 3PL on Tuesday and has not yet been graded, restocked, and posted back into available inventory. Returns should post to inventory in days, not weeks. When they take three weeks, the replenishment engine is making decisions against a version of reality the warehouse has already moved past.

For a $15M brand running wholesale, DTC, and a 3PL, we see operators spending six to nine hours a week reconciling inventory across Shopify, the 3PL portal, and the wholesale system, and still running a 2 to 3 percent oversell rate at peak. That reconciliation work exists because no single number in any of those systems is the sellable number. The replenishment trigger inherits that ambiguity and amplifies it.

The fix is not a better rule. The fix is a single inventory ledger with channel-aware available-to-sell, where wholesale commitments, in-transit, and returns-in-process are first-class states, not afterthoughts reconciled in a spreadsheet every Monday morning.

Reason two: your demand signal is contaminated by drops and returns lag

The second reason replenishment triggers misfire is that the demand input is wrong, and it is wrong in a way that is specific to how apparel sells.

Most replenishment engines compute forward demand from a trailing velocity, typically four or eight weeks of unit sales. In a category with steady weekly throughput, that works. In apparel, the trailing velocity is corrupted by three structural patterns.

The first is the drop spike. From conversations with apparel founders and ops leaders, the pattern I hear most often is a team treating the first 72 hours of a drop as a baseline, when it is actually a discontinuity. A SKU that sold 400 units in the launch weekend and is now selling 12 a week is not a 400-unit-per-month SKU. The replenishment engine, fed raw weekly velocity, will either over-trigger immediately after launch or under-trigger six weeks later when steady-state demand has settled and the trailing window still includes the spike.

The second is the wholesale reorder. A buyer at a department store places a reorder for 600 units of a single SKU on a Tuesday. If that PO drops into the same demand bucket the DTC velocity is computed from, the engine reads a 600-unit week and projects forward as if next week will look the same. It will not. Wholesale demand is lumpy and contractual. It belongs in the commitment layer, not the velocity layer.

The third is the returns lag. A SKU shows strong sell-through for three weeks, then a wave of returns hits the 3PL in week four and five. If returns are netted against sales in the demand calculation but posted late to inventory, the engine sees demand collapsing while on-hand stays flat, and triggers go quiet exactly when you should be planning the next buy.

The POV here is direct. A replenishment trigger that treats DTC velocity, wholesale commitments, and returns as a single blended demand number will misfire in every season. Separate them. Wholesale demand is committed, known, and dated. DTC velocity should be computed on a windowed basis that excludes the first two weeks post-drop. Returns should be modeled as a forward liability against gross sales, not netted retroactively.

Reason three: lead time is a distribution, not a number

The third reason is that the lead time input in most replenishment configurations is a single number, usually the supplier’s quoted lead time at the start of the season. Real lead time is a distribution shaped by factory loading, fabric availability, QC holds, freight booking windows, port congestion, and customs.

A factory that quotes 60 days in January is quoting against a capacity plan that assumes you place orders by week three. Place the same order in week eight when the factory has loaded another brand’s spring production, and the real lead time is 85 days. The replenishment engine, still calculating against 60, will tell you that you have eight weeks of cover when you actually have four.

Ocean freight adds another layer. A container booked on a Tuesday for a Friday sailing is on a different timeline than a container that misses the cutoff and rolls to the next vessel. In a normal year, the rolled container costs you eight days. In a constrained year, it costs you three weeks. The trigger does not know.

The operational fix is to maintain a lead time per supplier per season per category, updated against actuals, and to compute reorder points against the 75th or 85th percentile of that distribution rather than the mean. For a core program SKU where stockouts are expensive, run the trigger against the 90th percentile. For a fashion SKU where overbuying is more painful than a brief stockout, run it against the 50th. The choice is a margin decision, not a default.

This is also where the critical path matters. If your PLM is tracking actual milestone slippage against the time-and-action calendar (fabric in, sample approved, bulk cut, finishing, ex-factory), you have empirical lead-time data per supplier that the replenishment engine can consume. Most brands at the $10M to $20M band have this data sitting in a spreadsheet that no system reads.

Why these three failures compound

Each of these three misfires is bad alone. Together they produce the pattern the planner in the opening scene was living through. The on-hand number was wrong because returns had not posted and wholesale commits were invisible. The demand signal was wrong because a drop spike was in the trailing window. The lead time was wrong because the factory had quietly slipped from 60 to 75 days and nobody had updated the supplier record.

The replenishment trigger fired anyway, because rules do not know they are running on bad inputs. The planner placed the order, and by Wednesday she was unwinding it.

When brands in the $5M to $100M band try to fix this, the instinct is to add a tool. A demand planning bolt-on, a returns management app, a 3PL portal layer. That stack typically replaces 3 to 5 tools plus spreadsheets with 3 to 5 different tools plus different spreadsheets, and the FTE who was doing data plumbing is still doing data plumbing, just against a different set of CSV exports.

The architectural answer is that inventory truth, channel allocation, returns disposition, and supplier lead time history all need to live in the same operational ledger. Replenishment is the output, not the input. You cannot tune the output until the inputs agree.

What this means for an apparel operations team

If your replenishment triggers are misfiring, do not start by adjusting the rule. Audit the three inputs in order. First, can you produce a sellable on-hand number for any SKU that already nets wholesale commitments, in-transit, and returns-in-process, without anyone exporting anything? If the answer is no, the rule cannot be right because the input is not right.

Second, is your demand calculation separating committed wholesale orders from DTC velocity, and is it excluding the drop window from the trailing average? If not, your engine is reading a blended signal that does not describe any single channel accurately. Third, are you updating supplier lead times against actuals, or against the quote at the top of the season? A trigger calibrated against the season-opening quote will be wrong by week six in a normal year and wrong by week three in a constrained one.

The planner does not need a smarter rule. She needs the three numbers underneath the rule to be true at the same time, which is what an inventory truth layer is supposed to deliver and what spreadsheets, by their nature, cannot.