How to Calculate OTIF and Why Retailer Definitions Differ

The supplier's weekly dashboard says 96% OTIF. The retailer's scorecard for the same weeks says 81%, and the deduction for non-compliant cases has already come off the remittance. Both teams are using real data. They are simply measuring different things: one counts orders shipped on the confirmed date with the confirmed quantity, the other counts cases received inside its own appointment window against the original purchase order.

OTIF only becomes useful when the unit, the delivery window and the in-full quantity are written down before anyone counts. Do that, score each record on both tests at once, and you get a number you can reconcile to a customer's scorecard line by line, and a fine you can either accept, dispute with evidence, or book correctly in the accounts.

• In this guide: the formula, the choice of unit, on-time windows, the in-full quantity basis, the data each party holds, and how retailer and modern-trade penalties are accounted for in the US and India.
• Worked artefacts: one ten-line dataset scored six ways, from 72.2% down to 0%, a SQL scoring query, a dispute trace, and worked fines in dollars and rupees.

OTIF is a joint test on each order line, not two averages multiplied

A record counts toward OTIF only when it passes both tests on the same delivery. Calculating an on-time rate and an in-full rate separately and multiplying them gives a number that can sit above or below true OTIF, depending on whether late deliveries also tend to be short. Score jointly and the question goes away.

-- OTIF by order line, early arrivals allowed (window A)
-- due_lines: one row per PO line due in the period
--   req_date      requested or must-arrive-by date on the frozen PO version
--   arrive_date   arrival date from the gate or appointment check-in
--   ord_qty       ordered cases on the frozen PO version
--   rcv_qty       cases received by the DC for that line
--   excluded      1 when a documented customer-caused reason applies
SELECT
  COUNT(*) FILTER (WHERE excluded = 0)                          AS lines_due,
  COUNT(*) FILTER (WHERE excluded = 0
                     AND arrive_date <= req_date
                     AND rcv_qty     >= ord_qty)                AS lines_otif,
  ROUND(100.0 * COUNT(*) FILTER (WHERE excluded = 0
                     AND arrive_date <= req_date
                     AND rcv_qty     >= ord_qty)
        / NULLIF(COUNT(*) FILTER (WHERE excluded = 0), 0), 1)    AS otif_pct
FROM due_lines;

-- Window B (early counts as a miss, one day early allowed):
--   replace  arrive_date <= req_date
--   with     arrive_date BETWEEN req_date - 1 AND req_date
-- In-full tolerance: rcv_qty >= ord_qty means zero tolerance; a 2% unit
-- tolerance would read  rcv_qty >= 0.98 * ord_qty

Three definitions sit inside that query: the record is a PO line, the window is "on or before the requested date", and in full means received cases at least equal ordered cases. Change any one and the score changes, which is the whole reason retailer and supplier numbers diverge.

Line-level OTIF on a retailer DC dataset counts an order line only when arrival falls inside the agreed window and received cases equal ordered cases; on ten illustrative lines, a 70% on-time rate and an 80% in-full rate produced 50% OTIF, not the 56% obtained by multiplying the two rates.

Order, line, case or unit: the denominator that moves the score most

Pick the unit your customer uses, and report the others only as diagnostics. A whole-order measure punishes any single short line; a case measure gives partial credit for everything that did arrive; a line measure sits between them. None is more correct, but each answers a different business question.

• Order level: a purchase order counts only if every line is on time and in full; useful when a store cannot sell an incomplete set or assortment.
• Line level: each SKU line on the PO is scored; the most common choice for supplier-side reporting and for root-cause work by SKU.
• Case level: each ordered case is scored; common in retailer programmes because fines are often priced per non-compliant case.
• Unit level: each selling unit is scored; used where items ship as eaches, such as e-commerce replenishment or pharmacy totes.

On-time windows: requested date, appointment and the early edge

An on-time test needs two boundaries and one timestamp source, all agreed in advance. The late boundary is obvious; the early boundary is where most supplier reports go wrong, because a DC that planned labour for Thursday does not want the truck on Tuesday. Write the window as "from X to Y", never as "by Y".

• Reference date: the requested delivery date, a must-arrive-by date or a booked appointment; state which one and from which PO version.
• Early edge: how many days or hours before the reference arrival still counts; zero, one day and "any time" all appear in practice.
• Late edge: whether the day of the reference date counts in full, or only until the appointment slot closes.
• Timestamp source: gate check-in, appointment arrival, carrier status message or DC receipt posting; these can differ by a day or more.
• Freight terms: whether shipments routed by the customer's own carrier are judged on arrival at all, or only on pickup readiness and fill.

The appointment case causes the most disputes. If the DC moves a slot, the agreement should say whether the window moves with it. Without that rule, a supplier can arrive exactly when told and still be scored late against the original requested date.

In-full basis: which quantity the received cases are compared with

In full means received quantity compared with a stated reference quantity, and the reference must be the one both parties agree, usually the PO quantity after customer-approved changes. Comparing shipped quantity with the supplier's own confirmed quantity, which many ERP reports do by default, measures the warehouse rather than the customer outcome.

Decide in advance how to treat over-shipments, substitutions and customer cuts. An over-shipped line usually passes the in-full test but may be refused at receipt; a substitution may count as a miss for the ordered SKU; a cut the customer requested should drop the line from the denominator with a reason code, not count against the supplier.

One ten-line dataset scored six ways, from 72.2% to 0%

The same ten lines produce scores from 72.2% to 0% depending on unit and window, with no change to the underlying deliveries. The dataset below is illustrative: four purchase orders to one retailer DC, 500 cases ordered and 491 received.

