The Procure to Pay Cycle: Stages, Timings, Best Practice

Most guides describe the procure to pay cycle as a sequence of stages. This one treats it as something you measure and shorten. If you cannot say how many days pass between a requisition being raised and an invoice being paid, you cannot tell whether a change helped. What follows defines cycle time and its three sub-cycles, shows how to baseline each one honestly, identifies where time actually disappears, sets out the handful of metrics worth reporting, and lays out a practical programme for cutting the cycle down.

What procure to pay cycle time actually measures

Procurement as a discipline covers sourcing, negotiation, contracting and buying. The procure to pay cycle is the operational slice of that work: the run from a need being recognised to a supplier being paid for meeting it. Cycle time is the elapsed calendar time across that run. It is deliberately a blunt measure. It does not care whether the delay came from an approver on annual leave, a missing goods receipt or a bank cut-off. It simply records how long the organisation took, which is exactly what the requester and the supplier experience.

The instinct in most finance teams is to report an average. Resist it. Cycle time distributions are almost always skewed, with a dense cluster of fast transactions and a long tail of stalled ones. An average sits somewhere in the empty space between the two and describes nothing real. Report the median so you know what a typical transaction looks like, and report a high percentile, usually the ninetieth, so you know how bad the tail is. Improvement work then has two clear targets: pull the median down, and cut the tail off.

One more definition matters before you start counting. Decide whether you are measuring the cycle from the requisition date or the contract date, and whether you stop at payment initiation or at cash actually leaving. Either choice is defensible. Changing the choice halfway through a measurement programme is not, because it makes your trend line meaningless. Write the definition down and put it next to the number wherever it is reported. If you want the underlying stage detail first, our procure to pay guide covers the full cycle end to end.

Breaking the cycle into three sub-cycles

A single end to end number is useful for reporting and useless for improvement. Split it into three sub-cycles, each with a clear owner and a distinct failure mode. The split works because the causes of delay in each are unrelated, so the fixes are unrelated too.

Notice that the middle sub-cycle contains supplier lead time, which is largely outside your control. That is a good reason to measure it separately rather than let it inflate a combined figure and make your internal performance look worse than it is. Strip lead time out and what remains in that sub-cycle is receipting discipline, which is very much yours to fix. A purchase order that sits received but unrecorded for a week will surface later as a matching exception, and by then it costs far more to resolve.

How to baseline each sub-cycle honestly

Baselining is where measurement programmes usually go wrong, because the temptation is to clean the data until the numbers look sensible. Do the opposite. Pull one full quarter of completed transactions, exclude nothing, and look at what you get. Impossible records, such as an invoice dated before its order or a receipt logged after payment, are not noise to be discarded. They are a map of where your timestamps are unreliable, and unreliable timestamps are themselves a cause of delay.

Work through the baseline in this order. First, confirm which system holds the authoritative timestamp for each event, because the same event often has three different dates across three systems. Second, plot the distribution for each sub-cycle rather than computing a single figure. Third, segment by category, supplier and value band, since a low value repeat purchase and a capital item have nothing in common and averaging them together hides both. Fourth, look at the slowest ten per cent of transactions individually and write down why each one was slow. That list of reasons, not the headline number, is what tells you where to start.

Where time is actually lost

When teams first look at their sub-cycle data, the finding is nearly always the same in shape: the work itself takes minutes and the cycle takes days. The gap is queue time. A requisition waits for an approver to open their inbox. An invoice waits for a cost centre owner to confirm the coding. A payment waits for the next scheduled run. None of that is anybody working slowly. It is work sitting still.

Queue time concentrates in a few predictable places. Approval chains with more steps than the value justifies create a queue at each step. Requisitions submitted without a clear specification bounce back to the requester and rejoin the queue at the end. Invoices that fail to match an order or receipt drop into an exception pile that is worked in batches rather than continuously. And where receipting is done weekly rather than at the point of delivery, every invoice arriving in between is guaranteed to fail matching for reasons that have nothing to do with the supplier.

The practical consequence is that speeding people up achieves very little. Removing the wait achieves a great deal. That is why touchless processing matters more than any individual efficiency measure: each touch you remove removes a queue, and each queue removed takes hours or days out of the cycle rather than minutes.

The KPIs worth tracking

Five measures cover the cycle well. Track them together, because each one can be improved at the expense of another if it is watched alone. Do not import benchmark figures from elsewhere and treat them as targets. Your categories, supplier base and approval culture are your own, so your baseline is the only meaningful comparison and your trend is the only meaningful result.

That last metric deserves emphasis because it converts an operational number into a financial one. If accounts payable routinely approves invoices after the discount window has closed, the discount terms you negotiated are decorative. Measuring capture rate makes the cost of a slow cycle visible to people who do not otherwise care about process metrics, which is usually what unlocks the budget to fix it.

Building a measurement routine you can trust

