When should I reorder this ASIN?

Knowing how many units you have in FBA is easy. Knowing when you'll need to reorder is the hard part — and the gap between the two is sales velocity.

A thousand units means nothing on its own. At 10 a day it's a hundred days of cover. At 50 a day it's twenty. And if velocity moves from 10 to 50, the plan you made last month isn't slightly wrong — it's about a different business.

So a reorder forecast isn't a number you calculate once. It's a standing estimate that should move every time the evidence moves.

One caveat, stated once and not repeated: a forecasted reorder date is not a prediction. It's the output of a calculation over assumptions you can name. When an assumption changes, the date changes. That's the system working, not failing.

Here's how to build the estimate, and — more usefully — how to read it.

01Two dates, not one

Sellers ask "when do I run out?" The system has to answer a harder question first.

• The stockout date is when usable inventory reaches zero under a stated demand assumption.
• The order-by date is the last day you can place the order and still have units land before that happens.

They are separated by your entire replenishment lead time plus whatever buffer you've decided to carry. With a 60-day supplier, an ASIN with 45 days of cover isn't comfortable — it's already fifteen days late.

Waiting for inventory to look low is a strategy that only works if your supplier is faster than your customers.

Every section below exists to make one of those two dates more honest.

02The window problem, and how to actually resolve it

Sales velocity is units sold ÷ days. The arithmetic is trivial. The choice of days is the whole decision.

The ladder is monotonic: every shorter window is faster than the one before it. That shape is the signal — not any single row. It says demand is accelerating, and it says so more convincingly than a 7-day figure ever could on its own, because a spike shows up in one window while a trend shows up in all of them.

A default you can defend

Blend the responsive window with the stable one and lean recent:

weighted velocity = 0.6 × (last 7 days)
                  + 0.4 × (last 30 days)

                  = 0.6 × 47.1 + 0.4 × 40.0
                  = 44.3 units/day

This reacts to a real change within about a week, and it can't be dragged around by a single unusual day the way a raw 7-day figure can. Use it as the default and override it deliberately.

When to override it

Discount the short window when you can name the cause and the cause has an end date. A coupon that runs until Friday, a competitor who'll be back in stock in two weeks, a Prime Day tail — these are events, not demand. Reprice the forecast to the pre-event baseline and note when to re-check.

Trust the short window when the ladder is monotonic and the gap has persisted for two consecutive weeks. A step change with no nameable cause is usually a real change in rank or competitive position.

03Anchor to the data, not to today

Here is the failure that quietly breaks more reorder forecasts than any modelling choice.

Your sales data ends on some date. It's rarely today — reports settle late, imports run on a schedule, someone forgot. If your last transaction data covers through 5 September and your system computes "last 30 days" against today's date, it averages real sales with days that have no data in them yet.

Twelve days of lag against a 30-day window understates velocity by roughly 40%. Divide your stock by that and the system reports comfortable cover on a SKU that's about to go dark — in green, confidently.

Two rules fix it permanently:

• Compute every rate against the last day the data actually covers, not the wall clock.
• Project every date forward from that same anchor — and put the anchor on the screen where the reader can see it.

A forecast that won't tell you how old its inputs are is asking to be trusted on the one point where it's weakest.

04What actually counts as available

Not every unit attached to an ASIN can serve the next customer. Before any projection, separate:

• Sellable — the only units that satisfy demand today.
• Reserved — allocated to orders, in transfer between fulfilment centres, or in processing. Real, but not yet available.
• Unfulfillable — damaged, expired, stranded. Present in the account, absent from the forecast.
• Inbound — not stock. Not nothing either. See the next section.

Two of these routinely inflate a forecast. Counting reserved units as sellable buys you a few phantom days; counting inbound as on-hand buys you weeks of them.

05Inbound is a date, not a quantity

The common shortcut — add on-hand and inbound, divide by velocity — produces a number that is almost never right, because it assumes 800 units on a boat can be sold today.

Model stock as a curve instead. It falls at your velocity, steps up on the arrival date, and falls again.

That near-miss is invisible in any calculation that treats inbound as a lump sum. It's the single strongest argument for modelling inventory as a timeline.

And it means a delay notification is a forecast input, not an inconvenience: push the arrival by ten days and the projection should change the moment you record it.

06Lead time is a range you've already measured

Most reorder errors trace back to a lead time somebody typed in once, optimistically, in a different year.

You don't need to estimate it. You've run the orders. Measure from order placed to units sellable — the full chain, not just the factory:

