Analyze purchase requisition approval delays from workflow events

Measure requisition delays from workflow evidence, with a clear start milestone and a separate view of still-open requests. A requisition that spends three days gathering missing information is different from a complete request waiting three days for review. Both matter, but they call for different operational actions.

Microsoft's purchase requisition workflow documentation distinguishes submission, review and approval, and supports review at document or line level. The report should reflect the actual workflow granularity rather than assume every requisition follows one linear path.

Define one request and its review cycles

Use one requisition header for the overall request view, with line and workflow-cycle records underneath where required. One request containing several lines should not become several completed approvals in a header-level metric.

Inputs include company, requisition key, line key, requester role, creation, submission, complete-information milestone, workflow task events, returns, resubmissions, final approval or rejection, requested value and cutoff. Keep timestamps with time zones and record the workflow version.

Define what “complete information” means operationally. If the system does not record it, mark it unavailable. Do not infer completeness from the eventual approval or use a convenient later event as an undocumented substitute.

Separate elapsed clocks and outcomes

Measure submission-to-decision duration for completed requests, complete-information-to-decision duration where known, and open age at the cutoff. Label calendar hours and any business-hours version separately, using a stated working calendar.

Returned requests need their cycle history preserved. The total request duration includes all elapsed time, while a stage review may separately identify returned-to-requester intervals. Only subtract those intervals from an approval clock when the chosen reporting policy explicitly permits it.

Rejected, withdrawn and approved requests are different outcomes. A rapid rejection is not a fast approval. Group them separately before calculating durations or interpreting workload.

DEMO: incomplete and open requests

These requisitions and USD requested values are synthetic. Durations use continuous calendar hours, not working hours. The snapshot is October 6, 2026, at 9:00 a.m. Eastern.

B's total submission-to-approval time is 96 hours, including 24 hours before its complete-information milestone. C's 48 hours is an open age and cannot be mixed into the completed-duration average. D's submission age is 96 hours, but its complete-information review age remains unknown.

The four requested values sum to $25,000. That is request value, not committed, invoiced or paid spend. The decision is to inspect B's workflow history, confirm C's next reviewer and obtain D's missing completeness evidence.

Locate the stage rather than blame the approver

Where task events exist, show routing, assignment, acceptance, decision and request-for-information intervals. A task assigned to a role is not necessarily proof that a particular person received or ignored it. Delegations, parallel approvals and escalations can change the interpretation.

For line-level workflows, explain whether overall approval occurs only after every required line is complete. A slow optional or withdrawn line must not be treated as an active bottleneck without checking the rule. Retain unknown routing and conflicting timestamps as exceptions.

Connect approval to downstream populations carefully

The purchase-order, invoice and paid-spend guide explains why an approved request is not an invoice or payment. Use linked downstream records to investigate later stages without adding their dollars into requisition value.

Supplier onboarding lead time concerns getting a supplier through the reviewed registration process. Supplier delivery lead time is another separate clock. A broad purchase-cycle total can hide the particular delay the approval review is meant to address.

Scope a decision-focused review

Start with one workflow version and a defined request population. Reconcile headers, lines, cycles and outcomes, then ask whether missing information, routing or actual review capacity explains the visible age bands.

The procurement software evaluation guide sets the broader buyer context. Use the procurement review example to see a bounded evidence pack, or contact Covirage with the milestones available for a scoped approval-delay review.