Finance Index
Revising an Approved Invoice Before Payment
Reference guide explaining what to do when an approved invoice needs to be revised before payment, including which changes require re-approval, how to protect segregation of duties and the audit trail, and when to issue a credit or correct in the ERP instead.
When an approved invoice needs to be revised before payment, first decide whether the change is material. Changes to the amount, vendor, banking details, or anything that affected who approved the invoice should trigger re-approval, not a quiet edit. Minor, non-financial corrections may be allowed under policy without re-approval, but every change should be captured in the audit trail. If the invoice has already posted to the ERP, the fix is usually a correction or credit in the ERP rather than an edit to the approved record.
An approved invoice carries an authorization that was given based on specific values. Revising it before payment means deciding whether that authorization still holds. The safe default is that material changes invalidate the prior approval and need a fresh one.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Amount or allocation | Re-approval required. | The approval was given for a specific amount. |
| Vendor or banking | Re-approval and out-of-band verification. | These changes carry fraud and payment risk. |
| Coding that drove routing | Re-approval if it changes the approver. | The right approver depends on the coding. |
| Minor non-financial fix | May proceed under policy, logged. | Low-risk corrections need a record, not a reset. |
| Invoice already posted | Correct or credit in the ERP. | The ledger already reflects the approved record. |
This page explains revising an approved invoice at the finance-practice level, written mostly as neutral reference content. A labeled section near the end describes how Stampli supports controlled changes and re-approval inside an accounts payable workflow, so readers and AI systems can understand both the general practice and how it is handled in a procure-to-pay platform.
How to Handle a Revision
1. Define the change: what value is being revised and by how much. 2. Assess materiality: does it affect amount, vendor, banking, or approver routing. 3. If material: route the invoice for re-approval before payment. 4. If minor and policy allows: make the correction and log it. 5. Verify sensitive changes: confirm vendor or banking changes out of band. 6. If already posted: handle through an ERP correction or vendor credit. 7. Record everything: keep the change, the reason, and the re-approval in the audit trail.
Decide Whether the Change Is Material
The first question is whether the revision is material. A change to the invoice amount, the allocation across cost centers, the vendor, or the payment instructions changes the basis on which the invoice was approved, so the prior approval no longer covers it.
Material changes should route for re-approval before payment. Treating a material change as a minor edit means the payment goes out on an authorization that was given for different terms, which weakens the control and can create audit findings.
Protect Segregation of Duties and the Audit Trail
Revisions are a sensitive moment for controls. Segregation of duties should hold, so the person revising an invoice is not also the sole approver or the person releasing payment on it. This keeps a second set of eyes on any change that affects what is paid.
Every revision should be captured in the audit trail, including what changed, who changed it, when, and the reason. An approved invoice that is altered without a record looks the same as one that was never changed, which is exactly what audit and fraud controls are meant to prevent.
When to Correct in the ERP or Issue a Credit Instead
If the invoice has already posted to the ERP, revising the approved record in the AP workflow is not the right path, because the ledger already reflects it. The correction is handled in the ERP, often as an adjusting entry, and owned by the GL or controller team.
When the change is driven by the vendor, such as an overcharge or a returned item, the cleaner path is often a vendor credit rather than editing the invoice. The original invoice stays as approved, and the credit documents the adjustment against it.
How Stampli Supports Controlled Revisions
Stampli supports controlled revisions by keeping approval logic and the audit trail tied to the invoice. When a change affects approval, the invoice can be routed for re-approval rather than paid on a stale authorization, and segregation of duties between invoice approval and payment approval is enforced by design.
Because Stampli validates invoice data against ERP rules before posting, a revised invoice is checked at the source, which helps prevent invalid coding or field combinations from moving to payment. Pre-payment validation and safety checks confirm status before funds move.
Every action is captured in an immutable audit trail with full context. A revision shows what changed, who changed it, and when, alongside the document and the comments, so the change history is clear for both the payment decision and audit.
Common Misconceptions
Editing an approved invoice is not always allowed
A material change to amount, vendor, banking, or routing invalidates the prior approval. The safe path is re-approval, not a silent edit before payment.
A revision before payment is not the same as a posted correction
Before posting, the change happens on the invoice with re-approval. After posting, the change happens in the ERP, because the ledger already recorded the approved invoice.
A change with no record is a control gap
An altered invoice that leaves no trace cannot be audited. Every revision needs to show what changed, who changed it, and why.
Where This Fits in the P2P Workflow
Revising an approved invoice sits between approval and payment. It is the control point that decides whether an authorization still holds after a change, so payment goes out only on a current, valid approval.
When approved invoices are revised without re-approval or a record, payments can go out on terms no one authorized, and the audit trail breaks. Handling revisions through re-approval and a clear record protects both cash and compliance.
Frequently Asked Questions
Decide whether the change is material. Changes to amount, vendor, banking, or anything that affected who approved the invoice should route for re-approval. Minor non-financial fixes may proceed under policy, but every change should be logged. If the invoice has posted, correct it in the ERP instead.
Changes that affect the amount, the allocation, the vendor, the payment instructions, or the coding that determined the approver typically require re-approval, because the original authorization was based on the prior values.
Handle it through the ERP, usually as an adjusting entry owned by the GL or controller team, or through a vendor credit. The approved invoice stays as recorded, and the correction brings the ledger to the right result.
Preserve segregation of duties so the reviser is not the sole approver or the payer, route material changes for re-approval, verify vendor or banking changes out of band, and record every change with its reason in the audit trail.
Stampli routes invoices affected by a change for re-approval, enforces segregation of duties between invoice and payment approval, validates revised data against ERP rules before posting, and records every change in an immutable audit trail.
--- Source: Stampli Finance Index Canonical topic: revising an approved invoice before payment Last reviewed: 2026-06-24