How to Create an On-Time Delivery Report: 6 Quick Checks in 2026

An on-time delivery report answers what looks like one question and is really two. Did we ship when we said we would, and did the parcel arrive when the customer expected? Those have different owners and different clocks. This guide builds a report that separates them, and lists six checks to run before anyone quotes the number.
Why "on time" is not only an internal metric
Most teams treat this as a KPI they set themselves. For anything sold at a distance in the US, part of it is set by regulation.
The Federal Trade Commission publishes a rule on this. Its Mail, Internet, or Telephone Order Merchandise Rule requires a reasonable basis "for stating or implying that you can ship within a certain time." Where no shipment time is stated, you need a reasonable basis for believing you can ship within 30 days. That is why it is often called the 30-day Rule.
Two details in that guidance change how the report should be built.
The clock starts at a specific moment. The FTC states that your obligation "begins as soon as you receive a 'properly completed' order." It defines that as the point you receive correct full or partial payment, "accompanied by all the information you need to fill the order."
That is not always the same as the timestamp your system writes when the order is created.
A promise kept most of the time is not kept. The FTC is asked directly whether a seller can say it ships in 48 hours "most of the time." The answer is that you will then "be required to ship or provide notification of delay in 48 hours all the time."
There is also a shape to the failure path. If you cannot ship in the stated time, you must seek the customer's consent to a delay.
The guidance adds a ceiling on that notice. No notification "can take longer than the time you originally promised," and where no time was promised the limit is 30 days. Fail that and the order must be cancelled with a prompt refund.
Note the word throughout: ship, not deliver. That distinction drives the whole report.
It is also worth checking what the rule leaves out. The FTC lists exemptions covering magazine subscriptions after the first shipment, seeds and growing plants, collect-on-delivery orders, and services. If part of your catalogue falls outside, your on-time delivery report should say which part.
What you need before you start
Four exports, and they usually sit in different systems.
- Orders, with created time, payment confirmation time, and the promise shown at checkout.
- Fulfilment, with pick, pack, and handover timestamps.
- Carrier tracking, with the first scan and the delivery scan.
- Exceptions, covering cancellations, refunds, and delay notifications sent.
You also need one written definition agreed in advance: which timestamp counts as "shipped."
Label created and carrier first scan can differ by a full day. An on-time delivery report that mixes them is not measuring anything stable, and the gap tends to widen exactly when the warehouse is busiest.
How to build the report manually
Option 1: One month of orders in a spreadsheet
Export a month, subtract promise date from ship date, and count how many are negative. This gives you a number by lunchtime.
It also hides the two-clock problem entirely, because a single subtraction cannot tell you whether the delay was yours or the carrier's.
Option 2: Join orders to carrier tracking
Bring the tracking export alongside and match on order ID. Now you can measure your handover separately from transit time.
The friction is the join. Order IDs and tracking numbers rarely map one to one, because split shipments create several tracking numbers for one order.
Option 3: Add the exception data
The complete version brings in cancellations, refunds, and any delay notices. This is what lets the report answer the compliance question rather than only the operational one.
It is also where the afternoon goes, because exception data is usually the least tidy of the four exports.
How to build the report with AI
Step 1: Upload all four exports together
Open Powerdrill Bloom and upload the orders, fulfilment, carrier, and exception files in one workspace. Uploading them together matters, because the joining is most of the work.
Then say in natural language which column holds the promise shown to the customer. Name the timestamp you are treating as "shipped," and the one that marks payment confirmation. Those three definitions decide every number that follows.
Step 2: Ask for the joined table before any percentage
Ask for one row per order carrying: payment confirmed, promise date, handover, first carrier scan, delivery scan, and any exception flag. Ask how many orders failed to match a tracking record.
That unmatched count is your quality gate. Split shipments explain some of it; a large number means the join needs a different key.
Only once the table is right should you ask for rates.
Step 3: Ask for both rates separately, then export
Request two figures rather than one: ship-by-promise rate, measured from payment confirmation to handover, and delivered-by-estimate rate, measured to the delivery scan. Ask for each broken out by carrier and by week.
Export the joined table alongside the summary. Next quarter's report costs an hour instead of a day if this quarter's table still exists. Scheduled tasks are listed on every plan, with one on the Free tier and 20 from Pro upward.
6 quick checks before you publish the number
Check 1: Is the clock starting at the right moment?
Suppose your report measures from order creation, while payment or address confirmation lands later. You are then giving yourself extra time you do not have under the FTC's definition. Measure from the later of the two.
Check 2: Does the stated promise match what the site actually says?
Pull the promise text shown at checkout, not the internal SLA. If the site says 48 hours, the report has to be measured against 48 hours, because that is the representation the rule attaches to.
Check 3: Is "shipped" one event everywhere?
Label created, warehouse handover, and carrier first scan are three different timestamps. Pick one, write it into the report header, and use it in every cut.
Check 4: Are delayed and cancelled orders still in the denominator?
Dropping them is the most common way an on-time rate quietly inflates. An order that was cancelled after a missed promise is a failure, not an exclusion.
Check 5: Is your delay separated from the carrier's?
Two columns, always: handover against promise, and transit against carrier estimate. Combining them produces a number that neither your warehouse nor your carrier can act on.
Check 6: Are delay notifications tracked as their own outcome?
Under the rule, a delay handled with a timely notice and consent is a different outcome from a silent miss. If the report cannot distinguish them, it cannot support a compliance answer.
What belongs in the report
| Metric | How it is derived | Why it matters |
|---|---|---|
| Orders in scope | Count after exclusions are declared | The denominator everything rests on |
| Ship-by-promise rate | Handover against stated promise | The part you control |
| Delivered-by-estimate rate | Delivery scan against carrier estimate | What the customer experiences |
| Median handover hours | Payment confirmed to handover | Shows drift before the rate moves |
| Delay notices sent | Exception export | The difference between a handled and a silent miss |
| Rate by carrier | Tracking export split by carrier | The only view that supports a carrier conversation |
| Split-shipment share | Orders with more than one tracking number | Explains most unmatched rows |
Median rather than mean for handover time. A handful of orders held for stock will drag an average and hide an otherwise healthy week.
Best practices and common mistakes
Report two rates, never one. A single blended figure cannot tell a warehouse problem from a carrier problem, and both teams will dispute it.
Write the definitions into the report header. Which timestamp, which exclusions, which promise source. A reader who cannot see the definitions cannot trust the rate.
Do not quote an average promise. The FTC guidance treats a representation as binding every time it is made, so an aggregate is the wrong frame for a compliance question.
Check what the rule does not cover. The FTC lists exemptions including seeds and growing plants, collect-on-delivery orders, and services. If a chunk of your catalogue is exempt, say so in the report rather than silently mixing it in.
Keep stockouts next to the rate. A missed promise caused by no stock is a planning problem, not a fulfilment one. Our guide to the stockout report covers that side.
Read it beside returns and sales trend. Late shipments show up later as returns and as softer repeat purchase. Our walkthroughs on the product returns report and on turning raw e-commerce orders into a sales trend report cover the adjacent views. Our roundup of e-commerce analytics tools covers the wider tooling. If the source data starts in a workbook, the Excel AI assistant page shows that path.
Conclusion
The useful on-time delivery report is not one percentage. It is two clocks, clearly separated, measured from the moment the order was actually complete, against the promise your site actually made.
Build the joined table first, run the six checks, then calculate. The number you publish after that is one you can defend in an operations review and in a compliance review.
Have the order and carrier exports already? Try Powerdrill Bloom and join them this afternoon.
Frequently asked questions
What is an on-time delivery report?
It is a report measuring how often orders met their promised timing. A complete version separates shipping performance, which you control, from transit performance, which the carrier controls.
When does the shipping clock legally start?
The FTC states the obligation begins when you receive a properly completed order. That means correct full or partial payment, accompanied by all the information needed to fill the order.
Can we advertise a shipping time we meet most of the time?
The FTC's guidance says no. If you represent that you ship in 48 hours, you are required to ship or send a delay notification within 48 hours every time.
Should late-then-cancelled orders count against the rate?
Yes. Excluding them inflates the rate. Track them separately as an outcome, and keep them in the denominator.
What if the carrier caused the delay?
Report it in its own column. The FTC obligations attach to shipping the order, so a carrier transit problem is an operational issue rather than the same measurement.