A purchase-request exception workflow starts when a submitted request cannot proceed under the ordinary approval route. It ends with an authorized purchasing instruction, a rejection or a request returned for defined revision. It does not end merely because somebody clicks an approval button.
The software should connect the missing evidence, decision authority and next purchasing owner. Keep supplier negotiation, payment execution and the accounting ledger outside this narrow workflow.
Define the exception before routing it
An incomplete request and a request outside delegated authority are different exceptions. The first needs the requester to supply information. The second needs an authorized decision-maker. Sending both to a senior approver can conceal the real next action.
| Stage | Responsible participant | Handoff record |
|---|---|---|
| Identify exception | Request reviewer | Missing evidence or authority issue |
| Return for revision | Requester | Specific correction and original request reference |
| Resubmit | Requester to reviewer | Revised values and supporting material |
| Make the decision | Authorized approver | Outcome, scope and conditions |
| Hand off to buying | Purchasing owner | The authorized request version |
The organization supplies the authorization policy. This guide does not recommend thresholds or determine who may commit expenditure.
Procurement-native or configurable workflow
Precoro documents approving, rejecting and returning purchase requisitions for revision. Its workflow-setup guide describes approval steps and revision history. It is a candidate where the request already belongs in the purchasing system. Ask to see which changes trigger another review and which version the buyer receives.
Process Street documents approval tasks and stops. It is a candidate for a configurable process layer when the purchasing system remains elsewhere. The team must define how the approved result reaches that system and who investigates a failed handoff. A stop inside the process does not prove that an external purchase-order system is blocked.
Confirm the current package and participant permissions for either route. Documentation identifies capabilities to inspect; it does not establish faster processing or stronger financial controls in your eventual configuration.
Evaluate an amount changed during revision
Use a synthetic purchase request with missing supporting material. Return it to the requester, change its amount and resubmit it. Ask the supplier to show the revised approval route and whether any earlier decision still applies.
Then have the final approver add a condition. Ask the purchasing owner to identify that condition without reading a separate message thread. If the system represents a conditional approval only as a comment, decide whether that is sufficient for your operating model.
Include an absent approver and a rejected request that is later reopened. Record how responsibility is reassigned and whether reopening starts another decision or preserves the earlier outcome. Do not infer either behavior from a happy-path demonstration.
Keep the purchasing instruction authoritative
An approved request should have one clear destination. Copying it into a spreadsheet, task and email without naming the authoritative record can leave the buyer choosing between inconsistent versions. Consolidate the route where the existing procurement system already represents the process adequately.
The Approvals hub separates purchasing authorization from other decisions. For version-specific release rather than expenditure, see creative-asset approval.