production 20d + prep 5d + transit 25d + receiving 5d

For AB-2210 the last five orders took 48, 53, 59, 67 and 72 days. The average is 60. Reaching for the average alone throws away the most useful thing in that list — the spread.

average lead time  = 60 days
worst observed     = 72 days
lead-time buffer   = 72 − 60 = 12 days

Those twelve days aren't padding. They're the observed cost of your supplier being their usual self on a bad month. Add a demand-variability allowance on top if the SKU is volatile.

Whatever you choose, the assumption belongs on screen. A reorder date computed from a lead time the reader can't see is a number they have no way to disagree with — and the seller usually knows something the system doesn't.

07The whole calculation, on one SKU

Now every input has a defensible value. The reorder point is what you must not fall below:

reorder point = velocity × (lead time + buffer)
              = 44.3 × (60 + 12)
              = 3,190 units

AB-2210 has 1,240 on hand and 800 inbound. Even counting both, it sits at 2,040 — well under 3,190. It crossed its reorder point some time ago.

The date says the same thing:

projected stockout  ≈ 21 Oct   (from the curve above)
minus lead time         60 d
minus buffer            12 d
──────────────────────────────
order-by date       ≈ 10 Aug   — 30 days ago

This is the outcome the article has been building toward, and it's the common one: a SKU that looks healthy — six weeks of cover, a shipment on the water — is a month late on its next order. Days of cover hid it. Only the date exposed it.

When that happens, the questions change. Not "should I order?" but: how much can I expedite, what does air freight cost against the stockout it prevents, and do I split the order to get something moving now.

08Show the range, not the date

A system that prints "Reorder by 10 August" has told the truth and created a false impression at the same time. The number looks like a fact. It's a conclusion resting on a velocity assumption that could reasonably have been three other values.

So show what the assumption is worth:

Read that block for a second and you learn something no single date could tell you: the window debate doesn't matter here. Every plausible assumption puts the order-by date in the past. The velocity question is real, but it isn't this SKU's question — it only decides the quantity now, not whether to act.

On another SKU the same three rows might span six weeks and straddle today. Then the assumption is the decision, and it deserves an afternoon. Showing the spread is what lets a seller tell those two situations apart in a glance.

09What "real-time" should actually mean

Not recalculating every second. Nobody makes a purchase order decision on a five-minute cadence, and a forecast that twitches at every daily fluctuation trains you to ignore it.

Real-time should mean event-driven: the projection updates when something that feeds it changes.

• New sales data lands
• Stock moves, or units go unfulfillable
• An inbound shipment ships, arrives, or slips
• A purchase order is placed, received, or its dates change
• You change a lead time or a target cover

And it should be paired with a rule for when to tell you. Alert when a conclusion changes, not when a number does: an order-by date crossing today, a stockout date moving more than a week, a SKU dropping below its reorder point. Everything else is a screen you can visit.

A monthly refresh misses real changes. A constant one manufactures fake ones. The right cadence is a system that recalculates on events and interrupts you on conclusions.

10Keeping score is what makes it improve

Store what you predicted. Compare it to what happened. Without this, a forecasting system never gets better — it just keeps being confidently wrong in the same direction.

Three variances are worth tracking per SKU:

• Velocity variance — forecast 40/day, actual 52/day. One miss is noise; the same sign four weeks running is a settings problem you can fix.
• Lead-time variance — every completed PO is a free measurement. Feed it straight back into the average and the worst case.
• Arrival variance — how often does inbound land on the date you were given? That number is your real buffer requirement, and it's usually larger than the one you chose.

Over time this turns lead time and buffer from opinions into observations. That's the compounding part; the arithmetic was never the hard bit.

11The checklist

1. Find the last date your sales data covers. Anchor everything to it.
2. Separate sellable from reserved, unfulfillable and inbound.
3. Compute the velocity ladder — 7, 30, 60, 90 — and read its shape.
4. Set the working velocity: weighted by default, overridden only for a cause you can name.
5. Project stock as a curve, stepping up on each inbound arrival date.
6. Measure lead time from your own POs; keep the average and the worst case.
7. Set the buffer from the spread, plus a demand allowance if the SKU is volatile.
8. Compute the reorder point and the order-by date. Flag anything already past.
9. Show the order-by date at three velocities, not one.
10. Recalculate on events; alert only when a conclusion changes.
11. Record the forecast, and score it later.

Eleven steps, and only two of them are arithmetic. The rest is deciding what you believe and writing it down where you can check it later.

Frequently asked