If you've used Cin7 Core for more than a few months, you've probably hit this moment: you open the product detail page, look at the Minimum Before Reorder field, and realize you have no idea what number to put in.
So you guess. You put in something that feels right. Then you move on to the next 800 SKUs and put in numbers that feel right for those too.
Six months later you're either drowning in dead stock or apologizing to customers for a third week of "out of stock" emails. Often both at once, for different SKUs.
This post is the math and the methodology. What a reorder point actually is, where Cin7's default approach leaves you exposed, and a framework you can apply tomorrow whether you're managing 50 SKUs or 5,000.
What a reorder point actually means
A reorder point is the stock level at which you should place a new order with your supplier. It's the trigger to order, not the point where the new stock arrives. People mix those two up constantly.
The formula in its simplest form:
Reorder Point = (Average Daily Demand × Lead Time) + Safety Stock
Three variables. Two are about your business, one is about your supplier, and all of them tend to be wrong.
Take a real example. A SKU sells 5 units per day on average. Your supplier takes 14 days to deliver. You want some buffer in case demand spikes, say an extra 30 units of safety stock.
- Demand during lead time: 5 × 14 = 70 units
- Plus safety stock: + 30 units
- Reorder point = 100 units
When stock drops to 100, you place an order. By the time the order arrives 14 days later, you've sold 70 units, leaving you with 30 (your safety stock) plus the new delivery.
Simple in theory. The problem is each of those three numbers is harder to get right than it looks.
What Cin7 Core gives you — and what it doesn't
Cin7 Core does three useful things for reorder management:
- It stores a Minimum Before Reorder field on every product.
- It shows you stock levels in real time.
- It can trigger alerts when stock falls below your set minimum.
What it doesn't do:
- Calculate the reorder point for you. You have to put in the number yourself.
- Adjust for seasonality. That winter coat SKU has a different reorder point in June than December, but Cin7 stores a single static value.
- Account for stockout-corrected demand. Cin7 only knows what you sold, not what customers tried to buy when you were out of stock.
- Handle multi-supplier scenarios. If you have a primary supplier with a 14-day lead time and a backup with 30 days, Cin7 stores one number.
- Learn from your actual purchase history. Your "14-day lead time" might really be 19 days in practice, but Cin7 will never tell you.
None of this is a knock on Cin7 Core. It's an inventory management system, not a demand planning system. Those are different problems. But it does mean the reorder point field sits there waiting for you to fill it in with something defensible, and most of us don't have the time or the math to do that properly.
Why most reorder points are wrong (the four common mistakes)
Across the Cin7 users we've talked to, four problems show up again and again.
Mistake #1: Using simple averages for demand
The classic formula is total units sold last year ÷ 365 days. That gives you "average daily demand."
The problem: this hides everything that matters about demand. A SKU that sells 100 units in December and 5 units per month the rest of the year has an "average" of 13.75 units per month. Plan around that average and you'll be wildly out of stock at peak and drowning the rest of the year.
Better approach: segment demand by season if you can. If you have less than two years of data, at minimum identify your peak months and plan a separate reorder point for them.
Mistake #2: Trusting your supplier's stated lead time
Suppliers quote a lead time. Then reality happens.
Your "14-day" supplier averages 19 days when you actually measure the PO date to received-into-stock date across the last 12 months. The 5 days you're missing in your reorder math is the difference between a healthy stock buffer and a stockout.
Better approach: measure your actual lead time. Pull the last 6–12 received POs for each supplier. Compute the median, not the average, because outliers skew averages. Use that number, not the supplier's promise.
If you're on Cin7 Core, the POs table has the data you need. Date placed, date received. Subtract. Median across recent POs. That's your real lead time.
Mistake #3: Forgetting that "demand" excludes stockouts
This is the subtle one, and it catches almost everyone.
If your SKU was out of stock for 60 days last year, your recorded sales for those 60 days are zero. But the actual demand wasn't zero. It was just unmet. Customers tried to buy and couldn't.
When you compute "average daily demand" using your sales history, you're computing the demand that got through, not the demand that was there. Your reorder point ends up sized to maintain the stockouts.
This is what statisticians call censored demand, and it creates a vicious feedback loop:
- You under-estimate demand because of past stockouts
- Your reorder point is too low
- You stock out more
- Your demand estimate stays depressed
- Reorder point stays too low
- And so on
Better approach: subtract the days you were out of stock from the divisor. If a SKU sold 600 units in a year but was out of stock for 60 of those days, your real daily demand is 600 ÷ (365 − 60) = 1.97 units/day, not 600 ÷ 365 = 1.64. That's 20% higher, which means a 20% higher reorder point.
This adjustment matters most exactly where you can least afford to keep getting it wrong: your fastest-moving SKUs that stock out most often.
Mistake #4: Using calendar days when you mean business days
Most reorder formulas treat lead time as calendar days. "14 days" means 14 of the same days you measure demand on.
But your supplier doesn't work weekends. Their factory is closed Sunday. Their forwarder ships Monday to Friday. If a supplier "quotes 5 business days," that's actually 7 calendar days. If you reorder on a Friday afternoon, the clock doesn't start until Monday.
Meanwhile your customers buy 7 days a week. Your demand keeps accruing while your supplier rests.
The mismatch isn't huge, roughly 40%. Applied to a reorder point, that's the difference between safe and stocked out.
Better approach: if your supplier quotes business days, convert to calendar days before plugging into the demand formula. The rough conversion: business_days × (7/5) = calendar_days. So a "5 business day" lead time is really 7 calendar days of demand exposure.
A practical framework you can apply this week
Pull this together into a working method:
Step 1: Get your real demand per SKU
For each active SKU, take last 12 months of sales. Subtract any days the SKU was out of stock. Divide.
real_daily_demand = total_units_sold_last_12mo / (365 − days_out_of_stock)
If you don't track stockout days, ballpark it. If you remember a SKU was out for "about a month" last winter, that's 30 days. Better an estimate than ignoring it.
Step 2: Measure your real lead time per supplier
Pull the last 6–12 received POs from each supplier. Compute the median number of days between PO date and received date.
real_lead_time_calendar_days = median(received_date − po_date)
If your supplier quotes "business days," convert it: business_days × 7/5.
Step 3: Decide your safety stock multiplier
Safety stock should reflect your tolerance for stockouts and the predictability of demand.
- Predictable, low-volume SKU: safety = lead_time_demand × 0.5 (50% buffer)
- Average SKU: safety = lead_time_demand × 1.0 (one full lead-time period as buffer)
- High-volume or unpredictable SKU: safety = lead_time_demand × 1.5
- Critical, cannot-stock-out SKU: safety = lead_time_demand × 2.0
This isn't science. It's about how risk-tolerant you can afford to be. A higher safety multiplier means more cash tied up in stock; a lower one means more stockout risk.
Step 4: Compute the reorder point
lead_time_demand = real_daily_demand × real_lead_time_calendar_days
safety_stock = lead_time_demand × safety_multiplier
reorder_point = round(lead_time_demand + safety_stock)
That's the number to put into Cin7 Core's Minimum Before Reorder field.
Step 5: Review quarterly
Demand changes and lead times drift. A reorder point you set in February might be wrong by August.
Set a recurring calendar item to review your top 50 SKUs by sales velocity every quarter. The other 750 can be reviewed annually if they're stable.
When the spreadsheet stops working
The method above works. It also takes time.
Setting reorder points for 50 SKUs is a Saturday afternoon's work. Setting them for 500 is a long week. Setting them for 5,000, then re-doing it every quarter, is a full-time job.
At some point most growing Cin7 users hit the same wall: they know what they should be doing, but they don't have the time to do it manually, and Cin7 doesn't do it for them.
The options at that point are:
- Accept worse reorder points. Most SMBs default to this. You stock out occasionally and overstock chronically. It works until growth makes the cost obvious.
- Hire a demand planner. Realistic if you're $10M+ revenue. Most growing SMBs aren't there yet.
- Use a dedicated tool. This is what we built Stocura for. It sits on top of Cin7 Core and runs the math above (plus more sophisticated forecasting and lead-time learning) automatically across every SKU. Stockouts and seasonality both get factored in, and lead times get learned from your actual PO history. You review a Reorder Queue once a week instead of doing the math by hand.
Whatever you choose, the math is the same. What matters is that somebody or something is doing it. Leave the field blank and you're guessing on numbers that move your cash and your customer experience every single week.
TL;DR — the cheat sheet
If you remember nothing else from this post:
- The reorder point formula:
(real_daily_demand × real_lead_time_calendar_days) × (1 + safety_multiplier) - For demand, divide by days-in-stock, not 365.
- For lead time, measure your actual receipt dates, don't trust supplier promises.
- For business-day suppliers, multiply by 7/5 to convert to calendar days.
- Safety multiplier between 0.5 and 2.0 depending on SKU criticality.
- Review quarterly for top sellers, annually for the rest.
Don't want to do this for 800 SKUs by hand?
Stocura runs the math above (and more) every hour across your Cin7 Core data. Free until August 1, 2026 during soft launch.
Start free trial