Home / Blog

How to calculate reorder point for a Shopify store

Abstract artwork in Restoc's colours

Reorder point is the stock level where you place the next purchase order. The formula is: average daily sales x lead time in days, plus a safety buffer. If a SKU sells 8 units a day and your supplier takes 21 days from PO to receiving dock, your reorder point is 168 units, plus whatever buffer you keep for a late shipment or a good week. Hit 168 on hand, you order. Below it, you are already late.

Every number in that formula exists in your Shopify admin right now. Average daily sales comes from your orders over a chosen window, 7, 14 or 30 days. Current stock comes from the inventory level at your location. Lead time is the one number Shopify does not know, because it lives in your email thread with your supplier. Below, the walk-through: where each figure comes from, which window to pick, and the places the arithmetic quietly lies to you.

The formula, written out

Reorder point = (average daily sales x lead time in days) + safety stock

Three inputs. Two of them are data, one is a decision.

  • Average daily sales, sometimes called sales velocity. Units sold over a window, divided by the days in that window.
  • Lead time in days, measured from the moment you send the PO to the moment the stock is countable and sellable, not the moment it leaves the factory.
  • Safety stock, the cushion that covers a supplier slipping a week or a sudden spike.

The product of the first two is your lead time demand: how much you will sell while you wait. Safety stock is what stops a normal amount of bad luck turning into a zero.

Where average daily sales comes from in the Shopify admin

Go to Analytics, then Reports, then open Sales by product variant SKU. Set the date range to the last 30 days. The column you want is net items sold, not gross sales in currency. Reorder points are counted in units. Revenue figures will mislead you the moment you run a discount.

Take the net items sold for one SKU and divide by the number of days in the range. A variant that moved 240 units across 30 days sells 8 a day.

Two adjustments before you trust the number:

  • Exclude days the SKU was out of stock. If it sold 240 units but was unavailable for 6 of those days, the honest divisor is 24, not 30, which gives 10 a day rather than 8. Stockouts suppress the very number you use to prevent stockouts. This is the single most common way a reorder point ends up too low.
  • Decide about returns and cancellations. Net items sold already nets refunds out. That is usually what you want for replenishment, because a returned saleable unit goes back on the shelf.

Do this by hand for one SKU and you will understand the formula for life. Do it by hand for 600 SKUs every Monday and you will stop doing it by the third week. That is the problem Restoc is built to remove. When it launches, the Shopify install flow is built to pull real-time inventory levels and historical sales through webhooks and a scheduled sync job, and the reorder point calculation engine runs the arithmetic per SKU from that data (mvp:1, mvp:2). Restoc is on the waitlist today, so none of that is running on your store yet.

Choosing 7, 14 or 30 days

The window is a trade-off between responsiveness and noise, and there is no universally right answer.

  • 7 days. Reacts fast. Good for a SKU that just got picked up by a creator, or for genuinely fast-moving consumables. Also the window most likely to mistake one good Saturday for a new baseline. One bulk order from a wholesale customer can double a 7-day velocity.
  • 14 days. Two full weekly cycles, so weekday and weekend patterns cancel out. A reasonable default for most catalogues.
  • 30 days. Smoothest. Best for slow movers where a 7-day window frequently reads zero. The cost is lag: it takes weeks to notice that demand has genuinely stepped up or fallen off.

A practical approach is 14 days for the bulk of the catalogue, 30 days for slow movers where single-digit monthly sales make short windows meaningless, and 7 days only for SKUs you are actively watching. In Restoc, when it launches, the velocity window is configurable to 7, 14 or 30 days, and the setting is validated server-side so a bad value is rejected with a clear message rather than quietly producing a wrong number (mvp:2, item:b83d7838-44c0-4bf8-8a16-974270fe0b8c).

Where current stock comes from

Products, then the variant, then Inventory. If you run more than one location, note that Shopify shows available per location and a total. Use the quantity at the location that actually fulfils orders for that channel. A merchant with 40 units in a retail shop and 3 in the fulfilment warehouse does not have 43 units of cover for online orders.

Also decide how you treat incoming quantity. Stock already on a PO is not available to sell, but it does mean you should not order again. If you ignore incoming, you will double-order on long lead time items. The simple discipline: once you place a PO, that SKU is settled until the shipment lands, regardless of what the reorder point says next week.

Lead time: the number only you have

Shopify has no idea how long your supplier takes. You have to supply it, per SKU, and it should be measured end to end:

  • Days between you sending the PO and the supplier confirming it
  • Production or picking time
  • Transit, including ocean freight and any customs delay
  • Days between arrival at your warehouse and the stock being received, counted, and marked available in Shopify

That last step is routinely left out, and it is routinely three to five days. A container that clears customs on the 14th is not sellable inventory on the 14th.

Use your actual recent history rather than the supplier's quoted number. If the last four POs from one supplier took 24, 31, 26 and 29 days, use 30, not the 21 they promised. In Restoc, when it launches, lead time is entered per SKU and validated as a positive whole number of days within a sane range, so a typo cannot silently wreck a reorder point (mvp:2, item:b83d7838-44c0-4bf8-8a16-974270fe0b8c).

