SCM
Purchase orders and lines with promised and confirmed dates, goods receipts, current lead time and safety stock settings, and reorder policy per item.
Supply Chain
Plan on the lead time you get, not the one you were promised
The lead time in your item master was entered once, from a supplier's own quote, and has been treated as fact ever since. Every reorder point, every safety stock level, and every date you promise a customer rests on it. Meanwhile the receipts in your warehouse have been quietly recording what that supplier actually does, week after week, and nobody has ever put the two columns next to each other. Coheed does, per supplier and per item, and gives you both the real lead time and how much you can trust it.
- Systems combined
- SCMERP
- Runs
- Weekly on Monday
Sound familiar?
Teams bring us this use case when one or more of these is true.
- Safety stock was set by feel, because nobody trusts the lead times it should be calculated from.
- A supplier everyone 'knows' is unreliable has never been shown to be, with numbers.
- Orders are placed early as a habit, tying up cash to compensate for a lead time nobody has verified.
- Purchase negotiations are about price, because delivery performance is not measured.
How it works
Coheed runs this as a scheduled insight over your connected systems, then hands the result to an agent.
- 1
Promises and receipts are paired
Every purchase order line and its confirmed date is matched to the goods receipt that closed it, including partial receipts and lines delivered across several shipments, so the comparison is per delivery rather than per order header.
- 2
Lead time is measured, with its spread
Per supplier and per item you get the median lead time actually achieved and how much it varies. A supplier who is reliably twelve days is a completely different planning problem from one who averages ten but ranges from four to twenty-five, and only the spread tells you that.
- 3
The item master is compared against reality
The measured lead time is put next to the one your planning currently uses, so the items where the two disagree most, which are the ones quietly driving your stock-outs and your excess, are ranked by impact.
- 4
The insight becomes an action
Items whose measured lead time no longer matches the master data are handed to an agent that prepares the correction, along with the safety stock implication, for review.
Which data it uses
Only the fields this use case needs are read. Nothing is copied that the insight does not use.
ERP
Item master and supplier records, purchase invoices, and the agreed terms per supplier.
Coheed
The cross-system item and supplier links, and the measurement history that makes a trend, improving or deteriorating, visible over time.
What changes
What a team notices once this runs. No invented percentages: the effect depends on your data and your process.
- Safety stock is calculated from measured variability instead of set by feel.
- Supplier conversations start from a delivery record rather than an impression.
- The items whose master data is most wrong are ranked, so you correct the ones that cost money first.
- A supplier who is slowly getting worse is visible before it turns into a stock-out.
From insight to action
Lead Time Correction Agent
Available as an agent
Proposes updated lead time and safety stock values for the items where measurement and master data have diverged furthest, each with the receipt history behind it. Master data changes are prepared for approval rather than written on their own.
Mode: Human-in-the-loop
Every insight can stay read-only, run with human approval, or run autonomously. You decide per action type, and you can change it later.
FAQ
Frequently asked questions
How much purchase history do you need?
Roughly a year of receipts gives a stable median and a meaningful spread for regularly ordered items. Items ordered rarely are still measured, but marked low confidence so nobody rebuilds a safety stock policy on three data points.
What if we never record the supplier's confirmed date?
Then it measures against the date you requested instead, and says so. That is a different number, how long an order really takes from placing it to having it, rather than how well a supplier keeps their word. It is arguably the more useful one for planning, and it is the honest one to report when the confirmation was never captured. Where your ERP does hold a separate confirmed date, both are shown.
What if the delay was our fault, not the supplier's?
Late orders placed on your side are separated out, so an order sent a week after it should have been does not count against the supplier. What is left is delivery performance you can actually take into a negotiation.
Does it change our master data automatically?
Only if you allow it. By default the agent prepares the correction with the evidence attached, because a lead time change ripples straight into reorder points and cash.
Which systems does it need?
Whatever holds your purchase orders and your goods receipts, which for most companies is the ERP alone or the ERP plus a separate planning or warehouse system.
Built on these maturity levels
Most relevant for
Logistics & Transport
Combine your TMS, telematics, fleet, and finance systems into insights no single tool can produce.
B2B Wholesale
Close the gaps between CRM, ERP, and SCM so promises, stock, and margin hold across the whole order chain.
Manufacturing
Connect the quote, the shop floor, and purchasing so promised dates, real cost price, and margin per order finally agree.
Other use cases
Predictive Customer Lifetime Value
Score churn risk and future value per account by combining CRM engagement decline with ERP order frequency and value trends.
Lead-to-Quote Readiness
Surface correct ERP pricing, live stock, discounts, and customer agreements on every new CRM lead so sales can quote immediately.
Order Exception Monitoring
Catch stock gaps, unrealistic delivery dates, pricing errors, and missed agreements after the order, before the customer notices.
See this on your own data
Tell us your ERP, CRM, and SCM stack and we will show what this use case looks like on your systems.