Purchase Requisition Approval Delay

A team needs replacement parts by Friday, submits a purchase request Monday, but approval waits until Thursday. The supplier cannot deliver on time even if its own lead time is normal, because the delay began internally.

Define a complete submission, since a request missing item specifications, budget code or required justification may need a return-for-information state rather than being measured as an approver idle for days. Oracle's purchasing-workflow guidance describes routing requisitions through approval hierarchies after submission, so the configured path determines who can authorise the spend, and speed does not justify skipping it.

Choose the endpoint, since approved, rejected and sent back each end one approval attempt, but only approved requisitions can move to a purchase order, so report their outcomes separately. SAP's requisition-to-order cycle-time documentation provides a broader procurement clock, of which approval delay is only one part, since sourcing and PO creation can add further time.

An illustrative approved-case duration is approval timestamp minus complete-submission timestamp, so a Monday 9 AM submission approved Wednesday 9 AM took 48 elapsed hours. Show a median, high percentile and open cases, because completed-only averages can hide urgent requests stuck with an absent approver.

Segment by value and category, since a low-value routine replenishment and a high-value capital purchase may have legitimately different controls and expected times. Track each approval stage, because a two-day total caused by a security review requires a different fix from a request that sat unassigned.

Keep reassignment history, since a manager on leave may pass work to a delegate and the system should record the handoff and whether the delegate has proper authority. Separate waiting on requester from waiting on approver, as a returned request can take days to fix and the buyer may still experience the full elapsed time, and avoid resetting the original clock without a reason, because repeated resubmissions can make a long-running request look freshly submitted each time.

Pair the metric with purchase urgency, since a minor delay on a nonurgent need matters less than a one-day delay that forces an expensive expedited shipment, and review process design, because too many serial approvals, unclear thresholds and duplicate checks can create a slow path without stronger control. Do not rush weak requests through, since approvers need sufficient information to prevent wrong purchases or unauthorised spending and a low delay target is not the only goal.

Check budget and policy too, because a rejection may be the correct outcome and the metric should not reward approving inappropriate requisitions just to shorten the cycle. Use timestamps from the source system, since a manually typed date in a spreadsheet can be altered after the fact while workflow events create a stronger audit trail, and watch weekends and time zones, because a Friday-afternoon request can appear old on Monday even when the approval team works only business hours, so state the chosen clock.

Assess downstream effects such as stockouts, lost discounts and project delay to decide which queues deserve attention first, test an improvement such as an alternate approver for leave periods across comparable subsequent cases, and set an escalation threshold before a requested need date becomes impossible, considering supplier lead time and any safe substitute rather than a generic number of hours. Review a sample of rejected cases for clarity, since a quick rejection without useful explanation can send the requester through another slow cycle, and remember that for an owner approval delay shows how much time is spent before procurement can act and should expose real bottlenecks without weakening spending controls.