Procure-to-pay improvement usually begins by asking how long each step takes and how it could be made faster. That is the wrong first question, and it sends the programme after the wrong target — because in a mature P2P process the touch time is already small and the elapsed time is not.
Nobody spends fourteen extra days working on an invoice. That gap is queue time — documents sitting in an inbox, in a workflow, in a pile, waiting for someone to look. Which means the improvement lever is not speed of work; it is the number and length of the waits.
Measure the cycle in queues
Break the cycle at the points where something changes hands, and record the timestamp at each. Most ERPs already hold these — the difficulty is that nobody has assembled them into one view.
| Segment | From | To | Usually |
|---|---|---|---|
| Request | Need identified | Requisition submitted | Invisible and often the longest |
| Approval | Requisition submitted | Requisition approved | Pure queue time |
| Sourcing | Approved | PO issued | Real work, if sourcing is needed |
| Fulfilment | PO issued | Goods or service received | Supplier lead time |
| Receipting | Received | Receipt entered in system | Pure queue time, frequently days |
| Invoice entry | Invoice arrives | Invoice in system | Short if automated |
| Matching | In system | Matched or excepted | Short for clean, long for exceptions |
| Exception resolution | Excepted | Resolved | The largest single delay |
| Payment approval | Matched | Approved for payment | Queue time |
| Payment | Approved | Paid | Payment run cadence |
The four delays worth attacking
1. Approval routing that goes to unavailable people
Approval time is almost never decision time. It is the wait for someone to open a queue they check twice a week, or the wait for someone on leave whose delegation was never configured.
The measurement that exposes it: time from arrival in an approver's queue to action, per approver. It always produces a small number of names with times an order of magnitude above the rest, and the conversation is far easier with that in hand than as a general complaint about approvals being slow.
The cheapest structural fixes are enforced delegation before leave and auto-escalation after a fixed period. The more consequential one is raising approval thresholds. A £200 purchase requiring two approvals costs more in attention than the purchase, and thresholds set a decade ago have usually not been revisited since.
2. Goods receipting done in batches
Receipting is often treated as administration to be caught up on rather than as a step that unblocks a payment. The delivery arrives Monday, the receipt is entered Thursday, and every invoice against that PO has waited three days for a keystroke.
It also causes exceptions rather than merely delaying them: an invoice arriving before its receipt fails to match and enters exception handling, where it costs materially more to resolve than it would have cost to receipt on time.
3. Exception resolution with no owner
This is the largest delay in most processes, and the reason is structural rather than technical. An exception sits between two teams — AP raised it, procurement or the requisitioner has to answer it — and work that sits between two teams belongs to neither.
The fix is unfashionable: name an owner per exception type, with a turnaround commitment, and report ageing. Not better routing, not smarter matching tolerances. An owner and a date.
4. Payment runs that are too infrequent
A weekly payment run adds an average of three and a half days to every invoice that becomes ready to pay just after one closes. Where early-payment discounts are available, that cadence is what causes them to be missed on invoices that were approved in good time.
Moving from weekly to twice-weekly halves the average wait at close to zero marginal cost. The objection is usually about treasury control over cash timing, which is legitimate — and separable, since payment date can be scheduled independently of when the run is prepared.
Fix the sequence, not the tools
The consistent mistake in P2P improvement is to buy automation for the steps that are already fast. Capture technology reduces invoice entry from minutes to seconds in a cycle where the same invoice will subsequently wait eleven days for an exception to be answered.
- Instrument the cycle first. Ten timestamps, one report, one month of data. Until this exists, every improvement is a guess.
- Rank segments by total elapsed days consumed, not by how inefficient they look.
- Attack queue time before touch time. It is almost always larger and almost always cheaper to fix.
- Only then automate, and automate the segment the data identified rather than the one with the best demo.
- Re-instrument. If the total has not moved, the delay relocated rather than disappeared.
Step five catches the most common false victory in this work. Speeding up one segment frequently moves the queue somewhere else, and the cycle time is unchanged — which only becomes apparent if you measure the whole cycle rather than the segment you improved.
Why cycle time is a staffing problem
Almost every delay above is caused by something not being looked at promptly: a receipt not entered, an exception not chased, an approver not reminded, a query not followed up. None of it is difficult, and all of it is the work that gets displaced when a team is at capacity.
That is why cycle time is one of the metrics that responds most directly to added capacity, and why it is a fair thing to hold an outsourced team to. Chasing is a service level you can write into an agreement, and unlike unit cost it is something the reader of the report — the person waiting on the payment — actually experiences.
Common questions
What is a typical procure-to-pay cycle time?
Ardent Partners' 2025 study puts the average time to process a single invoice at 9.2 days, with Best-in-Class enterprises at 3.1 days against 17.4 for all others. The gap of roughly two working weeks is queue time rather than work time — nobody spends fourteen extra days working on an invoice.
Where does the time in a P2P cycle actually go?
Into waiting. Of ten measurable segments, five are pure queue time: approval routing, goods receipting, exception resolution, payment approval and the payment run cadence. Exception resolution is usually the single largest, because it sits between two teams and therefore belongs to neither.
Which P2P segment is most often unmeasured?
The first — from someone realising they need something to a requisition existing. No system records it, because the clock starts when the requisition is created. It is routinely the longest segment in the cycle and it is almost entirely a function of how difficult the requisition process is to use.
Will automating invoice capture reduce our cycle time?
Only for the segment it touches, which is usually already fast. Reducing invoice entry from minutes to seconds does little in a cycle where the same document then waits eleven days for an exception to be answered. Instrument the cycle first, rank segments by elapsed days consumed, and automate the one the data identifies.
How often should payment runs happen?
More often than weekly, if cycle time matters. A weekly run adds an average of three and a half days to every invoice ready to pay just after one closes, and it is a common cause of missed early-payment discounts on invoices that were approved in plenty of time. Moving to twice weekly halves that wait at almost no marginal cost, and the payment date itself can still be scheduled separately to preserve treasury control.
Sources
Want this run for you?
We take on the transactional half of procurement — invoices, purchase orders, supplier data and indirect spend — inside your own systems and under your approval rules. Start with a free spend audit: we measure your volumes, cycle times and exception rates, and the report is yours whether or not you go further.
Book a free spend audit