A number reported once is a curiosity. A number reported on the same definition every month is a management tool. Set a monthly cadence, keep the definitions frozen, and publish the same view to the same audience each time. Include the segment breakdown, not just the total, so a good month in low value purchases cannot disguise a bad one in complex categories.

Two habits keep the routine honest. The first is reviewing the slowest transactions every month by name rather than in aggregate, because patterns show up in individual cases long before they move a median. The second is recording the reason for every exception in a fixed, short list of causes rather than free text. Free text cannot be counted. A dozen standard reason codes can be, and after three months the ranked list of causes will tell you precisely what to fix next.

A practical programme to cut cycle time

Once you have a baseline and a reason-code list, the improvement work is fairly mechanical. Run it in this order, since each step makes the next one easier:

• Fix the front door. Most delay is created at requisition, where an incomplete or badly specified request guarantees rework. Guided forms with mandatory fields and preferred suppliers cut the bounce-back rate immediately.
• Right-size approvals. Set thresholds so low value, on-contract purchases need one approval or none. Reserve multi-step chains for the transactions that genuinely warrant them.
• Receipt at the point of delivery. Move goods receipting from a weekly batch to the moment of arrival, on a mobile device if necessary. This one change usually lifts first-time match rate more than anything else.
• Automate matching. Two and three way matching against order and receipt should be the default path, with tolerances set so trivial variances do not create human work.
• Work exceptions continuously. Route each exception to a named owner with a target resolution time instead of letting a queue accumulate for a weekly clear-down.
• Schedule payment runs against discount windows. A run timed a few days earlier can convert a whole category of missed discounts into captured ones without any process change.
• Rebaseline every quarter. Recompute the same measures on the same definitions and publish the movement, including where nothing improved.

Sequencing matters more than it appears. Automating matching before receipting is fixed simply automates the production of exceptions. Tightening approvals before the requisition form is fixed pushes rework upstream where it is less visible. Work from the front of the cycle backwards and each fix compounds.

What an instrumented cycle looks like

When the cycle is properly instrumented, the conversation changes character. Instead of arguing about whether procurement is slow, the team looks at a chart showing that requisition to order improved by four days while invoice to payment did not move, and directs effort accordingly. Instead of a supplier complaint triggering a search through mailboxes, the transaction record shows exactly which queue it sat in and for how long. The measurement itself does not shorten anything, but it makes every subsequent decision evidence-led rather than anecdotal.

Getting there needs the timestamps to exist in one place, which is the practical argument for running the whole cycle on a connected platform rather than across disconnected tools. ProcureWave records each event once, from requisition through order, receipt and invoice to payment, so sub-cycle timings and exception reasons come out of the system rather than a manual reconstruction. If you are choosing tooling, our guide to procure to pay software covers what to look for, and the solution overview shows how the pieces fit together.

Start with the baseline. One quarter of data, three sub-cycles, a median and a ninetieth percentile for each, and an honest list of why the slowest cases were slow. That afternoon of work will tell you more about your procure to pay cycle than any benchmark report, and it gives you the starting line every later improvement is measured against. If you would like a walkthrough of how the timings look once the cycle runs in one place, get in touch and we will show you.

Frequently asked questions

What is procure to pay cycle time?

Cycle time is the elapsed time between the first event in the cycle and the last, usually measured from the moment a requisition is raised to the moment a supplier invoice is paid. It is measured in calendar days rather than working hours, because suppliers and budget holders experience calendar time. Most teams report a median alongside the average, since a handful of very slow cases will drag the average somewhere unhelpful.

Which sub-cycles should I measure separately?

Three: requisition to purchase order, purchase order to goods receipt, and invoice to payment. Each has a different owner, a different failure mode and a different fix, so measuring only the end to end total tells you that something is slow without telling you what. Splitting the cycle is the single most useful measurement change most teams make. Our procure to pay process guide walks through what happens inside each stage.

How do I baseline cycle time if my data is messy?

Start with one quarter of completed transactions, exclude nothing at first, and plot the distribution rather than the average. Messy data usually shows up as impossible values, such as invoices paid before the order date, and those records tell you where your timestamps are unreliable. Fix the worst timestamp problems, then rebaseline. A rough baseline you trust beats a precise one you do not.

What is a touchless rate and why does it matter?

Touchless rate is the share of transactions that pass from requisition to payment without a human intervening beyond the initial approval. It matters because it is the clearest leading indicator of cycle time. Every touch adds queue time, and queue time, not processing time, is what makes cycles long. Raising the touchless rate almost always shortens the cycle without anyone working faster.

Should I chase cycle time or cost per purchase order first?

Cycle time, in most cases. Cost per purchase order is largely a function of how much human handling each transaction needs, so removing handling to shorten the cycle usually reduces cost as a side effect. Chasing cost directly tends to push teams toward cutting controls, which is a poor trade. Shorten the cycle by removing rework and waiting, and the cost figure follows.