Open the supplier record you set up eighteen months ago. There's a lead time in it. Fourteen days. You typed that in during onboarding, from memory, and you rounded it.
You have not looked at it since.
Every reorder decision for every SKU that supplier sells sits on top of that number. When the reorder point fires, when the suggested quantity lands, how much cover you carry going into a busy month. All of it is calculated from a figure you guessed once and never checked. If the figure is wrong, every decision built on it is wrong in the same direction.
This post is about that number. Where the guess comes from, the two ways it drifts away from reality, and what the drift costs you.
The number nobody revisits
Lead time is the gap between placing a purchase order and the stock being available to sell. It is the single most important input to a reorder point, because it sets how far ahead you have to see. Reorder too late by the length of your lead time and you stock out before the replacement lands. Guaranteed, not occasionally.
Cin7 Core gives you a field to store it. What it does not do is tell you whether the number in that field is true. It records every PO you raise and every receipt you book, but it never turns around and says: "You told me this supplier takes 14 days. The last six orders averaged 23." The data to check the guess is sitting in the system. Nothing checks it.
So the guess persists. And it drifts.
Two ways the guess goes wrong
The supplier slips, and the number doesn't. The fourteen days you entered might have been true once. Then the supplier changed freight forwarders, or moved a production line offshore. Lead times creep. Yours has probably crept. The field still says 14 because nobody updates a field that isn't throwing an error.
Business days and calendar days get mixed up. This one is quieter and more common than it should be. Your supplier quotes "ten working days." You enter 10. But ten working days is two full weeks plus the two weekends inside them. Fourteen calendar days, not ten. If your reorder math treats that 10 as calendar days, you are short four days of cover on every order, every time, forever. The error never shows up as a mistake. It shows up as a SKU that keeps cutting it fine.
Both failures push the same way. The stored lead time is shorter than the real one, so the reorder point is set too low, so the PO fires too late.
What the math does with a wrong number
The textbook reorder point is simple:
Reorder Point = (Average Daily Demand × Lead Time) + Safety Stock
Watch what happens when the lead time is wrong.
Take a SKU that sells 8 units a day. You've got the lead time stored as 14 days. So your reorder point lands around 112 units, plus a safety buffer. When available stock drops to that line, you reorder, expecting the replacement to land before you run dry.
Now say the supplier actually takes 23 days, not 14. The real cover you need is 23 × 8 = 184 units, not 112. You reordered 9 days too late. At 8 units a day, that's 72 units of demand with no stock to meet it. Some of it your safety buffer absorbs. The rest is a stockout, on a SKU you reordered "on time," through a system you trusted, because the one number underneath it was a guess from a year ago.
The business-days error does the same thing on a smaller scale. Ten working days read as ten calendar days is four days short. Four days at 8 units a day is 32 units of cover you thought you had and didn't. It rarely takes you out on its own. It works against you on every single order.
Stop guessing. Your own POs already know the answer
The fix is not a better guess. It's to stop guessing and measure.
Every received PO is a completed experiment. It has an order date and a receipt date. The gap between them is a real, observed lead time for that supplier. Not an estimate. A fact. Average the last several of those and you have a lead time grounded in what the supplier actually does, not what they once said they'd do.
That's the principle we built into the way Stocura handles lead times. Each supplier starts on your manual estimate, because at first that's all there is. Once there's enough order history (six or more received POs, or 90 days of it) the system stops trusting the estimate and takes over with the learned figure, averaged from the real order-to-receipt gaps. When it switches, it emails you so the change isn't silent. From then on, the number ageing quietly in a field gets replaced by the number the supplier keeps proving with every delivery.
The same math also keeps business days and calendar days straight. Lead times are counted in business days, because that's how suppliers actually work. They don't pick and pack on Sundays. Demand is counted in calendar days, because customers buy on Sundays. The conversion between the two happens in the engine, so the ten-working-days-versus-ten-days trap never gets a chance to open.
One SKU, two suppliers, two lead times
There's a second wrinkle the single stored number hides. Plenty of SKUs have more than one supplier: a primary you usually buy from and a backup for when the primary is out or slow. Those two suppliers rarely share a lead time. The local backup might turn an order around in 5 business days. The cheaper overseas primary might take 30.
If your system only holds one lead time per SKU, it's forcing two different realities through one field. The reorder trigger should run on whichever supplier you actually order from by default. The alternative lead time should be there, visible, the moment you decide to switch sources. Collapsing both into one number means your reorder point is wrong for at least one of them, all the time.
What you can do this week
You don't need new software to find out whether your lead times are lying to you. You need an afternoon.
Pick your five biggest suppliers by spend. For each, pull the last ten received POs out of Cin7 Core. For every one, take the receipt date, subtract the order date, and write down the gap in days. Average the ten.
The check: compare that average to the lead time sitting in the supplier record. If it's within a day or two, leave it. The number's honest. If it's meaningfully longer than the stored figure, you've found a supplier whose every reorder has been firing late, and you can fix it in thirty seconds by correcting the field. While you're there, confirm whether the number you entered was business days or calendar days, and whether your reorder math agrees.
Five suppliers, an hour, and you'll know which of your reorder points have been built on sand. The ones that have been quietly cutting it fine usually trace back to exactly this: one number, guessed once, never checked again.
Go and pull those ten POs for your slowest overseas supplier first. If the average comes back a week longer than the field says, that's the SKU stocking out next, and you've got a thirty-second fix sitting in front of you.
Let your purchase orders set your lead times
Stocura learns each supplier's real lead time from your Cin7 Core PO history, runs the reorder math in business days, and tells you when the number changes. Free until August 1, 2026 during soft launch.
Start free trial