Timing a procure to pay cycle honestly is a sobering exercise. The hands-on work across the whole cycle, from raising a request to scheduling a payment, is usually under an hour. The elapsed time is commonly weeks. Almost all of that gap is two specific waits, and both are addressable without changing anything about how the work itself is done.
Wait one: the approval of the request
A request sits with an approver who is busy, away or unaware it is there. This is the wait that determines whether people use the process at all, since a slow request is what sends somebody to buy on a card instead. Named approvers, automatic cover during absence and escalation after a set period remove most of it.
Wait two: the approval of the invoice
The same structural problem at the other end of the cycle, with the same fixes. The difference is that by now a supplier is waiting for money, so the cost of the delay is external as well as internal. Elapsed time here shows up as chasing calls, strained relationships and occasionally lost early-settlement terms.
The wait nobody counts
Between a delivery arriving and its receipt being recorded. Where receipts are batched weekly, every invoice for that period waits a week for no reason anyone would defend. Recording receipts at the point of delivery removes a delay that costs nothing to remove and unblocks matching immediately.
Questions people ask about procure to pay cycle
How do we measure the cycle?
Take fifty recent transactions and record the date of each event: request, approval, order, delivery, receipt recorded, invoice received, approval, payment. The gaps will be obvious.
Which wait should we fix first?
Whichever is longer in your own data. For most organisations it is the invoice approval, but the receipt delay is often the cheapest to remove.
Does software fix these?
It fixes routing, cover and escalation, which is most of it. It cannot make somebody who never opens their queue open it, which is a management question.