Safety stock: the decision, not the data

The textbook version uses demand standard deviation and a service-level factor. For a catalogue of a few hundred SKUs, most merchants get most of the value from a simpler rule: add a percentage of lead time demand, sized by how variable the SKU is and how badly a stockout hurts.

  • Steady seller, reliable domestic supplier: 10 to 20 percent of lead time demand
  • Normal variation, or a supplier who sometimes slips: 25 to 50 percent
  • Hero SKU, overseas freight, or a product you cannot substitute: more, and reviewed by hand

Take the earlier example. 8 units a day, 21 day lead time, 168 units of lead time demand. Add 30 percent safety stock and the reorder point is 218. The number climbing from 168 to 218 is not padding. It is the difference between a supplier being a week late and you being fine, versus a supplier being a week late and your listing going dark.

Worked example, three SKUs, one catalogue

Say a 400 SKU apparel store, 14 day window, mixed suppliers.

  1. Core black tee, size M. 154 units sold in 14 days, so 11 a day. Domestic supplier, 18 day lead time including receiving. Lead time demand 198. Safety stock 20 percent, so 40. Reorder point 238. Current stock 260. Not yet, but close, and worth watching this week.
  2. Printed hoodie, seasonal. 28 units in 14 days, so 2 a day. Overseas, 62 day lead time. Lead time demand 124. Safety stock 40 percent, so 50. Reorder point 174. Current stock 90. Already well past the point, and the long lead time means this one hurts.
  3. Accessory, slow mover. 3 units in 14 days. At 0.21 a day the 14-day window is noise. Switch it to a 30 day window: 9 units in 30 days, 0.3 a day. With a 25 day lead time, lead time demand is 7.5, call it 8, plus buffer, reorder point about 11. Small numbers, but reordering at 11 instead of 2 is what keeps the listing live.

Notice the hoodie. Nothing about its shelf looked alarming, 90 units is not a scary number, but the 62 day lead time means the reorder window closed weeks ago. Long lead time SKUs are where reorder points earn their keep, because eyeballing the shelf tells you nothing useful.

Where the arithmetic lies to you

  • Zero-sales SKUs. Velocity zero gives a reorder point of zero, which means the SKU never alerts. That is correct for a discontinued line and wrong for a new one. Restoc's calculation function is unit-tested against zero-sales SKUs, high-variance history, SKUs with less history than the chosen window, and SKUs already at zero stock, so it returns a defined, non-negative number in each case rather than a crash or a blank (item:1e56c9d5-f906-4981-8ffb-16674ccf430d).
  • New products. A SKU launched nine days ago has no 30 day history. Any window longer than its life will understate it. Use a short window and revisit.
  • Promotions. A flash sale inside your window inflates velocity for weeks afterward on a 30 day setting. If you ran one, know that the number is hot.
  • Seasonality. A trailing window is backward-looking by definition. It will not tell you that November triples your volume. For seasonal peaks, override the number by hand.
  • Bundles and kits. If a component sells inside a bundle, the component SKU's own sales report may not reflect true consumption.

None of these break the formula. They just mean the output is a prompt to think, not an instruction to obey.

Running it without doing the arithmetic

The formula is easy. Recomputing it for every SKU, every day, against stock that changes every hour, is not. That is the work Restoc is built to take over when it launches: a dashboard showing current stock, days of inventory remaining and reorder status per active SKU, email and Slack alerts when a SKU crosses its reorder point, and a weekly report of everything below the line with a suggested order quantity, viewable in-app and exportable as CSV (mvp:5, mvp:3, mvp:4). Alerts are built to be delivered through a background job designed to be idempotent, so a re-run does not fire the same warning twice (mvp:3, item:c24b8127-0b31-4096-8da1-b761740d8008).

Restoc is on the waitlist today, not in the App Store. When it opens, the trial runs 60 days, long enough for at least one full weekly reorder cycle to complete before any charge (mvp:7).

Until then, the formula above works with nothing but a spreadsheet and the sales by SKU report. Run it on your twenty highest-margin SKUs this week. Write down the reorder point next to each one. That list, kept honest, is most of inventory management.

What is the basic reorder point formula?

Reorder point equals average daily sales multiplied by lead time in days, plus safety stock. The first part is how much you will sell while you wait for the shipment, and safety stock is the cushion for a late supplier or a busy week.

Should I use a 7, 14 or 30 day sales window?

Fourteen days is a sensible default because it covers two full weekly cycles and cancels out weekday and weekend swings. Use 30 days for slow movers where short windows read zero, and 7 days only for SKUs you are actively watching after a spike.

Where do I find sales velocity in the Shopify admin?

Open Analytics, then Reports, then Sales by product variant SKU, and set your date range. Use the net items sold column rather than a currency figure, and divide by the number of days the SKU was actually in stock.

Can Restoc calculate reorder points for me?

That is what it is built to do when it launches: pull inventory and sales from Shopify, apply your chosen velocity window and per-SKU lead time, and alert you by email or Slack when a SKU crosses its reorder point. Restoc is on the waitlist today, so the calculation above is the manual version of the same arithmetic.