A purchase order approval workflow should authorize a specific order version before the buyer releases it to the supplier. The request owner supplies the scope, the budget owner checks the proposed commitment, and authorized approvers record their decisions. The buyer then records transmission separately. A later material change returns to review under the company’s declared policy.
Run this process against the complete order total, current approval limits, and the document that will be sent. An email saying “approved” cannot settle a revised price when it refers to an older version. The controls below are a proposed operating process (including a hypothetical dollar matrix), not a claim that every purchasing application enforces them.
Stage 1: the requester submits a complete version
The requester supplies the supplier, item or service scope, quantities, units, delivery destination, and needed-by dates. Attach the quote and record price, currency, discounts, freight, and tax assumptions. Label estimated charges so the approver can distinguish the proposed amount from a confirmed supplier price.
Give the request and its lines stable identifiers, then freeze a reviewable version with the supporting documents. Retain the cost center, project, business reason, and source requisition. The purchase requisition vs purchase order article covers the separate document handoff; this process checks the order that purchasing intends to release.
The failure to prevent is approval of incomplete or changing scope. Return missing quantities, an unknown supplier, or an unpriced material charge to the requester with a named owner. Do not let a blank amount route as zero or let an attachment change without identifying the version being reviewed.
Stage 2: the budget owner applies the order-total matrix
The budget owner checks the cost allocation and the proposed commitment against the applicable budget. Record the budget period and source used for that check, including existing commitments where policy requires them. A budget review and approval authority answer different questions: available funds do not make every requester an authorized buyer.
Oracle’s purchasing approval documentation describes routing by ordered amount, price, category, and contract terms, with sequential or parallel approvers. Set the equivalent criteria for your company before configuring a tool. Include currency conversion, the effective date of limits, and the treatment of freight and tax in the policy.
Consider this hypothetical US-dollar policy. Its routing amount is the full proposed order after discounts, including freight and tax. Requesters cannot approve their own requests, and a finance approver is a separate person. These are teaching rules, not a recommended universal threshold or a software default.
| Condition in the example policy | Required decision | Evidence retained |
|---|---|---|
| Order total at or below $2,000 | Budget owner approves | Budget reference and decision on the exact version |
| Order total above $2,000 | Budget owner and finance approver approve | Both decisions and the routing rule used |
| Increase of 5% or more from the last approved total | Route the revised total for approval again | Original total, change, reason, and new version |
An order with lines of $1,800 and $600 totals $2,400, even though each line is below $2,000. Both approvers are required under this matrix. Splitting the same known purchase into smaller orders must not bypass that review; have the policy owner define how related requests are grouped and how legitimate separate purchases are documented.
Stage 3: the approver records a decision within current authority
The approver checks the version, amount, allocation, and exceptions before approving, rejecting, or returning it for information. Retain identity, timestamp, decision, and the policy version used. Confirm that the person still has authority for this amount and scope; yesterday’s group membership or a forwarded notification is insufficient evidence.
Microsoft’s Business Central approval setup walkthrough describes approval users, substitutes, and amount limits. Its workflow instructions document delegation and overdue notifications. Those are configured application behaviors, not proof that your tenant’s matrix or separation of duties is correct.
The approval administrator owns substitute coverage and overdue escalation. Require a substitute whose current authority covers the request and who preserves the requester/approver separation. Retain who delegated the item and why. An expired deadline should trigger follow-up or escalation, never silent approval under this process.
If you are selecting a tool, compare its decision history, change controls, and route configuration before its notification channels. The construction purchase order software comparison examines product choices in a project-purchasing setting. Manufacturing teams still need to test their own cost-center, material, and supplier rules.
Explore a purchasing exception view
Use an accessible order export to inspect missing owners, version references, and unresolved approval evidence before expanding the workflow.
Stage 4: the buyer verifies release and supplier transmission
Before release, the buyer compares the outgoing document with the approved version and confirms every required decision is complete. Microsoft’s workflow instructions distinguish a record pending approval from a released record. Your operating process should also distinguish internal release, attempted transmission, and supplier acknowledgment; those states answer different questions.
Retain the order identifier, version, recipient, sent artifact, and transmission reference. If an automated send times out, mark the outcome uncertain and investigate delivery before repeating it. Require a stable send-operation identifier and duplicate checks where the channel supports them. These are implementation requirements, not a guarantee that email or an arbitrary connector provides idempotent delivery.
The buyer owns the unresolved send until there is evidence of failure or delivery. Record supplier acknowledgment separately where required, with the accepted terms or differences. After that handoff, purchase order tracking follows promises and open quantities; approval alone cannot prove that material is on its way.
Scope and committed total
Authority and decision
Sent version and delivery evidence
Stage 5: the change owner reroutes material revisions
The buyer or designated change owner records what changed, why, and which approved version it replaces. Microsoft documents canceling a pending approval, editing the order, and requesting approval again. For already released orders, use the purchasing system’s change process and verify which fields trigger review before sending a revised supplier document.
In the hypothetical $2,400 order, later freight of $120 increases the proposed total to $2,520. The increase is $120 / $2,400 = 5%, which meets the example’s “5% or more” rule and requires reapproval. Retain the last approved baseline so repeated small increases cannot reset the comparison before review.
The policy owner must also name non-amount changes that require review, such as a new supplier, different material specification, or changed delivery destination. A small price difference cannot make those changes safe by itself. Keep both the old and proposed values so approvers can assess the change they are being asked to accept.
Oracle’s purchasing document history separates original-document actions from change-order actions and records who acted and when. Require comparable evidence in your process. Receiving and invoice review should use the effective approved revision, while preserving earlier versions needed to explain deliveries already made.
Permute: purchasing evidence across connected records
Permute sells connected business data and custom software with implementation support. We connect approved records, reconcile order and request identifiers, and implement the definitions your team supplies. An order export in Excel and budget records in SAP can support an exception report once access and field coverage are established.
We preserve source evidence and apply current permissions to the data behind that report. Your declared matrix and version rules can identify orders needing review without asking an AI to invent approval authority. A purchasing manager can inspect the source behind an apparent missing decision and assign the unresolved item to its owner.
Keep approval authority and supplier commitments in the owning process
This reporting workflow reads approved records; it does not grant spending authority, approve a purchase, or send an order to a supplier. Those actions remain in your authorized purchasing process. Any custom action needs separate verification of supported operations, current permissions, approval scope, and execution evidence before it can be promised.
Your procurement and finance owners set the limits, substitutes, emergency path, and reapproval policy. Approval does not establish receipt or payment entitlement, and this process makes no legal claim about when an order becomes binding. Keep receiving and invoice matching as separate controls after the purchasing handoff.
A purchase order approval workflow is complete when the required authority has accepted the exact version being released and the buyer retains evidence of its transmission. Apply limits to the declared total, keep overdue requests unresolved, and route material changes against the last approved baseline. Assign each exception to an owner who can resolve it. Preserve the decision and document history when the order changes.
Scope a purchasing approval-evidence report
Bring an order sample, the authority matrix, and the change policy. We can review which records support the process and which approval or delivery gaps remain.
Questions about purchase approval and release
Can an email be the approval record?
Use the evidence format your policy and purchasing system accept, while preserving the approver, exact version, decision, and timestamp. A notification that a request exists is different from a recorded decision. If the evidence cannot identify the amount and scope approved, return it for clarification before release.
What if the only approver is unavailable and material is urgent?
Escalate through the declared substitute or emergency path instead of treating elapsed time as consent. The replacement decision still needs current authority, requester separation, and retained evidence. The policy owner must resolve a coverage gap before the normal process can release the order.
Should the buyer resend an order after a transmission timeout?
First determine whether the supplier or delivery service received the attempted version. Keep the send outcome uncertain until the buyer has evidence, then document whether a resend is necessary. Reuse the appropriate operation reference and duplicate checks where supported so a retry does not create an unexplained second instruction.