K-12

Supplier On-Time Delivery

Did the supplier deliver to your dock by the date they originally committed — at which receipt grain, against which promise, and after how much of the line arrived?

There is a reference build of this metric: the Supplier Scorecard 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

\text{Supplier OTD} = \frac{\sum_{s \in S} \mathbf{1}\!\left[t^{\mathrm{rcpt}}_{s} \le t^{\mathrm{prom}}_{s}\right]}{\lvert S \rvert}

In words

Supplier OTD = PO schedules received within the declared window ÷ eligible PO schedules due

Where

$s$: an eligible PO schedule line
$S$: eligible PO schedule lines due in the period, after declared cancellations and exclusions
$t^{\mathrm{rcpt}}_{s}$: date the cumulative dock receipt reached the committed quantity
$t^{\mathrm{prom}}_{s}$: original supplier-confirmed receipt date (the window edge where a commercial receiving window applies)
$\mathbf{1}$: 1 when the test holds, else 0

Numerator: Eligible schedules whose chosen dock-receipt milestone falls inside the declared window around the chosen promise
Denominator: Eligible PO schedules due in the period, after declared cancellations and exclusions
Grain: Purchase-order shipment schedule, rolled to supplier and period
Note: Aggregate receipt events to the schedule first. A receipt split is evidence for one schedule, not several denominator rows.

What supplier on-time delivery measures

Supplier on-time delivery is the share of eligible purchase-order schedule lines whose cumulative dock receipt reached the committed quantity on or before the supplier's originally confirmed date, within any declared receiving window. The event is the buyer's receipt, not the supplier's ship notice.

Supplier on-time delivery is the share of eligible purchase schedules that physically reach the buying company's dock by a declared commitment date. The event is your receipt, not the supplier's ASN and not the date they say the truck left. That boundary keeps the metric tied to an event the buying company can verify.

There is no useful OTD number without a promise basis. A buyer-requested date measures whether the requirement was met; a supplier-confirmed date measures whether the supplier kept its commitment; a current confirmed date often measures whether the promise was moved before the receipt. Those are three different questions. The practice default keeps the original supplier-confirmed receipt date as the accountability clock and reports requested-date service beside it.

Partial receipts make the receipt event a second definition choice. First-receipt OTD lets one unit stop the clock. Complete-receipt OTD waits until cumulative accepted quantity reaches ordered less canceled quantity. Store both milestone dates on the fulfillment fact and choose one in the metric contract; do not let a dashboard silently switch between them.

Also answers to Supplier OTD · Vendor OTD · Purchase Order On-Time Delivery

The decision switches

Four switches. Promise basis and receipt event usually move the number more than any supplier improvement programme does.

Promise basis

dependsOriginal supplier-confirmed promise — the accountability default — snapshot it when first confirmed because most ERPs keep only the latest value
raises the scoreCurrent confirmed promise — a late line can become on time after the promise is moved
lowers the scoreBuyer-requested receipt date — measures the buying requirement, including gaps the supplier never accepted

Practice default Original supplier-confirmed receipt date, with requested-date service and promise-change rate published beside it.

Receipt event

raises the scoreFirst physical receipt — a token partial delivery stops the clock even when most of the line is still missing
lowers the scoreCumulative receipt reaches the committed quantity — the line passes only when enough accepted quantity has arrived

Practice default Cumulative dock receipt to ordered less canceled quantity; report first-receipt OTD only as a separate diagnostic.

Weighting

dependsPO schedule line — each committed delivery schedule gets one vote and remains drillable
dependsQuantity weighted — large schedules dominate and mix shifts can move the portfolio rate

Practice default Schedule-line OTD as the headline, with the received-quantity denominator shown beside it.

Tolerance window

dependsOn or before promise — early receipts pass even when they create storage or cash consequences
lowers the scoreDeclared early/late window — receipts outside either side fail; the window should come from the agreement
raises the scoreLate-day grace only — a one- or two-day operational grace raises the score and must be printed on the tile

Practice default Use the commercial receiving window where one exists; otherwise publish zero late-day tolerance and show early receipts separately.

Common pitfalls

Scoring against the current promise — If a late line is rescheduled before it arrives, current-promise OTD turns the miss into a pass. Snapshot the original confirmation and publish promise-change rate beside OTD.
Using ASN or ship confirmation as the actual — Those events describe what the supplier reported, not what reached your dock. Use the receiving ledger and state whether the milestone is receive, inspect, accept, or deliver-to-inventory.
Letting a partial receipt stop the clock — One early unit can make a thousand-unit line look on time. If first receipt matters operationally, publish it separately from the complete or accepted-quantity milestone.
Averaging supplier percentages — A portfolio OTD is passing schedules divided by eligible schedules, not the mean of supplier rates. Show the denominator because a 100% supplier on two lines is not stronger evidence than 91% on two thousand.
Scoring history against today's tolerance — The tolerance fields that decide what counts as in-full — SAP's EKPO overdelivery and underdelivery percentages, D365's per-module item settings — are overwritten in place, so the extract holds only the tolerance in force today. Scoring last year's receipts against it silently rewrites the rules they were received under. If the tolerance window matters to the score, snapshot the tolerances into a type-2 dimension as part of the landing.

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 Supplier On-Time Delivery reads as a SELECT — the pattern worked through in full in the OTIF entry’s landing pattern.