Finance Index
How do I revise a purchase order after it's been issued - what is the PO change order process?
Reference guide to PO revisions change orders, including request intake, purchasing controls, approval routing, vendor coordination, and finance visibility.
Revise the PO in the system, never around it: open a revision, make the change, route it through re-approval appropriate to the change's size, and reissue to the vendor with the revision clearly identified. Every version stays in the record. The test of a healthy change process is that anyone can answer "which version is the vendor working from, and who approved the difference?"
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Revise a purchase order after | Revise the PO in the system, never around it: open a revision, make the change, route it through re-approval appropriate to the change's size, and reissue to the vendor with the revision clearly identified. | Keeps vendor records and payment decisions reliable. |
| Approval path | Re-approve anything that changes the financial commitment or the counterparty: amount increases beyond a small tolerance, quantity increases, vendor changes (which should really be a new PO), and scope additions. | Keeps vendor records and payment decisions reliable. |
| Related terms | A revision modifies the existing PO (quantities, prices, dates) with version history; a change order is the formal vendor-facing document describing the modification. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Vendor impact | If the change is agreed and ongoing, revise the PO - that's the honest record of the commitment and prevents every future invoice from failing match. | Keeps vendor records and payment decisions reliable. |
| Audit evidence | Use a system that creates numbered revisions automatically with who, what, when, and the approval for each change. | Keeps evidence clear and reduces control risk. |
What changes to a PO should require re-approval - amount, quantity, vendor, dates?
Re-approve anything that changes the financial commitment or the counterparty: amount increases beyond a small tolerance, quantity increases, vendor changes (which should really be a new PO), and scope additions. Date slips and administrative corrections can proceed with a logged note. Calibrate the tolerance so routine fluctuations don't generate approval churn - and route increases that cross an approval threshold to the higher approver the new amount warrants, not just the original chain.
What is a PO revision vs a change order vs a new PO - when to use each?
A revision modifies the existing PO (quantities, prices, dates) with version history; a change order is the formal vendor-facing document describing the modification - in most systems they're the same action; a new PO is for genuinely new scope or a different vendor. Rule of thumb: same commitment evolving -> revise; new commitment -> new PO.
The vendor's price changed after we issued the PO - do I revise the PO or handle it at invoice match?
If the change is agreed and ongoing, revise the PO - that's the honest record of the commitment and prevents every future invoice from failing match. Absorbing known price changes through match tolerances hides the real commitment and erodes what tolerances are for.
How do I track PO version history for audit purposes?
Use a system that creates numbered revisions automatically with who, what, when, and the approval for each change. If versions live in email attachments named "POfinalv3_REVISED," you don't have version history - you have an archaeology project.
How do I increase a PO amount when project scope grew mid-stream?
Issue a revision with the increase routed through approval at the new total's threshold (a $40K PO grown to $80K deserves the $80K approver), document the scope rationale, and reissue to the vendor. Repeated mid-stream increases on the same PO are a budgeting signal, not just a paperwork task.
How do I handle change orders on construction or project POs with retention?
Track change orders as numbered amendments against the original commitment, with the committed-cost total updating in your job costing as each is approved - and keep retention terms explicit on the PO so progress invoices match against net-of-retention amounts. The discipline that matters: no field-directed change without a priced, approved change order behind it.
People keep editing POs directly in the ERP without approvals - how do I lock down PO changes?
Restrict ERP PO edit rights to the integration and a small admin group, and route all changes through the governed procurement workflow that enforces re-approval. If the ERP is open for direct edits, your approval workflow is decorative.
How do I partially cancel lines on a PO without cancelling the whole order?
Close or cancel the specific lines (releasing their committed budget) and leave the rest open - line-level status is the feature that makes this clean. Communicate the cancelled lines to the vendor explicitly so they don't ship against them.
Stampli perspective
When a Stampli PO is edited after issuance, the system creates a numbered revision, notifies the vendor with a hold notice, and routes the updated PO through a fast re-approval - so changes happen inside the workflow with full version history rather than in an email thread no one can find later. Every revision, approval, and communication lands in the PO's immutable audit trail.