Order Cycle Time vs Lead Time in Distribution

Sales promises customers "two-day delivery". The weekly dashboard reports an average order cycle time of 2.5 days and nobody worries. Then a key account sends its own scorecard showing a third of orders arriving late, and the two teams spend a meeting arguing over whose clock is right. Usually both clocks are right; they are simply measuring different things from different timestamps, and one of them is a promise rather than a measurement.

Separating the two terms fixes that argument. Lead time is a duration you set in advance. Order cycle time is what actually happened to each order, measured from defined events in your systems. Once the events, the clock rules and the statistics are written down, the quoted lead time can be set from evidence and the late-delivery dispute disappears.

• What this guide defines: the five timestamps that bound a distribution order, where each comes from, and the rules for start events, split shipments, weekends and time zones.
• What it calculates: mean, median and 90th percentile on a ten-order dataset, the working-capital value of a day of lead time in dollars and rupees, and an SQL query you can adapt.

Lead time is a promise; order cycle time is a measurement

The simplest way to keep the terms apart is to ask when each number exists. A lead time exists before any order is placed: it sits on a price list, a customer agreement or an item master. An order cycle time exists only after a specific order has been delivered, because it is calculated from that order's own timestamps.

Distribution teams use lead time in at least two senses. Quoted lead time is what the customer is told, such as "delivered within three days of order". Planned lead time is a system parameter, such as the transit days held in a transport management system for a lane. Both are targets. Order cycle time is the evidence that tells you whether those targets are realistic.

The inbound mirror of this distinction, where a buyer measures how long suppliers take, is covered in our guide to supplier lead time definition. This article stays on the outbound side: orders your distribution centre receives from customers and delivers to them.

Five timestamps that bound every distribution order

Order cycle time is only as good as the events it is built from. Five timestamps cover almost every distribution flow, and each one should come from a named system field with a stated time zone. If any of the five is typed in by hand, expect arguments about the result.

1. Received: the moment a complete, valid order lands in the order management or ERP system, whether from an EDI purchase order, a portal or a sales rep's entry.
2. Released: the moment the order clears credit, stock allocation and any hold, and becomes eligible for warehouse work.
3. Picked and packed: the last pick or pack confirmation in the warehouse management system for the order or shipment.
4. Shipped: the ship confirmation when the trailer or vehicle departs, which also triggers the advance ship notice or invoice.
5. Delivered: the carrier's delivery event or the time on the signed proof of delivery.

The delivered timestamp deserves extra care because it comes from outside your own systems. Carrier status messages can arrive hours after the event, and some carriers send an estimated time rather than an actual one. Our article on legal proof of delivery explains which delivery records hold up in a dispute, and the same records make the best end point for the cycle-time clock.

Choosing the start event: receipt, release or the requested date

Start the headline clock at order receipt, because that is when the customer's wait begins. Hold releases and requested future dates should be recorded as separate events, so the report can show total elapsed time and the portion your operation controlled, without silently shortening the customer's experience.

Credit holds are the common trap. If the clock starts at release, an order that sat on hold for two days looks fast, and the customer who waited those two days disagrees. Report receipt-to-delivery as order cycle time, and release-to-delivery as a separate fulfilment time used to manage the warehouse and transport legs.

• Customer-requested dates: if a customer orders on Monday for delivery the following Monday, measure against the requested date and report early or late, rather than counting a seven-day cycle as poor performance.
• Order cut-off times: an order received at 14:20 against a 14:00 same-day cut-off will not ship until tomorrow. Keep the true receipt time and let the cut-off show up as a visible delay.
• Incomplete orders: an order missing a ship-to or price is not yet complete. Start the clock when it becomes valid and report the correction time separately.

Splitting the elapsed hours into processing, warehouse and transit legs

A single cycle-time number tells you whether customers waited too long; the legs tell you why. Break every order into order processing, warehouse and transit, and report each leg's median and 90th percentile next to the total, so a rising figure can be traced to its source within one meeting.

Order processing runs from receipt to release and belongs to customer service and credit. The warehouse leg runs from release to ship confirm and belongs to DC operations; the internal steps are described in our warehouse management system process flow guide. Transit runs from ship confirm to delivery and belongs to transport and the carriers.

Order cycle time and its legs, in calendar hours
  OCT        = T_delivered_last - T_received
  Processing = T_released       - T_received
  Warehouse  = T_shipped_last   - T_released
  Transit    = T_delivered_last - T_shipped_last
  Check: Processing + Warehouse + Transit = OCT (tolerance 0.1 h)

Open orders from Little's law (steady state)
  L = lambda x W
  L      = average number of orders received but not yet delivered
  lambda = orders received per day
  W      = mean order cycle time in days