Window A accepts any arrival on or before the requested date. Window B accepts arrival on the requested date or one day before, so PO 102, two days early, fails. Seven lines are on time under A, eight are in full, and five pass both.

The supplier's internal 96% and the retailer's 81% from the opening example could easily be two cells of a table like this one. The fix is not better data but an agreed definition, stored with the score so anyone can recompute it.

Why a retailer scorecard and a supplier report disagree

A retailer scores with its own timestamps and quantities, so a supplier that wants to match must rebuild the score from the retailer's events, not its own. The supplier's ship date, confirmed quantity and carrier delivery scan are useful for root cause, but they are not what the scorecard measures.

• Different clocks: the retailer may use receipt posting time, which can trail gate arrival by hours when receiving is backed up.
• Different quantities: refused or damaged cases leave the received count even if they were shipped and delivered.
• Different PO versions: the scorecard may use the original PO while the supplier uses the last change it accepted.
• Different units: a case-level scorecard and a line-level report will rarely agree, as the worked table shows.

The trace below is illustrative, built on PO 103 from the dataset, and shows how an appointment change becomes a fine when nobody records it.

1. 13 Oct, 22:10, appointment moved: the DC scheduler emails the carrier moving PO 103 from 16 Oct 07:00 to 17 Oct 05:30 because of dock congestion.
2. 17 Oct, 05:42, gate check-in: the truck arrives inside the new slot; the gate log records trailer, seal and appointment number.
3. 17 Oct, 11:15, receipt posted: the DC posts receipt of 130 cases; the scorecard compares 17 Oct with the original requested date of 16 Oct.
4. 3 Nov, scorecard published: three PO 103 lines score late and the case-level fine is deducted from the next remittance.
5. Controlled replay: the supplier's OTIF table stores each appointment version and a "customer moved slot" reason code, so the dispute is filed on 4 Nov with the email and gate log attached, inside the programme's dispute window.

For the broader carrier side of delivery measurement, our carrier performance scorecard guide separates tender acceptance, execution and evidence quality. OTIF sits one level up: it judges the supplier to the customer, and the carrier's performance is one cause among several.

Booking retailer fines and fill-rate penalties in USD and INR

An OTIF fine is usually a reduction of what the customer pays, not a freight cost, and it should be booked that way. Under US GAAP, ASC 606-10-32-6 lists penalties among the items that make consideration variable, so a supplier expecting OTIF fines estimates them as a reduction of revenue rather than waiting for the deduction.

Ind AS 115 is different on this point. KPMG's Ind AS implementation guide notes that Ind AS 115 excludes penalties from the variable consideration list and requires them to be accounted for as per the substance of the contract: a penalty inherent in determining the price is variable consideration, otherwise it is not considered in determining the consideration.

Under US GAAP ASC 606-10-32-6, penalties appear among items that make consideration variable, so a supplier expecting retailer OTIF fines estimates them as a revenue reduction; on 139 non-compliant cases at $24.00 cost, an illustrative 3% case fine is $100.08, booked against sales rather than freight.

Indian modern-trade fill-rate clauses: what to read before signing

In India the OTIF obligation lives in the vendor agreement, not in any statute, so the clause wording is the whole rulebook. The same is true in the US, where retailer programmes are published in supplier manuals and portals and change from time to time; this article does not quote any retailer's targets or fine rates because they are contract terms.

• Measurement basis: whether fill rate is by case, line, value or PO, and whether it is judged per PO, per week or per month.
• Reference quantity: original PO, PO after agreed amendments, or the quantity the buyer's system "released" to the vendor.
• Delivery window: appointment rules, early-arrival treatment and what happens when the DC turns a truck away for lack of dock space.
• Penalty mechanics: rate, base, cap and whether the buyer recovers it by debit note or by deduction from payment.
• Dispute route: how many days the vendor has to contest, and what evidence the buyer accepts.

Two tax points follow from the clause. CGST Section 34(2) sets the outer date for declaring a credit note as 30 November following the end of the financial year of supply, or the annual return date if that comes first; and since 1 October 2025 the supplier's output tax reduction is allowed only if the recipient has reversed the matching credit.

The penalty itself is a separate question. CBIC Circular 178/10/2022-GST, at paragraph 7.1.4, says liquidated damages paid only to compensate for loss from a breach, with no agreement to tolerate an act, are a flow of money rather than consideration for a supply. Paragraph 7.1.6 treats some amounts called penalties as consideration. Have the tax team classify the specific clause.

Ind AS 115 departs from IFRS 15 by removing penalties from the variable consideration list, so an Indian supplier books a modern-trade fill-rate penalty by substance, while CGST Section 34(2) lets a short-supply credit note reduce output tax only after the recipient reverses the matching input credit, as amended from 1 October 2025.

Separating automatic OTIF scoring from analyst judgement calls

Scoring is arithmetic once the definitions are fixed; the judgement sits in exclusions, evidence and classification of short-ships. Automate the first and put review queues around the second, so the score is reproducible and the exceptions are explainable.

The deductions side has its own playbook in our article on vendor compliance deduction recovery and AR reconciliation, which follows the money after a fine is taken.

Building an OTIF report that survives a customer dispute

A defensible OTIF report stores the definition with the score, keeps every input event, and reconciles to the customer's scorecard before anyone presents it. Treat these six checks as the floor for a supplier selling to large retailers or modern-trade chains in either market.

OTIF tells you whether deliveries met the promise; it does not tell you what that promise cost to keep. Pair it with activity-based cost to serve, which prices the work each customer creates, to see whether a tighter window is worth what it costs. Other KPI and cost guides are listed on our logistics hub. If you want OTIF rebuilt from your own EDI and DC events, start an RFP with us and include your customer list and monthly PO count.