Separate a bank-data correction from a failed payment, then prove the corrected instructions reach the next ACH file without paying the same invoice twice.
An ACH payment can reach a supplier and still produce a notification of change. The receiving bank has identified information that needs correcting for future entries. If AP treats that message as a failed payment, it can create a duplicate. If AP assumes the bank corrected every system, the next file may repeat the old instructions.
A useful ACH notification of change workflow therefore tracks two things separately: what happened to the original payment, and whether the reusable payment instructions have been corrected. This guide focuses on US vendor ACH credits, especially suppliers you expect to pay again.
First decide: correction notice or returned payment?
A notification of change, usually shortened to NOC, is a non-monetary correction message. It is also associated with the ACH COR entry type. It is not itself a new payment or a return of funds. Lithic’s ACH documentation distinguishes these correction entries from returns: the original payment can post while future instructions need updating.
Do not reopen an invoice or send a replacement solely because an NOC arrived. Check the original payment’s actual bank or processor record. If there is also a return, handle that as a separate financial event through the ACH return-code recovery process.
Keep separate status fields. A payment might be “posted, reconciled” while its NOC case remains “source correction pending.” Closing the payment does not close the correction; opening the correction does not establish that cash came back.
Capture the bank event before changing any record
Use the bank’s authenticated portal, established report feed or confirmed processor channel to retrieve the notice. An email saying “NOC received” should lead you to that trusted channel, not become authority to copy account details from an attachment.
The Federal Reserve’s FedPayments Reporter report descriptions explain that the ACH NOC report combines information from the original forward entry with change information supplied by the receiving bank. Ask your bank how it makes equivalent information available to your organization.
Create one correction case for the event, with links to duplicate notifications rather than separate competing updates. Its working record should contain:
- Receiving timestamp, trusted source and bank or processor reference.
- Original trace reference, supplier ID, paying entity and original payment reference.
- Change code, affected field names and a restricted link to corrected data.
- Original payment outcome, recorded separately from correction progress.
- Named correction owner, reviewer, next planned payment and applicable due date.
- Every reusable instruction source that could generate another payment.
Keep full account numbers in the approved restricted record, not a broadly shared task description. Mask working summaries and retain enough references for an authorized reviewer to locate the evidence.
Use the code to identify fields, not to invent missing data
The Texas Comptroller’s NOC reason-code reference identifies these common corrections. The field meanings are useful; its TINS system’s automatic actions are specific to that system.
| Code | Field affected | AP review question |
|---|---|---|
| C01 | Account number | Did the approved source receive the complete corrected account value? |
| C02 | Routing number | Which templates or exports still contain the previous routing value? |
| C03 | Routing and account numbers | Were both fields reviewed together rather than only one? |
| C05 | Transaction code, such as checking versus savings | Does the payment system map the corrected account type correctly? |
| C07 | Routing, account and transaction code | Were all three corrections applied to the same beneficiary record? |
This is not a complete code catalogue. If the corrected data is missing, inconsistent or cannot be mapped confidently, escalate to the bank or processor. Do not infer an account number from the code or copy details from a different supplier with a similar name.
A control matrix from receipt to verified use
The following is a recommended internal operating design, not a statement that every step is required by law. Adapt ownership and restrictions to your bank agreement, systems and authority policy.
| State and owner | Evidence and control | Exit condition or exception |
|---|---|---|
| Received — treasury or AP | Retrieve the event from the trusted channel; record receipt and original trace. | One case exists. Unauthenticated notice goes to bank confirmation, not data entry. |
| Matched — AP analyst | Match supplier, entity and original entry. Inspect payment status separately. | Unique match established. Ambiguous matches remain blocked for investigation. |
| Validated — authorized verifier | Confirm corrected fields and the responsible updater through the established bank/processor process. | Usable correction confirmed. Conflicting instructions require escalation. |
| Approved — independent reviewer | Review the proposed change, source evidence and affected future instructions. | Approval covers the exact field set and record version, not a generic “bank change.” |
| Applied — record owner | Update the authoritative source, or verify the processor’s completed update. Record before/after references. | Approved source is current; stale reusable copies are retired or corrected. |
| Verified for use — payment preparer and checker | Inspect the actual next file or template output against the approved source. Reapprove changed unreleased instructions. | Corrected values reach the output; unresolved stale instructions cannot proceed. |
| Closed — AP control owner | Retain match, verification, approval, update and propagation evidence; link subsequent payment outcome when available. | No unresolved copy or owner gap. Later recurrence reopens investigation, not a blind second edit. |
For authenticity and independent approval, use your established vendor bank-account change controls. The additional NOC work is linking the bank event to the original entry and proving the correction reaches every source that can create the next instruction.
Set a deadline without confusing rules and policy
SouthState’s ACH best-practice guidance describes correction timing as six banking days after receipt or the next time the transaction is generated, whichever is later. It also recommends independently validating changes using trusted contact information. Confirm the current applicable requirements and your bank’s instructions rather than calculating deadlines from a generic calendar-day reminder.
Scope matters. Nacha’s June 2024 minor rules amendment gives originators discretion about acting on NOCs for any single entry, regardless of its Standard Entry Class code. Do not present one timing sentence as an unconditional rule for every payment situation. Ask your bank to resolve applicability, exceptions and contractual obligations.
Your company can choose an earlier internal target: for example, triage on receipt and complete review before the next proposed file. Label that as company policy. Record the external requirement, internal target and next payment date as separate fields. A missed internal target should trigger escalation, not silent acceptance of stale instructions.
Check what the processor changed—and what it did not
Some providers apply NOC corrections themselves. Settle’s NOC guidance, for example, says it updates the vendor information for payments it originates. That does not demonstrate an update to an independently maintained ERP record, another bank’s beneficiary template or a saved payment export.
Assign one owner for each instruction source. If the processor is authoritative for its own route, verify its update rather than overwriting it with yesterday’s ERP export. If AP owns the ERP source, record the approved correction there and determine how downstream copies are refreshed.
- Queued but unreleased payment: inspect the instruction already prepared. A master-data change may not alter a file generated earlier. Withdraw or regenerate stale instructions through the normal approval process.
- Already transmitted payment: do not edit a local file and assume the bank instruction changed. Ask the bank or processor about its actual state and permitted actions.
- Conflicting vendor request: preserve both events and escalate through trusted contacts. Do not choose whichever account details arrived most recently.
- Repeat NOC: trace the actual input used by the next file. Investigate stale templates, wrong entities or imports that restored old data before making another change.
An NOC itself does not create a new payable, expense or cash movement. Keep ledger treatment tied to the actual payment, bank statement and any separate return or fee. A data-correction case should not generate an accounting adjustment simply to make its status look complete.
Worked example: the ERP is right, but the queued file is wrong
Illustrative transaction: a business pays a recurring supplier $4,800. The original payment posts. Treasury then receives a C02 notice and confirms the corrected routing number through its bank’s established process.
AP matches the original trace, records the supplier and paying entity, and submits the routing correction for independent review. The reviewer approves it. The ERP owner applies the update, but a bank-portal template and an unreleased file were created from the old record.
The case is not ready to close. The template owner corrects the saved template. The payment preparer withdraws the stale unreleased file, regenerates it from the approved source and obtains the required fresh approval. The checker compares the actual output to the corrected source, using restricted access rather than exposing banking details in the case summary.
The $4,800 invoice stays paid; there is no replacement payment. The correction case closes with the original notice, match, independent approval, ERP change reference, template evidence and regenerated-file check. If no future payment is planned, record that fact and any remaining reusable-source restriction explicitly rather than claiming a next-file test occurred.
Failure test: ask a reviewer to generate a draft instruction from the ordinary route. If the old routing value returns, the control failed even if an “updated” task was checked off. Fix the originating copy or import rule and repeat the output check before release.
Where Workhint fits
Workhint can support the coordination around this control. Its Workflow Engine lets teams define request steps, route approvals to defined roles, and require details, files or notes before work advances. Those capabilities are relevant to organizing the notice, verification and review handoff.
The Finance Leaders solution describes payment review, approval and payout-status workflows. Keep the bank’s correction evidence, the authoritative account record and the actual payment outcome explicit in your design. These pages do not establish native NOC ingestion, automatic ERP or bank-template updates, or guaranteed compliance with ACH rules.
The operational goal is a clear case owner and review sequence—not a second bank ledger. A workflow status should link to the source evidence rather than substitute for the bank’s or accounting system’s record.
Frequently asked questions
Does an ACH NOC mean the vendor was not paid?
No. An NOC is a non-monetary correction message, not proof that funds returned. Check the original entry’s actual outcome; investigate any separate return independently.
Should we send the invoice payment again after a C02 notice?
Not because of the notice alone. C02 identifies a routing-number correction. Establish the original payment’s status before considering any payment action.
Can we close the case if our provider updated the account?
Verify the provider’s update and identify other reusable sources. Closure also needs a documented disposition for ERP records, saved templates and prepared instructions that could reintroduce the old data.
What evidence shows the workflow is complete?
A matched authenticated notice, confirmed correction, appropriate review, authoritative-source update and evidence that stale reusable instructions are corrected or restricted. Record any unavailable next-file test honestly.
A sound NOC workflow ends with usable corrected instructions and a traceable decision—not a duplicate payment, an unexplained bank edit or a task marked complete while the next export still contains old data.
Leave a Reply