K-09
Lead Time — Order-to-Delivery & Supplier
How long from commitment to arrival — which two timestamps define the clock, and is the reported number a mean or the percentile customers and planners actually feel?
There is a reference build of this metric: the Lead Time & Reliability dashboard in the showcase runs this definition over frozen, simulated data — not a live client system.
Definitions and source tables below are current to the date above — verify against current SAP, Oracle, Microsoft, Infor, and Databricks documentation before you build.
What lead time measures
Lead time is a family of clocks, not one metric. The customer-facing versions run from an order or a confirmation to a ship or a delivery; the supplier-facing version runs from a purchase order to a receipt or a putaway. They share the arithmetic — one timestamp minus another — and almost nothing else, because they measure different processes for different audiences.
That makes the two timestamps the definition. Order entry to goods issue, confirmation to proof of delivery, and purchase order approval to putaway are three different numbers, and a chart labeled only lead time gives an audience no way to know which one it is looking at. Naming both events is not pedantry; it is the minimum for the number to be reproducible.
The statistic is the second half of the definition, and it matters more here than almost anywhere else in this dictionary. Safety stock exists to absorb the tail of the lead-time distribution, and the mean is precisely the statistic that hides the tail: one hub delay that lands at P95 barely moves the average and completely determines the buffer you should be holding. Report the median and P90, and recompute both from pooled durations at every scope, because a mean of site-level P90s is not the network P90.
Also answers to Order-to-Delivery · Customer Lead Time · Supplier Lead Time · PO Lead Time · Replenishment Lead Time
The decision switches
Four switches here, one more than most entries — because the clock and the statistic are independent choices, and both change the number.
| Switch | Settings | Practice default |
|---|---|---|
| Which clock | Customer order-to-ship · Customer order-to-delivery · Supplier PO-to-receipt | Pick the clock per audience, and never blend clocks inside one trend line. |
| Start and stop events | Order entry → goods issue · Confirmation → proof of delivery · PO approval → putaway | Name both timestamps on the chart — a lead time without them is not a definition. |
| Statistic | Mean · Median and P90 | Median and P90, recomputed from the pooled durations at every scope. |
| Calendar vs business days | Calendar days · Business days | Calendar days unless a contract says otherwise — and label which one is on the chart. |
Which clock
- dependsCustomer order-to-ship — what the fulfillment operation controls, transit excluded
- dependsCustomer order-to-delivery — adds transit — what the customer actually experiences
- dependsSupplier PO-to-receipt — the planning parameter that drives replenishment and safety stock
Practice default Pick the clock per audience, and never blend clocks inside one trend line.
Start and stop events
- dependsOrder entry → goods issue — the widest internal clock, including everything before release
- dependsConfirmation → proof of delivery — starts at the commitment and ends where the customer says it ended
- dependsPO approval → putaway — includes dock-to-stock, which planning needs and receiving often omits
Practice default Name both timestamps on the chart — a lead time without them is not a definition.
Statistic
- raises the scoreMean — legible, and it hides exactly the tail that drives safety stock
- dependsMedian and P90 — the practice default — P90 is what inventory policy should be sized against
Practice default Median and P90, recomputed from the pooled durations at every scope.
Calendar vs business days
- dependsCalendar days — the default; comparable across sites without a shared working calendar
- dependsBusiness days — fairer to operations, and it needs a maintained calendar dimension to compute
Practice default Calendar days unless a contract says otherwise — and label which one is on the chart.
Formula & grain
Lead time = stop timestamp − start timestamp, per document line
- Statistic
- Median and P90 of per-line durations for the declared clock
- Population
- Per-line durations at the declared grain
- Grain
- Order line for the customer clocks, purchase order schedule line for the supplier clock
- Note
- Never average away the tail, and never average percentiles across sites — recompute from the pooled lines.
Common pitfalls
- The mean — One hub delay lives at P90 and above and never appears in the average, so a portfolio can post a stable mean lead time while planners hold buffers for a distribution nobody is reporting.
- Re-aggregating percentiles — A mean of site-level P90s is not the network P90, and there is no weighting that makes it one — and the failure does not wait for a filter. A dataset that stores percentiles pre-aggregated by any dimension is already wrong at the unfiltered total (verified in one workspace on 2026-08-24, where the pre-aggregated figure missed the true pooled percentile with no filter applied). Never pre-aggregate a percentile: store the durations and recompute at each scope.
- Mixed clocks in one trend line — A series that quietly switches from order-to-ship to order-to-delivery will show an improvement or a regression that never happened. Fix the clock for the whole series.
- Sentinel and timezone artifacts — Unset dates stored as sentinels, unconverted Julian zeros, and UTC boundaries all produce negative or impossible durations. NULL-wrap first, convert timezones before taking dates, and treat any negative duration as a data defect rather than a fast delivery.
Source tables — SAP
Source tables — JD Edwards
Source tables — Dynamics 365
Sales lines with the customer packing-slip journal give the outbound clock; purchase lines with the vendor packing-slip journal give the inbound one. NULL-wrap the sentinel dates first, or unconfirmed lines contribute century-long lead times.
Source tables — Infor M3
Source tables — Oracle EBS
Promised and need-by dates live on the PO line location, not on the PO line, which is the join most supplier lead-time builds get wrong first. Receipts land in the receiving transactions, and the operating unit stripes all of it.
Source tables — Oracle Fusion
Fulfillment lines and delivery details carry the customer clock; PO line locations and receipt transactions carry the supplier clock. As in EBS, the schedule-level line location is where the committed dates live.
Store the components, not the ratio
Every switch above is a different way of reading the same underlying facts, so the components — quantities, dates, values, flags — are what belongs in the gold layer, never the finished percentage. Bronze keeps the source tables as extracted, silver resolves the encodings once, and gold carries a component-level fact that each variant of Lead Time reads as a SELECT — the pattern worked through in full in the OTIF entry's landing pattern.