Most stores under £1m reorder by feel. Someone opens the stock page, notices a line looks thin, and places an order. It works well enough that the business survives, which is precisely why it never gets examined.
It produces two costs, and neither appears on a P&L as a line item. Capital sits in stock that will not sell for months. Revenue is lost on items that went to zero and stayed there. The first is visible if you look for it. The second is invisible by construction — you cannot see the orders you did not receive.
This guide sets out how to calculate a defensible reorder point from data you already have, using nothing but Shopify's native reports and a spreadsheet. It takes an afternoon the first time and about twenty minutes a month thereafter.
Which two numbers does a reorder point need?
A reorder point answers one question: at what stock level must I place an order to avoid running out before the replacement arrives?
It requires two inputs and one judgement.
- Velocity — how many units you sell per week
- Lead time — how many weeks between placing an order and having sellable stock
- Cover — how much buffer you want against both being wrong
The formula is unglamorous:
Reorder point = weekly velocity × lead time in weeks + buffer cover
A product selling 12 units a week with a four-week lead time and three weeks' buffer has a reorder point of 84 units. When stock hits 84, you order. Not before, not after.
Everything difficult about this sits in getting the three inputs right.
Getting the data out of Shopify
Two reports, both native, both variant-level.
Analytics → Reports → filter Category → Inventory
The reports worth pulling:
- Inventory sold daily by product — average units sold per day, per variant. This is your velocity input.
- Products by sell-through rate — the percentage of available stock sold in the period. Shopify calculates this as units sold ÷ (units sold + units remaining).
- Days of inventory remaining — Shopify's own projection, useful as a sense check against your own figures.
- ABC product analysis — classifies products by revenue contribution. You will want this in a moment.
Two practical constraints to know before you start.
Report access varies by plan. Basic plans carry a reduced report set and restricted export. If a report named above is not visible, that is why. Custom ShopifyQL explorations require Advanced or Plus.
Check how far back your analytics actually reach. Shopify's newer inventory tooling retains adjustment history with a full audit trail, but the reporting window available to you varies by plan and report. If you want a reliable year of seasonal history to forecast against, export and archive it yourself, monthly. Start now; anything you do not capture is awkward to reconstruct later.
There is also a two-day processing lag on these reports. It rarely matters for reorder calculations and it matters a great deal if you are trying to react to a launch in real time.
Set the date range to ninety days. Shorter and you are reading noise; longer and you are averaging across seasons that behave differently.
How do you calculate velocity properly?
This is where most calculations go wrong, and the error is systematic rather than random — it always pushes in the same direction.
Exclude out-of-stock days.
A product that sold nothing for three weeks because it was unavailable is not a slow-moving product. If you divide ninety days of sales by ninety days, you have computed the velocity of a product that spent a third of the period unsellable. The figure will be understated, you will set the reorder point too low, it will go out of stock again, and the next calculation will be more wrong than the last.
This is a self-reinforcing loop and it is the single most common reason a store's bestsellers are permanently under-ordered.
The correction is arithmetic. If a variant sold 84 units across ninety days but was available on only sixty of them, the velocity is 84 ÷ 60 = 1.4 units per day, or 9.8 per week — not 84 ÷ 90 = 0.93 per day. That is a difference of fifty per cent, and it is the difference between a product that is always in stock and one that is always nearly out.
Shopify's native reports will not do this exclusion for you. You need to know which variants went to zero and for how long, which means either capturing daily stock snapshots yourself or accepting a manual adjustment on the SKUs you know were out.
Exclude anomalies too, but sparingly. One viral week should not permanently reset a forecast. Neither should a fortnight of unusually flat trading. Strip genuine outliers and leave the rest alone — the temptation to smooth data until it agrees with your instincts is strong and should be resisted.
How do you measure supplier lead time?
Suppliers quote lead times. Those quotes describe the supplier's intention rather than your experience.
The number you want is the elapsed time from you placing the order to the stock being sellable on your site. That includes several things a supplier's quoted lead time excludes:
- Time between you deciding to order and actually sending the PO
- The supplier's actual production or picking time, which is often not their quoted one
- Shipping, including customs if applicable
- Your own receiving — counting, quality checking, putting away, updating Shopify
The last item is routinely ignored and is frequently the largest controllable component. Stock sitting in a box in the back of the unit for four days is stock you cannot sell.
Go back through your last six purchase orders per supplier and measure the real elapsed time. Use the longest of the six rather than the average. You are protecting against the bad case, not the typical one — the average lead time is exactly the figure that leaves you out of stock half the time.
If you have a supplier whose lead time varies wildly, that variance is itself a cost. It has to be absorbed as additional buffer, and that buffer is working capital. It is a legitimate thing to raise with them.
How much buffer cover should you hold?
Buffer stock is insurance, and like all insurance it has a premium. Every additional week of cover is cash converted into inventory.
Download
Reorder point calculator
An Excel workbook that takes your Shopify sell-through export and returns a reorder point per variant. No email required.
There is no universally correct figure. There is a reasonable framework:
- Two weeks for stable products with reliable suppliers and steady demand
- Three to four weeks for products with variable demand or an unreliable supplier
- Four to six weeks for anything seasonal approaching its season, or anything on a long international lead time
Two factors should push the number up. Demand volatility — if weekly sales swing widely, you need more buffer to cover the high weeks. And supplier unreliability — if lead time varies between four and nine weeks, you must plan for nine.
One factor should push it down: cash. A store with limited working capital should carry less buffer on C-tier products and accept occasional stockouts on items that contribute little revenue. That is a deliberate trade, not a failure.
Do this at variant level, not product level
The most consequential point in this guide.
Reorder points calculated at product level are wrong in a specific and expensive way. A product with five sizes does not sell them evenly. In apparel, the middle sizes typically account for a substantial majority of units. A colourway that photographs well may outsell its siblings several times over.
Consider a t-shirt across three sizes. Small sells 3 units a week, medium sells 14, large sells 6. Product-level thinking says the t-shirt sells 23 a week and orders accordingly, usually in even quantities across sizes. The consequence is entirely predictable: medium goes out of stock first, small accumulates and eventually gets discounted, and the product spends a large part of its life technically in stock but unbuyable for the majority of customers who wanted a medium.
The product page still shows as available. Your stock report still shows units on hand. Your advertising keeps running. Nothing in Shopify's default view flags any of this, because from Shopify's perspective nothing is wrong.
Every variant needs its own velocity, its own reorder point, and its own line on the purchase order. The Shopify reports above are already variant-level, so the data is there. The effort is in not collapsing it.
This is also the point at which a stockout stops being a stock problem and becomes a marketing problem, which is covered in Guide 04.
Do not do this for every SKU
A store with 400 variants that attempts to maintain 400 reorder points will maintain none of them. Prioritise using the ABC report.
- A items — typically the top 20 per cent of SKUs generating around 80 per cent of revenue. Calculate these properly, review monthly, hold generous buffer. These are the ones where a stockout is genuinely expensive.
- B items — the middle. Calculate once, review quarterly, hold moderate buffer.
- C items — the long tail. Do not calculate. Set a simple minimum threshold, reorder when it trips, and accept occasional gaps. The analytical effort costs more than the stockouts do.
Most stores at this size will find fewer than forty variants require real attention. That is a manageable afternoon's work and it covers the great majority of the exposure.
The other direction: stock that is not moving
A reorder point tells you what to buy. The same data tells you what to stop buying, and this is the half most stores skip.
Pull the sell-through report and sort ascending. Anything with a sell-through rate below roughly 20 per cent over ninety days is a candidate for action. Anything that has sold nothing in ninety days while holding stock is dead capital, and it should be treated as such: discount it, bundle it, or write it off, but do not reorder it and do not leave it sitting.
The arithmetic is straightforward and rarely done. Stock that does not move is cash that could have been in stock that does. A store holding £15,000 in dead lines while stocking out on its bestsellers has a working capital problem disguised as a demand problem.
What are the most common reorder point errors?
Using the average lead time. Use the longest recent one. The average leaves you short half the time by construction.
Recalculating too often. Monthly is right for A items. Weekly recalculation reacts to noise and produces whipsaw ordering.
Not recalculating at all. A reorder point set in February and never revisited will be badly wrong by November. Seasonality moves velocity substantially in most categories.
Forgetting minimum order quantities. If your reorder point says 84 units and the supplier's minimum is 200, your effective reorder point is higher than the formula suggests, because you must trigger the order earlier to avoid being caught between the two.
Ignoring committed stock. Shopify distinguishes on hand from available — available excludes units already sold but not yet shipped. Calculate against available, not on hand, or you will consistently order late.
Treating a promotion's velocity as normal. A week of discounted sales tells you what happens at that discount, not what happens at full price.
The App Ceiling
This section appears in every one of The Operational Guides. It describes where the advice above stops working.
Everything above holds to roughly £1m–£1.5m in annual revenue. Past that point the constraint changes, and it changes in a way that adding further apps does not address.
Apps are built to be sold to many stores. That is what makes them affordable, and it is also what limits them: an app can only act on the data inside its own boundary. Your forecasting tool does not know what your ad platform is spending. Your ad platform does not know what is out of stock. Your back-in-stock tool does not know what your supplier lead times are. Each app is correct within its own scope and blind outside it.
Below roughly £1m, a person bridges those gaps. Someone looks at the stock report, notices a line is running low, and adjusts. The bridging is invisible because it is absorbed into the founder's day.
Above roughly £1m, three things happen at once. SKU count rises, so there is more to bridge. Order volume rises, so the consequence of missing something rises with it. And the founder's time is now spent on growth rather than operations, so the bridging stops happening reliably. Nothing breaks visibly. Revenue keeps climbing. What changes is that a percentage of it begins to leak in places nobody is looking — advertising spend running against unavailable variants, stock accumulating in the wrong location, returns sitting unprocessed for a week and a half while the item they contain is out of stock and being advertised.
That is not an app problem, and no app solves it, because the solution has to sit between systems rather than inside one. It requires something built for your specific stack, your specific SKU structure, and your specific supplier terms.
Build the foundations well now. The stores that struggle most at £2m are not the ones that used the wrong apps. They are the ones whose product data was never structured properly in the first place, which makes every subsequent automation expensive to build.
Where should you start?
Pull the two reports. Take your top twenty variants by revenue. For each one, work out real velocity with out-of-stock days excluded, real lead time from your last six orders, and a buffer you can afford. Write the resulting reorder point somewhere you will actually look at it.
Then set a calendar reminder for the same day next month. The calculation is worth little; the habit of doing it is worth a great deal.