OTIF is the KPI that ends “it arrived… sort of”
Most delivery disputes aren’t about whether a truck showed up. They’re about the missing line item, the wrong variant, the split shipment that arrived after the production slot, or the “delivered” order that’s still sitting in a carrier depot. OTIF (On-Time In-Full) exists to stop those arguments from being purely anecdotal.
At its simplest, OTIF asks one question: did the supplier deliver what you ordered (in full), when you agreed it was needed (on time)? Procurement teams use it to quantify reliability, compare suppliers, and decide when a “cheap” unit price is being wiped out by expediting, downtime, and rework.
A practical definition: “on time” and “in full” need rules
OTIF sounds binary, but it becomes messy the moment you try to calculate it. The only way it stays useful is if you define the rules up front—then apply them consistently across suppliers.
What counts as “on time”?
“On time” should be measured against an agreed date (or time window), not a vague expectation. In practice, teams choose one of these anchors: the purchase order requested delivery date, the supplier’s confirmed delivery date, or a scheduled dock appointment. Each choice shifts accountability. If you measure against your requested date but allow suppliers to confirm later dates without challenge, you’ll punish them for dates you never truly agreed.
Define a tolerance window (e.g., early/late allowed days). Too strict and you’ll label everything a failure; too loose and OTIF becomes meaningless.
Decide whether early deliveries count as on time. In many sites, “early” creates storage and handling cost and should not be rewarded.
Choose the event that proves delivery: proof of delivery, goods receipt posting, or put-away completion. If your warehouse posts receipts two days late, your OTIF will blame suppliers for your internal delay.
What counts as “in full”?
“In full” usually means the right quantities of the right items, delivered in one go, with acceptable substitutions only if pre-approved. The trap is partial acceptance: operations may accept 90% to keep moving, while procurement still needs that missing 10% to avoid a second shipment and a second round of admin.
Set the unit of measure for completeness: order line, SKU, case, pallet, or total order quantity.
Decide how you treat backorders and split shipments. Many businesses score the order as not in full until the last piece arrives.
Include quality and compliance if they are common failure modes (e.g., wrong certificate, damaged goods). Some teams track these separately to avoid turning OTIF into an all-purpose dumping ground.
How OTIF is calculated (and why the denominator matters)
OTIF is typically expressed as a percentage: deliveries that met both conditions divided by total deliveries measured. Sounds straightforward—until you decide what “total deliveries” means. Counting by purchase orders will hide chronic short-shipping across many lines; counting by order lines can over-penalise large, complex orders.
A workable approach is to pick the level that matches how your business feels pain. If one missing component stops a production line, line-level OTIF makes sense. If your warehouse processes orders as a single unit of work, order-level OTIF may be closer to reality. The important part is not the “right” formula; it’s that everyone stops changing the denominator when the number looks bad.
Where OTIF goes wrong in real procurement teams
OTIF is often treated as a supplier stick. That’s convenient—and frequently inaccurate. Many OTIF failures are created upstream by the buyer: late POs, unclear lead times, last-minute changes, or “requested dates” that ignore the supplier’s capacity. If you don’t separate supplier-caused vs buyer-caused failures, the metric will drive the wrong behaviour.
Measuring against dates that were never confirmed (then acting surprised when suppliers miss them).
Using goods receipt date as “delivery date” when the warehouse is understaffed and receipts are posted late.
Ignoring master data issues: wrong pack sizes, obsolete SKUs, incorrect ship-to addresses—then blaming the supplier for mismatches.
Letting partials slide operationally, then wondering why suppliers keep shipping partials as a habit.
Mixing urgent spot buys and stable replenishment in the same OTIF bucket, which makes every supplier look unreliable.
What OTIF is good for (and what it’s not)
Used well, OTIF is a service-level signal you can negotiate around: it supports supplier development, helps prioritise expediting effort, and makes trade-offs visible (price vs reliability, buffer stock vs delivery discipline). It’s especially useful when you have repeatable flows—MRO, packaging, components, standard finished goods—where patterns matter.
What it’s not: a complete picture of supplier performance. A supplier can hit OTIF while quietly increasing prices, shipping in excessive packaging, or delivering “on time” only because you padded lead times. OTIF should sit next to other measures—quality, responsiveness, cost-to-serve—not replace them.
How to implement OTIF without creating a monthly blame ritual
The fastest way to kill OTIF is to publish a league table, shame suppliers, and ignore the disputes. A better approach is to treat OTIF as a shared operational metric with a dispute process and a short list of fixable root causes.
Write down your definitions (on-time anchor, tolerance, in-full rules) and share them with suppliers before scoring them.
Start with a pilot category where data is clean and order patterns are stable; fix the data problems before scaling.
Track “reason codes” for failures (supplier capacity, carrier delay, buyer change, master data, warehouse receipt delay). Even imperfect coding beats guesswork.
Agree how performance will be used: escalation thresholds, corrective action plans, and when OTIF affects sourcing decisions.
Review exceptions with operations and logistics, not just procurement. Many fixes sit outside the buying team.
A simple test: if OTIF improves, did life actually get easier?
If your OTIF score climbs but expediting effort, stockouts, and “where is my order?” emails don’t drop, something is off—usually definitions, data capture, or the denominator. The point of OTIF isn’t a prettier dashboard. It’s fewer surprises at the dock and fewer production or service disruptions caused by avoidable delivery failures.