The reorder math merchants are doing by hand again, and the four fields that replace it

The formula doing the rounds in merchant forums is the right one: reorder point = average daily sales × supplier lead time, plus safety stock. Run it on a SKU that sells 3 units a day with a 14 day lead time and a 20 percent buffer. Lead time demand is 3 × 14, so 42 units. Twenty percent of 42 is 8.4, round up to 9. Your reorder point is 51. When that SKU drops to 51 units on hand, you place the order. No app required, and the arithmetic is not the hard part.

What is hard is that 51 is only true for about a week. Velocity moves. A supplier slips from 14 days to 19. You have 400 other SKUs with their own numbers, and every one of them needs recalculating against today's stock on hand. That is where hand math stops being math and starts being a standing appointment with a spreadsheet. Of the four inputs, two are judgement calls you should keep, and two are arithmetic on data that changes daily, which is what software is for.

The worked example, all the way through

Take the 3 units a day SKU with 60 units on hand.

• Average daily sales: 3
• Lead time: 14 days
• Lead time demand: 42 units
• Safety stock at 20 percent: 9 units
• Reorder point: 51 units

You are 9 units above the line, which at 3 a day is three days before you cross. Order on the day you cross and the shipment lands 14 days later, by which point you have sold 42 and you are sitting on your 9 units of safety stock, roughly three days of cover. That is the whole design: the buffer absorbs a supplier running late or a week that sells faster than average.

Notice what the number is not. It is not a par level and it is not the quantity to order. It is a trigger. The order quantity is a separate decision, usually demand over the period you want covered after delivery, minus what you will have on hand when the box arrives.

The two numbers you should own

Lead time. No data source knows this. Shopify does not know it, and no tool can infer it from your sales. It is the number of days between you sending the purchase order and the stock being sellable, which includes the two days your supplier takes to acknowledge the order, the customs hold, and the afternoon it sits on your receiving bench. If your supplier quotes 14 and delivers 17 more often than not, your lead time is 17. Owning this number is the highest leverage thing a merchant does in reorder planning, because it multiplies against velocity. An error of three days on a 3 a day SKU is 9 units of exposure.

The safety stock buffer. This is a risk decision, not a calculation. Twenty percent is a reasonable default. It should be higher for a SKU that sells in bursts, for a supplier who has burned you, or for an item where going out of stock sends the customer to a competitor rather than to a backorder form. It can be lower on slow, predictable, cheap-to-hold stock. Averages are what break merchants here: a SKU that sells 21 units in one day a week averages 3 a day, and an average-based reorder point will let it run dry mid-week. The buffer is the answer to that, and only you can size it.

The two numbers a tool should compute

Average daily sales. This changes every day and it depends on the window you pick. Seven days reacts to a trend quickly and overreacts to a promotion. Thirty days is steadier and slower to notice that something has started moving. Recomputing it by hand across a few hundred SKUs is the part of the job nobody does weekly, which means the reorder points in most spreadsheets are quietly running on last quarter's velocity.

The crossing. Multiplying velocity by lead time and adding a buffer is trivial. Watching every SKU every day to see which one just crossed its line is not, and it is the part that actually prevents a stockout. A reorder point you check on Mondays is a reorder point that can be breached on a Tuesday and sit there for six days.

How those four fields look in Restoc

Restoc is built around exactly this split. When it launches, you set the two numbers you own and it computes the two you should not have to.

You give it a lead time in days, per SKU, validated as a whole number between 1 and 365 so a typo does not silently poison a reorder point. Because typing a lead time into hundreds of SKUs one at a time is not a real workflow, it also syncs each product's vendor from Shopify and gives you a vendor lead times screen: set 19 days against one supplier and every SKU of theirs without its own override inherits it. You also set a store-wide safety stock percentage, which feeds the reorder point function directly and shows as a units column on the dashboard, the weekly report and the CSV export, so you can see that the 51 is 42 plus 9 rather than a number with no working shown.

Restoc computes the rest. It pulls inventory levels from Shopify through the install and builds sales velocity from order data as it comes in, derives average daily sales over a velocity window you choose from 7, 14 or 30 days, and runs the reorder point as a tested pure function, including the awkward cases: zero-sales SKUs, SKUs with less history than the window, SKUs already at zero. The dashboard shows current stock, days of inventory remaining and reorder status per SKU. When a SKU crosses its line, an alert goes out by email or Slack webhook, once per crossing rather than once per job run. On top of that, a weekly report lists everything below its reorder point with a suggested order quantity, exportable as CSV for whoever raises the purchase orders.

Three honest limits. A freshly connected store has little or no velocity to work from at first, because sales accrue forward from the day you connect rather than arriving as a backfill, so for the first stretch the numbers on screen are thin and your spreadsheet stays open. The longest velocity window is 30 days, and merchants running heavily seasonal catalogues often want a 60 day average, so if that is you, bias your buffer upward to compensate. And the safety stock percentage is store-wide today rather than per SKU, so your burstiest item and your steadiest item share one buffer setting until that changes.

When hand math is still the right answer

If you have 30 SKUs, one supplier and stable demand, the spreadsheet is fine. Recalculate it monthly and you will not miss much. The case for automating starts where the numbers stop holding still: more SKUs than you can scan in a sitting, lead times that vary by supplier, or products that sell in bursts. The failure mode is not getting the formula wrong. It is having the right formula sitting in a file nobody opened this week while a hero SKU quietly crossed its line.