Sold out for two weeks: why the reorder report under-orders

Here is a pattern that catches people the second time they run out of a product, not the first. A bestseller sells out on the 3rd of the month. The delivery lands on the 17th. Two weeks later the reorder report in Restock Ops suggests a quantity that feels small, and because the report is usually right, you order it. Six weeks after that you are out again, and the report seemed to see it coming even less than before.

Nothing is broken. The report is doing exactly what it says, which is turning the orders Shopify recorded into a units-per-day rate and planning from that. The problem is that for fourteen of the days in the window the product could not be bought, Shopify recorded zero sales, and zero is not what demand was. This post walks through the arithmetic, shows how far off it gets, and gives three ways to fix it, in order of how much effort they take.

What the velocity is, in one line

The report takes every unit of an item sold in the sales velocity window (30 days by default, adjustable in Settings between 7 and 365) and divides by the number of days in the window. Units sold over days, nothing cleverer. The what counts as a sale post explains which orders and line items are included; for this post the only fact that matters is the division. Every day in the window counts in the denominator whether or not the product was available to buy.

That rate then drives everything else. Days of cover is on hand plus incoming divided by the velocity. The order target is velocity times lead time plus the days of cover you asked for. The suggested quantity is the target minus what you have and what is already on order, rounded up to the supplier's case size or minimum. Lower the velocity and every one of those numbers moves in the direction of ordering less and worrying later.

The arithmetic of a two week gap

Take a product that genuinely sells 10 a day. In a normal 30-day window the report sees 300 units and computes 10 a day. Now put a 14-day stockout inside the window. The 16 days it was in stock sold 160 units; the 14 days it was not sold none. The report divides 160 by 30 and gets 5.3 a day, about half the truth.

Follow that through with a supplier lead time of 20 days and 14 days of cover. The target is 5.3 times 34, which rounds to 181 units. The real target is 10 times 34, which is 340. If you have 60 on hand, the report suggests 121 and you needed 280. You are short by more than half a delivery, and the shortfall lands exactly when the next stock arrives: the 121 units sell out in 12 days, the lead time is 20, and you have another stockout, which drags the next window's velocity down again. That is the spiral the opening paragraph described.

Why the report does not guess

It would be possible to detect the gap and divide by in-stock days instead. We chose not to, for two reasons. The first is that Shopify does not keep a reliable record of when a variant was at zero at each location, so the app would be inferring the gap from inventory history, which has the same holes as every other inventory history. The second is that a product sitting at zero is not always a stockout. It may have been deliberately paused, unpublished for a season, or replaced by a new variant while the old one ran down. A report that silently inflates the velocity for every zero period would over-order in those cases, and over-ordering is the mistake that costs cash rather than sales.

So the report shows you a velocity it can defend from the orders, marks where that velocity came from, and leaves the judgement to you. The three corrections below are the judgement.

Fix one: type the real rate as a manual velocity

Every row of the reorder report has a manual velocity field, labelled Sales per day. Enter the rate the product sells at when it is in stock and the report uses that number instead of the computed one, for that row only, until you clear it. The row shows that it is running on a manual rate so you can see at a glance which items are on your forecast rather than history.

Working the number out is easy right after a stockout because you know the dates. Units sold in the window divided by the days it was actually available: 160 over 16, which is 10. Enter 10. The suggestion jumps from 121 to 280 immediately, since the report recomputes from the live values when it loads.

The step people forget is clearing it. Once the window has moved past the gap, which takes as many days as the window is long, the computed velocity is honest again and a manual value left in place is just a stale guess. Put a note in the calendar for 30 days out, or make a habit of scanning the manual rows once a month. The rollout post uses the same field for a different purpose and the same warning applies.

Fix two: shorten the window after the stock is back

The window is a single setting for the whole store, so this is a blunt tool, but it is a quick one. If the stockout ended a week ago, a 7-day window sees only days the product was available and computes a rate from those. For the example that is 70 units over 7 days, 10 a day, with no typing per row.

The cost is that every other product's velocity becomes a 7-day average too, and a week is a noisy sample. A product that sells 3 a week reads as 0 or 0.43 depending on which day you look. Use this when the stockout hit many products at once, a delayed container or a warehouse closure, and set the window back to 30 once a full month of normal selling has passed. A shorter window after a wide gap is a one-time repair, not a permanent choice.

Fix three: set a reorder point for products that must not run out

The two fixes above correct the rate. The third makes the report less dependent on it. A reorder point is a fixed quantity per item; when on hand plus incoming falls to it, the row is flagged and the suggestion becomes at least enough to get back above the point, whatever the velocity says. The velocity still sets how far above, but the trigger no longer depends on a number that a gap can halve.

For a product where a stockout is expensive, a hero item or a component every bundle depends on, set the point at the units you expect to sell during a lead time plus a margin, using the rate you know rather than the one the report currently shows. Then even a depressed velocity cannot push the item below the line without raising a flag. The stock alert post describes the alert side of the same idea.

Spotting a depressed velocity before it bites

• Sort the report by days of cover and look at the rows near the top that recently received a delivery. A product that just arrived and already shows low cover usually has a true high rate; one that shows comfortable cover right after a stockout may be running on a halved velocity.
• Compare the velocity with last month's. The report is read live, so keep the previous export or a note. A rate that fell by a third for a product nobody stopped promoting is a gap, not a trend.
• Check the receipt date against the window. If the delivery that ended the stockout is less than a window-length ago, the velocity for that item still contains zero days.
• Look at the stocktake. A count that found zero on a shelf that was expected to hold stock is the gap starting; the stocktake post covers what a count does and does not change about the report.

What Shopify's own reports show

Shopify's inventory reports present the same history from a different angle. Sell-through rate and days of inventory remaining are built from the sales Shopify recorded, so a stockout lowers them in the same way; a product that was unavailable for two weeks shows a lower sell-through and a longer days-remaining figure than its demand would justify. Since October 2026 those reports also measure on hand rather than available quantity, which changes the value and quantity columns but not the way a gap in sales is treated. Neither Shopify nor the app can report demand that never had the chance to become an order. The manual velocity field is the place that knowledge goes.

FAQ