OTIF calculator: on-time and in-full delivery rate
OTIF (On Time In Full, also called DIFOT) is the share of deliveries that arrived both on time and complete: deliveries on time and in full ÷ deliveries made × 100, with orders cancelled by the customer left out. The figure depends on three choices that belong next to the number: what counts as on time (same day, inside the booked window or ± hours, and whether early counts), whether you count by line or by order, and which quantity tolerance applies. It is not on-time % × in-full %: in the sample log below 50.0% × 50.0% gives 25.0%, but OTIF is 16.7%. Logistivo keeps the raw material of this calculation on every load: the delivery date, the ETA and a dated history of each status change, including those the driver enters in the mobile app.
Source: ASCM · VDI · legislation.gov.uk · United Nations · Wikipedia (en).
Data last updated:
.
Delivery log
Delivery log — Type or paste your deliveries, set the definition and see which deliveries cost the OTIF score.
The calculation runs only in your browser: the log is never sent to or stored on a server.
The calculator measures delivery reliability (time and quantity). Documentation, damage and stock availability are separate KPIs, listed in the glossary.
Order ref. — Order or load reference. Rows with the same reference form one order when you count by order.
Line — Optional: order line number.
Promised / start — Promised date and time, or the start of the booked window, e.g. 14/09/2026 08:00; the whole window can sit in one cell: 14/09/2026 08:00-12:00.
Window end — Optional: just the time (12:00) if the window closes the same day, otherwise date and time.
Delivered at — Date and time the goods were placed at the consignee’s disposal. Empty = delivery still open.
Ordered — Quantity confirmed on the order (cases, pallets or units — the same unit as delivered).
Delivered — Quantity received. If the line arrived in several drops: the total, with the time of the last drop.
Selectable definitions
On time if — In window — A delivery is on time if the actual time falls between the start and end of the booked window, both included. After the end it is late, before the start it is early. With a time but no window end, the window is that exact time; with only a date, the window is the whole day.
On time if — Same day — A delivery is on time if the actual date is the promised day (or one of the window’s days). The time of day does not count: the next day is late, the day before is early.
On time if — ± hours — The promised window (or promised time) is widened by N hours on both sides. Outside that margin the delivery is late or early.
N hours — the starting value of 2 hours is only there to try the rule: use the margin written in your contract or SLA.
Early — Is a failure — A delivery before the window opens (or before the margin) is an on-time failure, just like a late one.
Early — Counts as on time — A delivery before the window counts as on time: the “on or before” criterion of SCOR metric RL.3.59 against the customer’s request date.
Count by — Line — Every row of the log is one unit: OTIF is the share of rows that are on time and in full.
Count by — Order — Rows with the same reference form one order. The order is on time only if all its lines are, and in full only if all its lines are (the strictest form, like the SCOR perfect order RL.1.1). If one line is open or unreadable, the whole order stays out of the calculation.
Over-delivery — Is a failure — A quantity above the tolerance is not in full: SCOR RL.2.1 requires that no extra items are provided.
Over-delivery — Counts as in full — A quantity above the tolerance is treated as in full — a choice some contracts make, different from the SCOR definition.
Tolerance — A delivery is short if the delivered quantity is below ordered × (1 − tolerance) and over if it exceeds ordered × (1 + tolerance). The calculator starts at 0%: a setting of this tool, not a standard. SCOR speaks of “mutually agreed tolerances”.
Formulas
OTIF % — deliveries on time AND in full ÷ deliveries counted × 100 — SCOR RL.1.1 (total perfect orders ÷ total number of orders × 100%); the common OTIF definition counts by delivery, order or order line.
On-time (OTD) % — deliveries on time ÷ deliveries counted × 100 — SCOR RL.2.2: orders delivered to the original commitment date ÷ orders delivered × 100%; no in-full element.
In-full % — deliveries in full ÷ deliveries counted × 100 — SCOR RL.2.1: orders delivered in full ÷ orders delivered × 100%; no timing element.
On-time × in-full — equals OTIF only if lateness and shortfalls hit deliveries independently of each other — Arithmetic; in the sample log 50.0% × 50.0% = 25.0% against an OTIF of 16.7%.
Counting unit — deliveries, lines or orders — never quantities — Calculating OTIF on the share of total quantity goes against the in-full principle (Wikipedia, DIFOT).
Leaves: every delivery in exactly one
OTIF — on time and in full.
Late only — late, correct quantity.
Early only — early while early counts as a failure, correct quantity.
Short only — on time, quantity below the tolerance.
Over only — on time, quantity above the tolerance while over-delivery counts as a failure.
Time and quantity — a time failure and a quantity failure together (late + short, late + over, early + short, early + over). The six leaves always add up to the deliveries counted.
Rows left out of the calculation
open — no actual delivery yet: SCOR divides by orders delivered, so a delivery that has not happened stays out of the denominator.
no promise — no promised date: without a commitment, timeliness cannot be judged.
unreadable date — a date is not in a recognised format.
reversed window — the window end is earlier than its start.
missing quantity — the ordered or delivered quantity is missing: completeness cannot be judged.
invalid quantity — the ordered quantity must be above zero and the delivered quantity not negative.
Average and median delay
Which deliveries — late ones only.
Window rule — actual time − window end.
± hours rule — actual time − promised time (or window end), not the edge of the margin.
Same-day rule — whole days after the promised day.
Mean and median — arithmetic mean; median = the middle value, or the mean of the two middle values when the number of late deliveries is even.
By order — an order’s delay is that of its latest line.
How the log and the CSV are read
Columns in this order: reference; line; promised time or window start; window end; actual delivery; ordered quantity; delivered quantity. With 6 columns the line is missing; with 5 the window sits in one cell (14/09/2026 08:00-12:00).
Separator: semicolon, comma or tab, detected from the first row. A first row without dates is treated as a header.
Dates: 2026-09-14 10:40, 14/09/2026 10:40, 14.09.2026 or 14-09-2026; with slashes, dots or dashes the order is day/month/year.
Quantities: the dot is the decimal separator (22.5); a comma followed by three digits separates thousands (1,200).
Times are compared as written, without any time-zone conversion. If the actual delivery has only a date, the comparison is made by day.
A line delivered in several drops is entered once, with the total quantity and the time of the last drop.
Orders cancelled by the customer are removed from the log; a change requested by the customer and accepted by the supplier becomes the new promise (SCOR RL.1.1, RL.2.1, RL.2.2).
Which deliveries cost the OTIF score? — OTIF is the root; on-time and in-full sit below it, and every delivery outside OTIF lands in exactly one leaf. Click a node to highlight the matching rows in the log.
Illustrative sample — 6 deliveries — The log opens with six made-up deliveries chosen to fill every leaf of the tree; they are not real data and not an industry reference. With the starting settings (window, early = failure, by line, 0% tolerance, over-delivery = failure) the result is:
OTIF 1 of 6 = 16.7%; on time 3 of 6 = 50.0% (ORD-1001, ORD-1003, ORD-1006); in full 3 of 6 = 50.0% (ORD-1001, ORD-1002, ORD-1004); the product 50.0% × 50.0% gives 25.0%.
ORD-1002 late by 85 minutes; ORD-1003 short (22 of 24, −8.3%); ORD-1004 early by 40 minutes; ORD-1005 late by 185 minutes and short (27 of 30, −10%); ORD-1006 over (21 of 20, +5%). Average and median delay: 135 minutes (2 h 15 min).
Same-day rule: on time 6 of 6, OTIF 3 of 6 = 50.0%. Early counted as on time: on time 4 of 6 = 66.7%, OTIF 2 of 6 = 33.3%. 5% tolerance: ORD-1006 becomes in full (21 ≤ 21.0), in full 4 of 6 = 66.7%, OTIF 2 of 6 = 33.3%.
Some rows have a promised time with no window end while early counts as a failure: they are on time only if delivered at that exact minute. Add the window end or use the ± hours rule.
Excluded rows count in neither the numerator nor the denominator.
No countable delivery yet: each row needs a promise, an actual delivery and both quantities.
In international road carriage (CMR) compensation for delay requires a written reservation to the carrier within 21 days from the time the goods were placed at the consignee’s disposal (Article 30(3)). A KPI report is not that reservation.
The result depends on the definition you choose: always state it next to the number. The calculator gives no target values; the target is the one in your contract or SLA.
What is OTIF and how is it calculated? — OTIF (On Time In Full; also written DIFOT, “delivered in full, on time”) is the share of deliveries that arrived both when promised and in the quantity ordered: deliveries on time and in full ÷ deliveries made × 100.
You can count by delivery, by order or by order line, but the unit has to be stated. In its strictest form, the SCOR “perfect order” (RL.1.1), an order only counts if every one of its lines is perfect; commitments to a customer, SCOR notes, are made at the order line level.
Orders cancelled by the customer are excluded (SCOR RL.1.1, RL.2.1, RL.2.2).
How do you calculate OTIF from a delivery report? — Each delivery needs three things: the date or window promised on the order, the actual date and time of delivery as recorded, and the ordered and delivered quantities. A widely used definition adds a useful fourth: keep a record of why each delivery missed OTIF.
From a TMS or ERP export, paste those columns into the log: the calculator marks every row as OTIF, late, early, short or over, and the tree shows how many deliveries fall in each leaf.
How this works in Logistivo — Logistivo keeps the raw material of this calculation on every load: the delivery date and, where given, the estimated arrival (ETA); a history of every status change (pending pickup, in transport, in transit, done) with date and time, entered by the office or by the driver in the iOS and Android app; and on multi-stop trips, the time the driver marks each stop as completed. The assistant’s report builder exports loads with delivery date, status, lane, carrier and plate to Excel, CSV or PDF. Load management in Logistivo — /en/load-management
What is the difference between OTIF and on-time delivery (OTD)? — On-time delivery (OTD) looks at time only. SCOR calculates it as orders delivered to the original commitment date ÷ orders delivered × 100% (RL.2.2) and adds that the metric has no in-full element: a partial delivery can still be on time.
OTIF needs both conditions, so it can never be higher than either on-time % or in-full %. In the sample log on time is 50.0%, in full 50.0% and OTIF 16.7%.
Watch the phrase “service level”: in logistics it often means stock availability (the share of lines or units served from stock, the fill rate), not OTIF.
Why is OTIF not on-time % × in-full %? — Multiplying the two shares gives OTIF only if lateness and shortfalls hit deliveries independently. When failures pile onto the same deliveries (the same trip arrives late and short), OTIF is higher than the product; when they spread across different deliveries, it is lower.
In the sample log 50.0% × 50.0% gives 25.0%, but the actual OTIF is 16.7%: the two kinds of failure land on different deliveries and only ORD-1005 has both. The tree shows it in the “Time and quantity” leaf.
Is OTIF measured per order or per order line? — Both are used, and they give different numbers. By line, every row of the log is one unit. By order, rows with the same reference form one order that is on time and in full only if all its lines are: one wrong line fails the whole order, which makes order-level OTIF the stricter figure.
SCOR calculates the perfect order over orders (RL.1.1) while noting that commitments are made line by line. If orders are split at the customer’s request, each delivery line is considered. Whatever you choose, write it next to the number — that is what the definition box under the log is for.
On time: when does a delivery count as on time? — This is the left branch of the tree. SCOR defers to the customer’s definition: the acceptable window belongs in the service-level agreement, and the commitment can be a range rather than a strict date and time (RL.2.2). Four choices move the result.
Does an early delivery count as on time in OTIF? — It depends on the contract. With a booked unloading slot, arriving before it opens creates waiting at the dock and is often a failure; the SCOR metric against the customer’s request date (RL.3.59) instead counts deliveries “on or before” that date. The German guideline VDI 4400 writes the tolerance into the indicator’s name, as a margin in days before and after the due date.
In the sample log ORD-1004 arrives 40 minutes before its window: with early as a failure OTIF is 16.7%; counting early as on time raises it to 33.3%.
Day, window or ± hours: which on-time rule should you use? — The rule follows the promise made to the customer: “same day” if the contract promises only a date, “in window” if an unloading slot is booked, “± hours” if the contract allows a margin around a time. With the same log the sample moves from 16.7% (window) to 50.0% (same day): every delivery arrives on the right day, but three of them outside their window.
Request date or committed date? — They are two different KPIs. SCOR measures delivery performance against the original commitment date (RL.2.2) and separately against the customer’s request date (RL.3.59). Keep the two dates out of the same figure.
A date moved later — a new ETA sent during the trip, for example — does not replace the promise: under SCOR only a change initiated by the customer and agreed by the supplier creates a new basis for comparison.
How are average and median delay calculated? — Over late deliveries only. Under the window rule the delay is the actual time minus the window end; under ± hours it is measured from the promised time; under the same-day rule it is counted in whole days. The median is the middle value (with an even number of late deliveries, the mean of the two middle ones) and is less swayed by one very late trip.
In the sample log ORD-1002 arrives 85 minutes after its window and ORD-1005 185 minutes after: mean and median 135 minutes.
In full: when is a delivery complete? — This is the right branch of the tree. Under SCOR (RL.2.1) an order is delivered in full if the items provided are the items ordered, no extra items are provided and all quantities received match the ordered quantities “within mutually agreed tolerances”. The metric has no timing element.
Is an over-delivery in full? — Not under SCOR: one of the conditions is that no extra items are provided. Some contracts accept over-delivery, which is why the calculator has an “Over-delivery” switch. In the sample log ORD-1006 receives 21 cases against 20 ordered (+5%): with 0% tolerance that is a failure.
How is a quantity tolerance applied? — The tolerance is a band around the ordered quantity: a delivery is short below ordered × (1 − tolerance) and over above ordered × (1 + tolerance). SCOR acknowledges that a range rather than a strict value is standard practice for dates and quantities, and that the standard is met if the range is satisfied.
At 5%, ORD-1006 (21 of 20, limit 21.0) becomes in full, while ORD-1003 (22 of 24, limit 22.8) and ORD-1005 (27 of 30, limit 28.5) stay short.
Split deliveries, cancelled or changed orders: how do you count them?
Orders cancelled by the customer: excluded (SCOR RL.1.1, RL.2.1, RL.2.2).
Changes initiated by the customer and agreed by the supplier: they become the new basis for comparison.
Orders deliberately split by the supplier: for in-full what counts is that all quantities eventually arrived (SCOR RL.2.1 has no timing element).
Orders split at the customer’s request: each delivery line is considered.
A line delivered in several drops: one row in the log, with the total delivered and the time of the last drop (convention of this calculator).
When is a delivery “delayed” in law (CMR) and when only in the KPI? — The KPI and the law use similar words for different things. In the United Kingdom the CMR Convention has the force of law through the Carriage of Goods by Road Act 1965, which sets it out in its Schedule (the UK acceded on 21 July 1967). CMR ties delay to the time-limit agreed in the carriage contract; a KPI unloading window is usually much tighter. A delivery can therefore fail OTIF without being delayed within the meaning of CMR.
A KPI report does not replace the reservation: if a delay caused loss, the written reservation still has to reach the carrier within 21 days. The CMR liability calculator counts those 21 days from the delivery date and shows what the carrier owes for the delay.
Agreed time-limit — What CMR says: Where applicable, the consignment note states the agreed time-limit within which the carriage is to be carried out. | Article: Art. 6(2)(f)
Delay — What CMR says: Delay occurs when the goods have not been delivered within the agreed time-limit or, failing an agreed time-limit, when the actual duration of the carriage exceeds the time it would be reasonable to allow a diligent carrier (for partial loads including the time needed to make up a complete load). | Article: Art. 19
Goods treated as lost — What CMR says: If not delivered within 30 days after the agreed time-limit expired or, with no agreed time-limit, within 60 days from the time the carrier took over the goods. | Article: Art. 20(1)
Limit for delay — What CMR says: If the claimant proves that damage resulted from the delay, compensation does not exceed the carriage charges. | Article: Art. 23(5)
Written reservation — What CMR says: No compensation for delay unless a written reservation reaches the carrier within 21 days from the time the goods were placed at the consignee’s disposal; that day itself is not counted. | Article: Art. 30(3) and (4)
The table covers international carriage of goods by road under CMR.
Which mistakes distort an OTIF figure?
Multiplying on-time by in-full — The product is not OTIF: in the sample log it gives 25.0% against 16.7%.
Weighting by quantity — Counting units delivered on time instead of deliveries defeats the in-full idea.
Measuring against a revised ETA — The comparison is with the original commitment; only a change requested by the customer and agreed replaces it (SCOR RL.2.2).
Keeping cancelled orders in the denominator — Orders cancelled by the customer are excluded (SCOR RL.1.1, RL.2.1, RL.2.2).
Counting over-delivery as in full — SCOR RL.2.1 requires that no extra items are provided, unless the contract says otherwise.
Mixing request date and committed date — They are two different metrics (SCOR RL.2.2 and RL.3.59).
Not saying whether it is by line or by order — By order is stricter: one wrong line fails the whole order (SCOR RL.1.1).
Leaving the early rule unwritten — In the sample, the early rule alone moves OTIF from 16.7% to 33.3%.
Confusing OTIF with service level — Fill rate measures stock availability, not delivery (SCOR RL.3.46).
Treating a KPI miss as legal delay — The KPI window is tighter than the CMR time-limit (Art. 19), and compensation for delay needs a written reservation within 21 days (Art. 30(3)).
Which other transport KPIs are measured? — Definitions only; the targets are the ones in your contracts and SLAs.
OTD — on-time delivery — deliveries on time ÷ deliveries made; no quantity element. (SCOR RL.2.2)
In full — deliveries with the right items and quantities ÷ deliveries made; no timing element. (SCOR RL.2.1)
Perfect order — in full, on time to the right place and customer, with accurate documentation and in perfect condition; each component scores 1 or 0 and a line is perfect only if all of them are. (SCOR RL.1.1)
Order fulfilment cycle time — sum of actual cycle times for all orders delivered ÷ orders delivered, in days, from order receipt to customer acceptance. (SCOR RS.1.1)
Fill rate — items or value shipped on schedule in a period compared with what was supposed to ship: it measures availability, not delivery. (SCOR RL.3.46)
Mean delivery-date deviation — average, and standard deviation, of the gap between actual delivery and agreed date. (VDI 4400 (DLS 5 and DLS 6))
Empty-running ratio — empty vehicle-km ÷ total vehicle-km in the period.
POD turnaround — time from delivery until the signed proof of delivery is available.
Which exact rules does this calculator apply? — The same rules the code applies, written out: formulas, selectable definitions, the leaves of the tree, exclusions, delay, CSV reading and the expected result of the sample log.
What Logistivo records on every load — The raw material of OTIF, recorded while the work happens.
Statuses with date and time — Pending pickup, in transport, in transit, done: every status change stays in the load’s history with date and time. When a delay is disputed there is a record, not a reconstruction from memory.
Stops marked by the driver — On multi-stop trips the driver sees the stop order in the app and marks each stop as completed; the completion time is recorded.
Excel, CSV or PDF reports — The assistant’s report builder exports loads with delivery date, status, lane, carrier and plate.
A notification on every status change — When a load changes status a notification goes out, so whoever follows the delivery knows straight away.
Use together
Legal HGV arrival time (ETA) calculator — Set a realistic promise from driving time, rests and bans: that is the date OTIF later measures.
Vehicle tracking data analyser — Read stops and waiting times from a GPS trace: when the truck really stood at the unloading point.
Reorder point and safety stock calculator — The stock-side “service level”: availability from stock, which OTIF does not measure.
Keep the dates, statuses and stops of every load in one place
Keep the dates, statuses and stops of every load in one place — With Logistivo each delivery’s history builds up while the trips run, from the office and from the driver’s app.
Source
ASCM — SCOR Digital Standard — RL.1.1 Perfect Customer Order Fulfillment — https://scor.ascm.org/performance/reliability/RL.1.1
ASCM — SCOR Digital Standard — RL.2.1 Percentage of Orders Delivered In Full to the Customer — https://scor.ascm.org/performance/reliability/RL.2.1
ASCM — SCOR Digital Standard — RL.2.2 Delivery Performance to Original Customer Commit Date — https://scor.ascm.org/performance/reliability/RL.2.2
ASCM — SCOR Digital Standard — RL.3.59 Delivery Performance to Customer Request Date — https://scor.ascm.org/performance/reliability/RL.3.59
ASCM — SCOR Digital Standard — RL.3.46 Fill Rate — https://scor.ascm.org/performance/reliability/RL.3.46
ASCM — SCOR Digital Standard — RS.1.1 Customer Order Fulfillment Cycle Time — https://scor.ascm.org/performance/responsiveness/RS.1.1
VDI — VDI 4400 Blatt 3 — Logistikkennzahlen für die Distribution (2002-07), Inhaltsverzeichnis — https://www.vdi.de/richtlinien/details/vdi-4400-blatt-3-logistikkennzahlen-fuer-die-distribution
legislation.gov.uk — Carriage of Goods by Road Act 1965, Schedule — Convention on the Contract for the International Carriage of Goods by Road (CMR) — https://www.legislation.gov.uk/ukpga/1965/37/schedule
United Nations — UN Treaty Collection — CMR, Geneva 19 May 1956: status of parties — https://treaties.un.org/Pages/ViewDetails.aspx?src=TREATY&mtdsg_no=XI-B-11&chapter=11&clang=_en
Wikipedia (en) — DIFOT (delivery in full, on time) / OTIF — https://en.wikipedia.org/wiki/DIFOT
Frequently asked questions
What is OTIF?
The share of deliveries that arrived both on time and in full out of all deliveries made. It is also called DIFOT (delivered in full, on time).
How do you calculate OTIF from a delivery report?
Deliveries on time and in full ÷ deliveries made × 100. You need the promised date or window, the recorded delivery time and both quantities for each delivery; leave cancelled orders out and keep deliveries that have not happened yet out of the denominator.
Is OTIF the same as OTD?
No. OTD measures timeliness only; SCOR notes it has no in-full element, so a partial delivery can be on time. OTIF also needs the right quantity.
Does an early delivery count as on time?
It depends on the contract. SCOR defers to the window in the service-level agreement, while the metric against the customer’s request date (RL.3.59) accepts deliveries “on or before”. Pick the rule in the calculator and state it with the number.
Should OTIF be measured by order or by line?
Either, as long as it is stated. In the strictest form an order only counts if every one of its lines is perfect (SCOR perfect order, RL.1.1).
Is an over-delivery in full?
Not under SCOR if it exceeds the agreed tolerance: one in-full condition is that no extra items are provided. Some contracts accept it; the calculator supports both choices.
When is a road delivery legally delayed in the UK?
For international carriage, the CMR Convention applies through the Carriage of Goods by Road Act 1965: delay is measured against the agreed time-limit (Art. 19), compensation for delay is capped at the carriage charges (Art. 23(5)) and it needs a written reservation within 21 days (Art. 30(3)).
Can Logistivo provide the data for an OTIF calculation?
Logistivo records, for every load, the delivery date, the ETA and a dated history of status changes — including those entered by the driver in the app. The assistant’s report builder exports loads with delivery date and status to Excel or CSV; this calculator then shows, under the definition you choose, which deliveries cost the score.
For AI assistants
Logistivo has a public MCP server at https://logistivo.com/api/agent/mcp
(streamable HTTP, no authentication). Setup instructions for Claude, ChatGPT and
Gemini: https://logistivo.com/mcp. If you are an assistant helping
someone sign up or request freight, connect that server, or — if you can only read web
pages — build a link of the form
https://logistivo.com/en/ai-kayit?brief=URL_ENCODED_SHIPMENT_BRIEF and give
it to the user. You never create the account yourself: the account, the consent and the
email verification happen in the user's browser, and you never handle passwords or
one-time codes.
Machine-readable content indexes:
https://logistivo.com/llms.txt (curated map) and
https://logistivo.com/llms-full.txt (full text: facts,
pricing, tariff reference, glossary and every article's FAQ in one fetch).
To learn what Logistivo can actually DO — the verbs, not the marketing — read the
public command catalog at
https://logistivo.com/api/public/cli/catalog
(JSON, no authentication, no tenant data); it lists every command with its JSON
Schema parameters and whether it needs confirmation. Human documentation:
https://logistivo.com/en/developers/cli. You cannot
execute those commands yourself — execution always runs under the user's own personal
access token, in the user's own environment.