Sizing the last order you'll ever place for a SKU

A final buy has a finish line, not a horizon

Replenishment is sized against a moving edge: cover the next N days, then order again. The order only has to reach an edge that keeps retreating.

A final buy is sized against a finish line. Procurement calls it a last-time buy, a lifetime buy, or an all-time buy; the stock it produces is run-out stock, bought with the explicit intent that it end. It has to carry you to a fixed calendar date and stop.

That inverts what a good number looks like. In replenishment, a healthy cover level is success and a little leftover is a rounding error next month absorbs. In a final buy, cover past the date is meaningless, and every unit of buffer is one you'll still own the morning after: safety stock stops protecting you and starts converting, one for one, into residual.

Forecast to the date, and let the window shrink

A replenishment forecast is a rolling question: always the next thirty days, re-asked at the same width. A final-buy forecast is a countdown — the window is days-until-discontinuation, and it shrinks every week you deliberate. A number computed a fortnight ago is wrong by a fortnight, in the expensive direction.

So the window has to be a setting, not an assumption. Assisty forecasts what each product — and each variant — will sell over the horizon you choose: point it at the days you actually have left, and recompute as the date closes in. Do it at the grain you buy at — buying decisions happen at variant level, so do the forecasts, and a dying product rarely dies evenly.

Then argue with the baseline, because phase-out demand isn't a flat continuation of trailing velocity — it shrinks, gets irregular, and ends in a sharp drop-off. Clean the history first: days you were out of stock can be excluded, so the forecast reflects real demand rather than the days you couldn't sell. Then put the decline to the what-if box and watch the forecast and the reorder needs recompute in front of you. Ask why demand is moving, too — Atlas explains the drivers, telling fading demand from a stock gap, which is what says whether the tail has started.

Subtract everything that's already on its way

final order = forecast demand to the end date − on hand − units on open POs ± your leftover tolerance

The Smart Buying Table already shows this arithmetic line by line. A suggestion is computed from your sales velocity, lead times, and incoming stock, and the breakdown shows the demand over the cover period, minus incoming from open POs, minus on hand, arriving at a suggested order. The breakdown reads the same way whichever demand number sits on the top line; for a final buy, that top line is the one you forecast to the date.

The line that ruins final buys is incoming. Units already moving on an ordinary replenishment cycle are part of the final buy whether anyone intended them to be, which is why phase-out planning reviews open POs and supplier commitments alongside the final quantity, not after it. A shipment that exists in an email thread and not in the system doesn't get subtracted, and you buy the tail twice.

Decide what happens to the tail before you place the order

Residual disposition is a choice among named routes — markdown, bundling with current products, an alternate channel, liquidation lots, write-off — and the recovery you expect from the route you pick sets how much leftover you can tolerate. Units you can clear at a planned price step are a cost; the same units with nowhere to go are a write-off. The difference is a decision made before ordering, not after.

Decide first because rounding manufactures a residual whether or not you've chosen: suggestions get rounded to your case sizes and capped at your maximum stock levels, and a supplier who only sells in minimums pushes the same way. If the route is a markdown, fix the ladder now: price steps scheduled before the goods need clearing, taken in stages. The hard part is committing to the first step on time.

Assisty already treats this as a finding, not an afterthought: overstock is surfaced ranked by money at stake with the fix named alongside it — an item holding 240 days of stock arrives with Plan markdown attached. The plan is yours to run; the table gives you the exposure, priced and sorted.

Both ways of being wrong are permanent

Last-time-buy sizing is formally a cost-balancing problem — procurement, holding, disposal and shortage costs, net of whatever salvage you recover — and the same literature names the standard failure: LTB orders are routinely oversized in pursuit of service level, leaving a large obsolete residual (arXiv). Buying generously feels safe because in replenishment it is. Here it just buys a bigger write-off.

The other error isn't safe either. Run out early and those sales are gone — no substitute arrives, no next cycle recaptures them. Leftovers never sell at full price later; the price only goes one way.

So pick the terminal error on purpose and write it into the quantity. Writing it in is the cheap part: tell Atlas how reality differs from the data and the whole table recomputes, every change carrying a was→now chip with per-row undo, and nothing committed until you create the order. Then select the rows — Atlas splits the selection into one PO per supplier and asks which location receives it.

The date is the one input nobody can infer for you. Everything downstream of it is arithmetic you can run today.