-- SQL: per-order legs and weekly percentiles
SELECT order_id,
       EXTRACT(EPOCH FROM (delivered_last - received_at)) / 3600.0 AS oct_h,
       EXTRACT(EPOCH FROM (released_at   - received_at)) / 3600.0 AS proc_h,
       EXTRACT(EPOCH FROM (shipped_last  - released_at)) / 3600.0 AS wh_h,
       EXTRACT(EPOCH FROM (delivered_last - shipped_last)) / 3600.0 AS transit_h
FROM order_events
WHERE delivered_last IS NOT NULL
  AND received_at >= DATE '2026-11-02' AND received_at < DATE '2026-11-09';

The timestamps must all be stored in one time zone, usually UTC, with the site's local zone kept as an attribute. Subtracting a local delivery time from a UTC receipt time produces errors of several hours that look like real performance changes. Percentiles across the week can then be taken with the database's percentile function on the oct_h column.

Order cycle time in an ERP and WMS reporting model equals delivered-last minus received, stored in UTC, and must equal the sum of processing, warehouse and transit legs within 0.1 hour; any order failing that check points to a missing or overwritten event and is excluded from published percentiles until corrected.

Ten orders worked through mean, median and 90th percentile

Averages hide the orders customers complain about. The ten orders below come from one week at an illustrative US distribution centre with a 14:00 same-day cut-off, and the figures show how the mean, median and 90th percentile tell three different stories about the same week.

The ten cycle times sum to 596.6 hours, so the mean is 59.7 hours, or about 2.5 days. Sorted, the middle two values are both 46.9 hours, giving a median of 46.9 hours, just under two days. Using the nearest-rank method, the 90th percentile is the ninth value, 114.7 hours or 4.8 days. Two orders, one crossing a weekend and one with a backorder, pull the mean well above the median.

• Mean of 59.7 hours: useful for capacity and open-order calculations, misleading as a promise because it is pulled by a few long orders.
• Median of 46.9 hours: the typical customer experience; quoting it as a promise means about half of orders arrive late.
• 90th percentile of 114.7 hours: the figure to test any quoted lead time against, because a promise should hold for nearly all orders.
• Transit dominates: mean transit was 36.9 hours against 22.7 hours from receipt to ship, so carrier and lane choice matter more than pick speed this week.

Split shipments, backorders, weekends and time zones

Edge cases decide whether two analysts reach the same figure from the same data. Write a rule for each before publishing the KPI, apply it in code rather than in a spreadsheet, and keep the excluded or adjusted orders visible in a reconciliation list so nobody can quietly improve the number.

SO-1010 in the dataset shows why the split-shipment rule matters. Eight lines shipped on Thursday and arrived Friday at 10:10, 24.9 hours after receipt. The last two lines arrived the following Tuesday, 121.8 hours after receipt. Measured to first delivery, the week's mean falls from 59.7 to about 50.0 hours. Measured to last delivery, the backorder stays visible, which is what the customer experienced.

• Split shipments: close the order at the last line delivered; report first-delivery time and the share of orders split as separate measures.
• Cancelled lines: if a backordered line is cancelled, close the order at the last delivery of the remaining lines and count the cancellation in fill rate, not cycle time.
• Weekends and holidays: store calendar hours; derive business hours from a DC calendar table. SO-1009 took 114.7 calendar hours but 66.7 hours once the 48-hour weekend is removed.
• Time zones: convert every event to UTC at load time and keep the local zone, so a delivery in another zone is not shortened or lengthened by the offset.
• Undelivered orders: orders still in transit at the reporting cut-off are listed as open with their age, not dropped from the period.

Fill rate and cycle time interact. A distributor that ships complete orders only after backorders arrive will show a high order fill rate and a long cycle time; one that ships whatever is available will show the opposite. Our comparison of line fill rate vs order fill rate explains how to report the fill side so the two KPIs are read together.

Split-shipment orders in order cycle time reporting should close at the last delivered line, recorded in the TMS or carrier POD feed; in an illustrative ten-order week, measuring to first delivery instead cut the reported mean from 59.7 to about 50.0 hours, a 16% improvement that customers never experienced.

Setting a quoted lead time from the measured distribution

A quoted lead time should be the measured cycle time that a chosen share of orders achieves, usually the 90th or 95th percentile for the customer's region and order type. Promising the median guarantees frequent failures, while promising the worst case makes the offer uncompetitive.

In the sample week, a three-day promise of 72 hours would have been met by seven orders out of ten: SO-1006 missed by half an hour, and the weekend and backorder orders missed by much more. A five-day promise would have covered all ten, but a single week is too small a sample. Use at least eight weeks of orders, segmented by delivery zone and by whether stock was available at release.

