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.

Verified October 2026

Definitions below are current to the date above — verify against current SAP, Oracle, Microsoft, Infor, and Databricks documentation before you build.

Formula

\begin{aligned} \text{LT}_{\ell} &= t^{\mathrm{stop}}_{\ell} - t^{\mathrm{start}}_{\ell} \\ \text{Reported} &= \operatorname{median}_{\ell}\!\left(\text{LT}_{\ell}\right),\; P_{90}\!\left(\text{LT}_{\ell}\right) \end{aligned}

In words

Lead time = stop timestamp − start timestamp, per document line

Where

$\ell$: order line (customer clocks) or PO schedule line (supplier clock)
$t^{\mathrm{start}}_{\ell}$: the declared start timestamp of the chosen clock
$t^{\mathrm{stop}}_{\ell}$: its declared stop timestamp
$\operatorname{median}$: median of the pooled per-line durations at the queried scope
$P_{90}$: their 90th percentile, likewise pooled

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.

What lead time measures

Lead time is the elapsed time between two declared timestamps on one document line — order entry to goods issue, confirmation to proof of delivery, or purchase-order approval to putaway — reported as the median and 90th percentile of the pooled line durations, in calendar days unless a contract says otherwise.

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.

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

dependsMean — 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.

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.

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.

The same two clocks, as a pass/fail test