Procurement Cycle Time

A purchasing request reaches procurement on Monday, but an approved purchase order is not released until the following week, which managers call procurement cycle time, though another team may mean the full period through delivery and payment. The start and end events decide what the measure says.

APQC defines a requisition-to-purchase-order release measure and a broader procure-to-pay cycle measure, which are distinct, so a useful report names its segment rather than publishing one ambiguous number of days. Define the path, since requisition-to-order, order-to-receipt and requisition-to-payment cover different responsibilities, and pick timestamps carefully because a request draft may wait for the requester while a submitted complete requisition begins the procurement team's controllable work.

Record the end, since a purchase order approved internally is not necessarily released to the supplier, and use the milestone that matches the process promise. Choose calendar or working days and state the calendar and time zone, because weekends and holidays can change a result.

Segment purchase types, as standard catalogue items and complex construction contracts have different review needs and a blended average can mislead, and track request completeness since missing specifications, budget codes or required approvals can cause delay and time awaiting the requester should be recorded separately. Preserve controls, because faster ordering should not bypass supplier screening, safety review or spending approval, and review approval routing since unclear delegation or a manager away on leave can strand a request.

Measure sourcing time too, as competitive bids, supplier clarification and negotiation may be necessary and a long cycle is not automatically wasted time. Watch contract reuse, since an approved framework agreement can shorten a repeat purchase if prices, scope and validity are confirmed first, and separate supplier lead time because procurement may release a correct order promptly while delivery takes months.

Check emergency purchases, which should be flagged and investigated rather than silently folded into normal-cycle benchmarks, and audit a sample of system queues because duplicate requisitions, missing status updates and integration errors can distort timestamps. Watch supplier onboarding as well, since tax, bank and compliance checks may happen before the order and their duration and quality should be recorded.

Use median and spread, because one unusually complex purchase can pull the mean upward, and report percentiles and sample counts where practical. Track ageing work, since an overall average can look fine while open requests grow old and the current queue should be shown by stage, and report outliers because a single critical request stuck for weeks may matter more than a small shift in the average.

Define exclusions such as cancelled requests, test records and incomplete drafts and show the policy, and after any process change compare like-for-like cycle times and control exceptions, since a faster average alone is not proof of success. Identify handoffs, because finance, legal, security and operations may each have a required review, and map their wait times without treating all review as unnecessary; prioritise bottlenecks, so if legal review dominates time for one category templates may help while if request rework dominates intake guidance should improve.

Check demand planning, since late requests close to a required delivery date create urgency and procurement speed cannot recover lead time already lost, and use automation carefully because catalogue buying and approved supplier data can reduce manual work but exceptions still need human handling. For an owner, procurement cycle time tells where a buying process consumes time, and the useful measure names the milestones, assigns ownership across procurement, requesters and approvers, and checks whether speed still produces the right purchase.