How do I measure on-time delivery correctly?
Key Takeaways
- On-time delivery means nothing until you decide "on time to what." The promised date, the delivery appointment and the customer's requested date are three different targets, and they give three different numbers.
- Write the definition down, including the tolerance, how early deliveries count and which loads are excluded, and use it the same way every month.
- The number is only as good as the delivery times behind it. Use the signed POD or a carrier event with a timestamp, not the date someone updated the order.
- Measure pickup as well as delivery. A late delivery that started with a late pickup has a different cause and a different fix.
- Break the number down by carrier, lane and customer. One company-wide percentage hides the lanes and customers where service is actually failing.
- Wilson, by Cartage, is an AI logistics agent that tracks each load, records pickup and delivery times and can produce carrier-performance reports on request from the loads it runs.
What does on-time delivery actually mean?
The monthly operations meeting starts with one slide. Sales says on-time delivery was 91%. Customer service says customers are complaining more than ever. The warehouse says it shipped everything on the day it was supposed to. Logistics says the carriers delivered within their transit times. All four are telling the truth. They are just measuring different things.
To measure on-time delivery correctly, first decide what "on time" means (the date promised to the customer, the delivery appointment or the customer's requested date), set a tolerance, take delivery times from a reliable source such as the signed POD or a carrier delivery event, apply the same exclusions every time, measure pickup as well as delivery, and break the result down by carrier, lane and customer. A precise definition turns on-time delivery from a number people argue about into one they can act on.
Three targets, three numbers
The same delivery can be on time against one target and late against another.
- Promised date. The date your company committed to the customer when the order was confirmed. This measures whether you kept your word.
- Delivery appointment. The date and time window set with the receiver. This measures whether the carrier arrived when the dock expected it.
- Requested date. The date the customer originally asked for. This measures whether you met the customer's need, which may be earlier than what you promised.
Consider a hypothetical order the customer requested for Monday. Your team promised Wednesday because of stock. The appointment was set for Wednesday at 10 a.m. The truck arrived Wednesday at 1 p.m. Against the requested date, it's two days late. Against the promised date, it's on time. Against the appointment, it's three hours late. None of these is wrong. They answer different questions.
Which one to use
Most companies need more than one, used for different purposes. The promised date is the main customer-facing measure. The appointment is the main carrier-facing measure. The requested date shows how often the company can't meet what customers ask for, which is a planning and inventory question more than a logistics one. Pick a primary measure for each audience and label every report with the target it uses.
On time and in full
Many customers, especially retailers, measure "on time in full" (OTIF): the order arrived on time and with every item and quantity ordered. A delivery can be on time and short, which fails OTIF. If your customers measure OTIF, measure it yourself the same way, so their scorecard doesn't surprise you. Retailers often attach penalties to it; see avoiding retailer chargebacks for late shipments.
How do you set up an on-time measure step by step?
Write the definition, choose the data sources, set the exclusions and run the same calculation every period. The steps below take a few hours to set up and save months of arguments.
Step 1: Write the definition
A written definition should answer each of these:
- Which target: promised date, appointment or requested date?
- What counts as delivered: the time the truck arrived, the time unloading finished or the time the POD was signed?
- What tolerance: same day, within the appointment window, within an hour?
- Do early deliveries count as on time?
- Is the measure per shipment, per order or per order line?
- Which loads are excluded, and who approves an exclusion?
Step 2: Choose the tolerance
For deliveries without appointments, "on or before the promised date" is common. For appointments, many companies count arrival within the appointment window, or within a short grace period after it. Whatever the tolerance, use the same one for every carrier and every month. Changing it mid-year makes the trend meaningless.
Step 3: Decide how early deliveries count
Early isn't always good. A receiver with a tight dock schedule may refuse or charge for an early truck. A retailer may count early as a failure. For most B2B freight without appointments, early is fine. For appointment-based deliveries, decide whether arriving before the window counts as on time, and say so in the definition.
Step 4: Pick the unit
Measuring per shipment is simplest. Measuring per order matters when an order ships in several parts, because the order isn't complete until the last part arrives. Measuring per line matters for OTIF. Pick the unit that matches the question. A company that ships many split orders will get a much higher number per shipment than per order.
Step 5: Choose the data sources
List where each date and time will come from. The promised date usually comes from the ERP order. The appointment comes from the scheduling record or the carrier. The actual delivery time comes from the signed POD, a carrier delivery event or GPS data. Write down which source wins when two disagree.
Step 6: Set the exclusions
Decide in advance which late deliveries won't count against the carrier or the company, and record every exclusion with a reason. More on this below.
Step 7: Test the definition on last month's loads
Before publishing anything, run the new definition on a month of past loads and look at the late ones one by one. Do the results match what the team remembers? Are there late loads that were really the receiver's doing, or on-time loads that customers complained about? A test like this exposes gaps in the data and holes in the exclusion rules while they are still cheap to fix. Adjust the definition once, agree it with sales and customer service, and then freeze it.
Step 8: Run it the same way every period
Calculate the number on a fixed schedule, with the same definition and sources. Publish it with the definition on the report. When someone asks why it changed, the answer should be about performance, not about method.
Where should the data come from, and what should be excluded?
Use the most reliable timestamp available for each delivery, and exclude only what you've agreed to exclude, with a reason on the record.
Delivery time sources
| Source | What it shows | Reliability | Watch for |
|---|---|---|---|
| Signed POD | Delivery date and often time, receiver's signature | High for date; time varies | Missing times, illegible entries, late arrival of the document |
| Carrier delivery event (API or EDI) | Delivery status with a timestamp | Usually good | Events entered late, or at the terminal instead of the dock |
| GPS or ELD data | Truck location and arrival at the site | High for arrival time | Arrival is not the same as unloaded |
| Carrier website by PRO | Delivery status and date | Moderate | Time often missing; status can lag |
| Receiver's dock records | Check-in and check-out times | High, if you can get them | Not always shared |
| Order status in the ERP | Date someone marked the order delivered | Low | Often the day it was updated, not the day it arrived |
The most common error is using the date the order was closed in the ERP as the delivery date. That date reflects when someone in the office caught up on paperwork, not when the truck arrived.
Missing data
Some deliveries will have no reliable time. Don't quietly drop them, because the loads with missing data are often the ones with problems. Track how many deliveries have no reliable delivery time, chase the POD or carrier record for them, and report the share alongside the on-time number. If a large share is missing, the on-time number isn't trustworthy yet.
Exclusions
Some late deliveries aren't the carrier's fault or yours. Common exclusions include:
- The receiver was closed, refused the appointment or moved it
- The customer asked to delay delivery
- Severe weather or a road closure the carrier couldn't avoid
- The order changed after pickup, such as a new address
- The freight was held for paperwork the customer was responsible for
Every exclusion should have a reason code and a named person who approved it. Without that discipline, exclusions grow until the number is meaningless. A useful check: report the number of excluded loads every period. If exclusions rise while on-time also rises, look closely.
Multi-stop loads and split orders
Multi-stop truckloads need a rule: is the load on time if the last stop is on time, or does each stop count separately? Measuring each stop is more honest, because each stop is a different receiver with its own appointment. Split orders need a similar rule. If an order ships in three parts, record each shipment's delivery, then mark the order on time only when the last part arrives by the promised date. Without these rules, a load with one late stop out of four, or an order with one late part out of three, can look fully on time.
Customer-caused vs carrier-caused vs company-caused
When a delivery is late, record the cause along with the fact. The three big buckets are carrier (missed pickup, transit delay, misrouting), company (freight not ready, late order release, wrong paperwork) and customer or receiver (closed dock, moved appointment, refused delivery). The overall on-time number shows the customer's experience. The cause split shows who needs to fix what.
Why measure pickup too, and what errors distort the number?
A late delivery often starts with a late pickup. Measuring pickup separately shows where the delay actually began.
On-time pickup
Define on-time pickup the same way: the scheduled pickup date or window, a tolerance and a reliable source for the actual pickup time. The sources are similar: the signed BOL, a carrier pickup event, GPS data or your own dock records. If a carrier picks up late but still delivers on time, the transit was fast. If it picks up on time and delivers late, the problem is in transit. If it picks up late and delivers late, the problem may be at the carrier's dispatch or at your dock.
Why freight wasn't ready
Not every late pickup is the carrier's fault. If the truck arrived on time and the freight wasn't ready, record that. It's a company-caused delay, and it often explains a share of "carrier" lateness. Measuring freight readiness at pickup time separates the two.
Break it down
One company-wide number hides the problems. Break on-time delivery down by:
- Carrier, to see who performs and who doesn't
- Lane, because one carrier can be strong on one lane and weak on another; see comparing carrier on-time performance by lane
- Customer, because some receivers cause delays and some customers matter more
- Mode, because LTL, truckload and parcel have different norms
- Origin, if you ship from more than one plant or warehouse
A small number of lanes or customers usually explains most of the late deliveries. Fixing those moves the overall number more than any company-wide initiative.
Common errors
- Using the ERP close date as the delivery date. It measures paperwork, not delivery.
- No written definition. Each team calculates its own number, and meetings turn into arguments.
- Changing the definition or tolerance mid-year. The trend becomes meaningless.
- Dropping loads with missing data. The missing loads are often the late ones.
- Unlimited exclusions. Without reason codes and approval, the number drifts upward with no change in service.
- Counting shipments when the customer counts orders. Split orders make the shipment number look better than the customer's experience.
- Measuring delivery against the carrier's transit time instead of your promise. The carrier can be on time while the customer still gets the order late.
- Ignoring pickup. Late deliveries get blamed on carriers when the freight wasn't ready.
- Small samples. A lane with five loads a month can swing from 100% to 60% on one bad week.
Transit time next to on-time
On-time percentage says how often freight arrived when expected. It doesn't say how long it took. Track average transit days by lane alongside on-time, because a carrier can stay on time by quoting long transit times. If one carrier delivers on time in five days and another in three, the first one may look better on the report while serving customers worse. Showing both numbers side by side stops the on-time figure from rewarding slow promises.
Promises logistics can't meet
Sometimes the on-time number is low because the promise was unrealistic from the start: a date sales gave without checking transit times, carrier schedules or appointment lead times. Measuring against the promised date makes this visible. The fix is upstream; see when sales promises delivery dates logistics can't meet.
What should an on-time delivery report include?
A good report states its definition, shows the number with its sample size and splits it by cause, carrier, lane and customer. The table below is a template.
| Section | What it shows | Why it matters |
|---|---|---|
| Definition | Target, tolerance, unit, early rule | Anyone reading knows what was measured |
| Overall on-time delivery | Percentage and number of deliveries | The headline, with its sample size |
| On-time pickup | Percentage and number of pickups | Shows where delays begin |
| Data coverage | Share of deliveries with a reliable timestamp | Shows how far the number can be trusted |
| Exclusions | Number excluded, by reason | Keeps exclusions honest |
| Late by cause | Carrier, company, customer or receiver | Shows who needs to act |
| By carrier | On-time and volume per carrier | Feeds carrier conversations and tenders |
| By lane | On-time per lane, with volume | Finds the problem lanes |
| By customer | On-time per customer | Shows where customers feel it most |
| Trend | The last six to twelve months | Shows whether changes are working |
A monthly checklist
- Pull all deliveries for the period with promised date, appointment, requested date and actual delivery time.
- Fill gaps in delivery times from PODs or carrier records.
- Record the share of deliveries still missing a reliable time.
- Apply exclusions with reason codes and approvals.
- Calculate on-time delivery and on-time pickup with the written definition.
- Assign a cause to every late delivery.
- Break results down by carrier, lane, customer and mode.
- Compare with previous months and note what changed.
- Share the report with the definition on the first page.
- Pick the two or three lanes or customers to work on next month.
A hypothetical example
Consider a hypothetical manufacturer that reports 94% on-time delivery using the date orders were closed in its ERP. Customer complaints don't match that number, so the logistics manager rebuilds it. Using POD delivery dates against the promised date, per order rather than per shipment, the number falls to 83%. The cause split shows that about a third of late deliveries started with freight that wasn't ready when the truck arrived. Two lanes account for nearly half of the remaining carrier-caused lateness. The team fixes the order release process at the plant and moves one of the two lanes to a different approved carrier. Three months later, the honest number has climbed, and customer complaints have dropped with it. The company's reported number went down before it went up, and that was the point.
Who should own the number
One person or team should own the definition and the calculation, usually logistics, with sales and customer service agreeing to the definition once. Ownership means deciding exclusions, fixing data gaps and answering questions about the method. When nobody owns it, every department builds its own spreadsheet and the meeting from the start of this article happens every month.
Using it in carrier conversations
Once the number is reliable, use it in regular carrier reviews and in the next tender. Show each carrier its own late loads, with dates, causes and the evidence from the POD or tracking events, and ask what it will change. Give credit for improvement as well as pointing out problems. Carriers that see a fair, consistent measure tend to take it seriously, and the conversation moves from arguing about data to fixing lanes.
Sharing the number
Share on-time delivery with leadership monthly, with the definition, coverage and cause split attached. For the wider set of numbers worth reporting, see what to report to leadership about logistics each month. Share carrier-level results with each carrier, using the same definition you use internally, and ask them to explain their late loads. Carriers respond better to clear data than to general complaints.
How does Wilson, by Cartage, help measure on-time delivery?
Wilson, by Cartage, is an AI logistics agent that books, tracks and follows up on freight for manufacturers and distributors, so the pickup and delivery times behind an on-time number are recorded on each load as it moves. Traditional logistics software gives teams information. Wilson executes the work required to move shipments forward.
Here's how Wilson supports a reliable on-time measure:
- Tracking with the best available source. Wilson tracks each load with the best source available for that carrier: carrier API or EDI, GPS or ELD data where the carrier shares it, the carrier's website by PRO number, and email or phone calls when nothing else is current. Pickup and delivery events are recorded on the load.
- Collecting PODs. Wilson requests and files the signed POD after delivery, so the delivery date comes from the document, not from the day someone updated the order.
- Recording exceptions as they happen. When a pickup is missed, a load is cancelled or a delivery is delayed, Wilson contacts the carrier, tells the team in Slack, Microsoft Teams or email, tells the customer if configured, and records what happened. That record is what a cause code is based on later.
- Reports on request. Wilson doesn't keep a permanent scorecard or run recurring benchmarking by default. It can produce carrier-performance and lane-rate reports on request from the loads it runs, with the definition the team chooses.
- Keeping the history. Every message, confirmation and change is kept in the shipment's change history, so when a carrier disputes a late delivery, the timestamps and messages are on the load.
Wilson also quotes, books with written acceptance and a rate confirmation, schedules pickups, generates bills of lading, packing slips and pallet labels, and audits each carrier invoice against the rate confirmation and POD before paying from the Wilson Wallet. It books only carriers the company has approved, across LTL, FTL, ocean, drayage, parcel and cross-border freight.
Teams use Wilson's dashboard and records the way they would use a TMS. Wilson replaces the TMS for freight execution and connects to the company's ERP. Wilson works with SAP, NetSuite, Microsoft Dynamics 365, Oracle, Infor, Epicor, Sage, Acumatica and other ERP environments, with the exact connection depending on the customer's data flow and scope. Whether delivery dates are written back to the ERP depends on scope.
Pricing
Wilson is free on Wilson's network: the shipper pays the freight rate and nothing on top. When a shipper keeps its own carriers, the fee is 2% to 0.5% of what Wilson pays them, falling with volume. There are no seat fees, no setup cost and no contract. Timing depends on scope: most teams start on a few lanes and expand from there.
FAQs
How do I measure on-time delivery correctly?
Decide which target you measure against (promised date, appointment or requested date), set a tolerance, use reliable delivery times such as the signed POD, apply consistent exclusions, measure pickup too and break results down by carrier, lane and customer. Wilson, by Cartage, an AI logistics agent, records pickup and delivery times on each load and can produce carrier-performance reports on request.
What is the difference between on-time delivery and OTIF?
On-time delivery measures whether the shipment arrived on time. OTIF (on time in full) also requires that every item and quantity ordered arrived. A delivery can be on time but short, which fails OTIF.
Should early deliveries count as on time?
It depends on the receiver. For most B2B deliveries without appointments, early is fine. For appointment-based or retail deliveries, early may be refused or penalized, so decide the rule and write it into the definition.
What is a good on-time delivery percentage?
It depends on your definition, mode and customers, so compare against your own trend and your customers' requirements rather than a general benchmark. A precise, honest number that improves is more useful than a high number nobody trusts.
Where should the delivery date come from?
From the signed POD, a carrier delivery event with a timestamp or GPS data. Avoid using the date an order was closed in the ERP, which reflects paperwork rather than delivery.
Which late deliveries can be excluded?
Common exclusions are receiver closures, customer-requested delays, severe weather and order changes after pickup. Each exclusion should have a reason code and an approver, and the number of exclusions should be reported.
Why measure on-time pickup?
Because many late deliveries start with a late pickup, and some late pickups are caused by freight that wasn't ready. Measuring pickup separately shows where the delay began and who needs to fix it.
Should we measure per shipment or per order?
Per order if your orders often ship in parts, because the customer experiences the order, not the shipment. Per shipment is fine for carrier performance.
How often should we report on-time delivery?
Monthly for leadership and carriers, with the definition, data coverage and cause split attached. Look at problem lanes and customers more often if they matter to the business.
Does Wilson keep a carrier scorecard?
Not by default. Wilson can produce carrier-performance and lane-rate reports on request from the loads it runs, and every load's pickup and delivery records stay in its change history.
Sources
- Cartage, Wilson product FAQ and product scope, October 2026: https://cartage.ai