Decide which invoice changes need fresh authorization, stop stale payment instructions, and prove that the released amount matches the version finance approved.
An invoice for $4,800 is approved on Monday. On Tuesday, a corrected document arrives for $5,400. The payment proposal still contains Monday’s amount, while the invoice screen still shows an approval. Which record is the payment team supposed to trust?
Invoice reapproval after changes closes that gap. It connects a specific revised obligation to the people authorized to approve it and then to the instruction that will move the money. It is not simply another approval reminder.
This guide presents a recommended company control, not a legal rule or a universal ERP configuration. Start with your invoice approval workflow; use the procedure below when something changes after that approval is complete.
Approval belongs to a particular set of facts
Record what the approver actually reviewed: supplier and paying entity, invoice reference and revision, amount and currency, line-level scope, relevant coding, supporting evidence and applicable approval rule. Payment instructions need their own verified reference; approval of the purchase does not by itself verify a new bank account.
Do not assume every system resets approval automatically. Oracle E-Business Suite’s invoice guidance describes an amount change moving a document to Needs Reapproval. NetSuite’s record-locking and reapproval settings instead illustrate configuration choices, including tolerance-based rerouting and an option not to reroute changed amounts. Verify the behavior of your actual setup.
The practical control is simple: an approval flag is not enough when the facts behind it have changed. Keep the original authorization as history, but establish whether it still covers the current record.
Classify the change before releasing the hold
AP should log the request and pause the affected invoice’s payment eligibility while assessing it. Confirm the hold in the system that actually feeds payment selection; an email or a comment is not evidence that the payment has stopped. Unaffected, separately authorized items can continue under policy.
Use this matrix as a starting policy design. The controller should approve the actual thresholds, roles and permitted administrative corrections. A matching tolerance is not automatically a reapproval tolerance.
| Change | Recommended decision | Decision owner | Evidence before release |
|---|---|---|---|
| Amount, currency, quantity or scope | Revalidate the obligation and route the revised values under current authority rules, including reductions. | Business owner and finance approver | Old/new values, revised document, receipt or contract support, current approval |
| Supplier or paying legal entity | Hold for identity and obligation review; do not transfer an old approval to a different party. | AP lead, supplier owner and accounting | Verified entity, correct source documents and authorized treatment |
| Bank account or payment destination | Use the separate bank-change verification process and obtain required payment authorization. | Vendor master reviewer and payment approver | Verified change reference and current destination authorization, not full bank data in a general queue |
| Cost center, project or coding | Assess whether ownership, budget authority or accounting treatment changes; reroute affected approvals. | Budget owner and accounting reviewer | Revised allocation and documented approval-impact decision |
| Due date, terms or discount | Review timing, cash and commercial effects; update the proposal and obtain approvals required by policy. | AP lead and treasury, with commercial owner when needed | Agreed terms, recalculated payment basis and authorized payment date |
| Typo in a nonfinancial internal note | Allow a logged correction only if policy permits and no authority, identity, evidence or payment field changes. | Authorized AP reviewer | Before/after note, reason and confirmation that approval-driving facts are unchanged |
For bank changes, follow the vendor bank account change-control process. Reapproving an invoice amount does not replace independent destination verification.
Build a revision record that preserves the old approval
Use one linked change case rather than creating a second payable without checking the original. The original invoice, proposed revision and payment history must remain distinguishable. If a supplier issues a new document number, AP should explicitly determine whether it replaces the old obligation or bills an additional one.
- Identity: original invoice ID, supplier, paying entity, currency and revision identifiers.
- Delta: each old and new value, reason, requester and request time; include a reference to the revised supporting document.
- Containment: affected invoice hold, payment-proposal IDs and confirmation of whether any instruction has already been transmitted.
- Authority: approvals now required, the policy version and the revised amount or allocation each reviewer is authorizing.
- Resolution: correction or credit references, replacement proposal, final release check and reconciliation owner.
Preserve evidence in appropriately restricted records. A general coordination case can contain verification references without exposing bank details. Do not overwrite the original approved PDF and leave its approval attached to an indistinguishable replacement.
Separate authorization from accounting correction
AP owns the change queue; the business owner confirms the revised goods, services or price; finance approves under the applicable authority; accounting determines how a posted document must be corrected. Treasury controls the payment-instruction response. Avoid letting the requester both change the obligation and independently authorize its release.
Posted or finalized invoices may need a formal correction or credit rather than an ordinary edit. For example, the Infor LN 10.3 accounts payable guide distinguishes correction, removal of approval and subsequent approval. Use your accounting system’s supported route; the workflow record is not a substitute for the ledger entry.
Run the change through a controlled state loop
A useful operating sequence is Approved → Change raised → Payment held → Impact validated → Reapproval pending → Approved revision → Payment rebuilt → Release checked → Reconciled. These are proposed business states, not claims about a particular software product.
- Contain: AP records the change and confirms the payment hold. Treasury establishes the actual instruction state. If that state is unknown, keep the case blocked.
- Validate: the business and accounting owners agree the correct obligation and correction method. Recheck matching and duplicate risks against the revised evidence.
- Reauthorize: apply the rules to the revised facts, not just the difference. Make rejected revisions return to review; a rejection must not silently restore payment eligibility.
- Rebuild: remove or supersede the stale proposal through the payment system’s supported controls. Recalculate its totals and obtain any renewed batch approval required by policy.
- Compare and release: an authorized reviewer compares the current approved revision with the final instruction immediately before release.
- Reconcile: accounting ties the resulting payment, correction and invoice balance together, retaining any residual dispute rather than closing it as paid.
If payment has already been sent
Changing an invoice does not establish that an instruction already sent to a bank has changed. Treasury must confirm whether stopping or recalling it is possible and obtain evidence of the outcome before deciding on a replacement.
Catacloud’s payment-change guidance illustrates the distinction between an editable unsent payment and one already held by the bank, and warns against creating a replacement before confirming the original stopped. Treat cancellation availability and timing as provider-specific. If the original settles, route the difference to an authorized additional-payment, credit or recovery decision instead of assuming cancellation succeeded.
Worked example: a revision crosses an approval limit
Illustrative company policy: a department manager may approve up to $5,000; a controller must also approve larger invoices. All figures below are USD, with no tax, fees or foreign-exchange differences. These limits are examples, not recommended universal thresholds.
Invoice INV-240 version A is $4,800 and has manager approval. It is included in proposal PR-17 but has not been sent. The supplier submits version B for $5,400 after an agreed scope addition.
- AP opens a revision case, confirms the hold and removes the stale $4,800 item from release eligibility. The $600 change does not become a separate payable by default.
- The business owner confirms the extra scope and supporting agreement. Accounting determines the supported correction of the existing obligation.
- The manager reviews version B and the controller approves under the illustrative $5,000 rule. The approval basis is $5,400, not just the $600 increase.
- Treasury checks that PR-17 can no longer send version A, then stages the approved $5,400 instruction. If other items are unchanged, the proposal total increases by $600; both the removed item and new item remain traceable.
- The release reviewer compares invoice ID, revision B, entity, supplier, currency, $5,400 amount, verified destination reference and approval evidence. Any further material change returns the case to hold.
After settlement, accounting confirms that the revised payable and payment reconcile without leaving version A as another open liability. The case closes only when the correction, authorization and settlement records agree.
Where Workhint fits
Workhint’s Workflow Engine describes routing approvals to defined roles and requiring details, files, notes or approval steps before work moves forward. Those capabilities are relevant to coordinating an invoice-change request across AP, the business owner and finance.
The Workhint Finance Leaders solution describes payment review and approval alongside payout-status tracking. For this process, the useful design question is which team supplies the revised evidence, who authorizes it and who confirms the payment-system outcome.
These pages do not establish automatic invoice-version locking, synchronization of an ERP hold or bank cancellation for this scenario. Validate those requirements in the actual implementation. Keep ledger corrections and payment release in the responsible systems, with explicit evidence of their results in the coordinating workflow.
Frequently asked questions
Does every edit need a complete new approval chain?
Not necessarily. Define the permitted nonfinancial corrections in policy and log them. For changes affecting the obligation, authority, destination or payment terms, reassess the impacted approvals. Do not use an amount-only tolerance to excuse a different supplier or bank account.
Can a smaller invoice keep its previous approval?
Do not assume so. A reduction can reflect removed work, changed allocation or a credit that needs accounting treatment. Follow the documented policy and preserve the reviewer’s decision about the revised facts.
Does invoice reapproval also approve the payment run?
No. Invoice review addresses the obligation; the payment run approval workflow addresses the instruction and batch. A changed invoice can require changes to both records. The last release check must compare their current versions.
What if the replacement document arrives close to the cutoff?
Escalate to the designated owner with the hold status, change evidence and time remaining. Use an authorized exception route or a later payment date. Urgency is not evidence that the old approval covers the new instruction.
Leave a Reply