• Zone segments: quote separately for zones with one-day, two-day and longer carrier transit, because one blended quote fails the far zones every week.
• Stock status segments: quote in-stock orders from the in-stock distribution and give backordered lines a separate date at order entry.
• Review trigger: reopen the quote when the measured 90th percentile for a zone moves more than 12 hours from the quote for three weeks running.

Lead time also has a money value for the customer. A customer that reorders when stock falls to demand during lead time must hold that inventory, so every day removed from a dependable quoted lead time frees one day of demand. The table uses illustrative figures for a US hardware chain and an Indian dealer network served from a Bhiwandi distribution centre.

The last two rows apply Little's law from the formula block: average open orders equal the daily order rate times the mean cycle time in days. That is why finance cares about the mean even though customers care about the 90th percentile. Where revenue is recognised on delivery, every hour of mean cycle time keeps invoiced value in the unbilled or in-transit position at period end, as our article on goods in transit at year-end cutoff explains.

US shipment promises and Indian transit limits that bound the clock

Two rules put outside limits on the clock in this article's two markets. Neither defines order cycle time, but both make the underlying timestamps matter: one sets a default promise to ship in the US, and the other sets how long goods may legally be on the road under one e-way bill in India.

In the US, the Federal Trade Commission's Mail, Internet, or Telephone Order Merchandise Rule, 16 CFR 435.2(a)(1), requires a seller soliciting such orders to have a reasonable basis to expect shipment within the time it states, or within 30 days after receipt of a properly completed order if no time is stated. The period is 50 days where the buyer applies to the seller for credit at the time of ordering.

• The clock in the rule: it runs from receipt of a properly completed order to shipment, which maps to the received and shipped timestamps above, not to delivery.
• Records as evidence: paragraph (a)(4) says that if a seller lacks records showing systems that assure shipment within the applicable time, a rebuttable presumption arises that it had no reasonable basis for its shipping expectation.
• Delay notices: paragraph (b) requires an offer to consent to the delay or cancel for a prompt refund when the seller cannot ship in time.

Shipment-time promises by US mail, internet and telephone sellers fall under 16 CFR 435.2(a)(1), with a 30-day default after receipt of a properly completed order; paragraph (a)(4) presumes no reasonable basis when shipment records are missing, so ERP receipt and ship timestamps should be retained for every order.

India has no equivalent default shipping promise in this sense, but goods moving by road with a consignment value above ₹50,000 generally travel under an e-way bill, and CGST Rules, Rule 138(10), limits its validity. For cargo other than over-dimensional cargo, the bill is valid for one day up to 200 km and one more day for every further 200 km or part. Explanation 1 counts each day as expiring at midnight of the following day.

For a lane from Bhiwandi to Bengaluru of about 980 km, the validity is one day for the first 200 km plus four more days for the remaining 780 km, five days in all. A planned transit lead time of three days fits inside that window. If measured transit on the lane drifts above the validity period, shipments risk moving on an expired bill unless the transporter extends it within eight hours of expiry, as the rule permits.

Which timestamp checks run unattended and which need an analyst

Most cycle-time quality checks are fixed rules that run when events load. Pattern-finding software can help an analyst spot unusual orders or carriers, but it should flag, not change, a timestamp. The table names each check and who handles it.

The trace below shows how a time-zone fault produced a false improvement at one site, and where an automatic rule would have stopped it before the figure reached customers.

1. Sunday 02:00, software change: a WMS upgrade at the Ohio DC alters the nightly export so that it writes Eastern local times with no UTC offset, while the loader still assumes UTC.
2. Monday 09:40, order SO-2214: received in ERP at 14:40 UTC; WMS records ship confirm for shipment SH-88120 at 15:05 local, loaded as 15:05 UTC.
3. Monday 15:05, false leg: the receipt-to-ship leg calculates as 25 minutes instead of 5 hours 25 minutes, and 140 orders that day show similar gains.
4. Friday 11:00, dashboard: the week's warehouse leg median falls by five hours and the site is praised; transit appears five hours longer, so the carrier is questioned.
5. Controlled outcome: an automatic rule comparing WMS ship confirm with the carrier's pickup event, flagging any gap above 60 minutes, catches 140 shipments with five-hour gaps on Monday and holds the site's figure until the export is fixed.

Rollout checklist for publishing order cycle time each week

Publish order cycle time only after the definitions are written, the events are tested and one month of data has been reconciled by hand. The checklist below sets the order of work and the evidence that each step is finished.

Once the report is stable, review the gap between quoted lead time and the measured 90th percentile every month, by zone. More KPI and distribution guides sit on the Logistics and Supply Chain hub. If you need help building the event model and reports across your ERP, WMS and carriers, describe the project on our request for proposal page.