An ACH notification of change arrived after the supplier was paid

An ACH notification of change can arrive even though the payment was processed. Nacha distinguishes these correction notices from returns: the notice identifies payment information that needs updating. Retrieve the actual bank report and its original transaction reference before treating the supplier as unpaid.

Confirm the payment's settlement status independently. Do not reverse a supported payment or send another simply because the report contains an unfamiliar code. A correction notice and a cash return are different events, and each needs its own evidence in the accounting record.

Match the notice to the supplier, original payment and stored beneficiary record. Record the code, corrected information, notice date and bank reference. Ask the originating bank to explain any field that the accounting team cannot interpret reliably. Avoid guessing whether a value belongs in the routing, account or account-type field.

Check where that payment information is stored. It may appear in the bank portal, accounts-payable software, an export template and a separate recurring-payment instruction. Updating only one location can leave the next file using the old details. Create a short list of affected records and the owner of each.

Keep the change limited to the supported beneficiary record. A correction to one supplier does not establish that every supplier using the same bank needs a change. Retain the previous value securely in the change history where policy permits, while keeping full banking details out of general email threads.

Ask the bank which deadline and handling requirements apply to the notice. Nacha's originator guidance describes the usual correction timing, while its rule clarification provides discretion for certain single-entry situations. The payment type and actual circumstances matter, so the team should use the bank's current instructions rather than a universal calendar reminder.

Assign a named owner and set an internal due date before the affected next payment run. When the bank confirms that a correction is required, keep the relevant instruction from being reused until the update is complete. If an urgent payment is due, obtain the bank's approved route instead of bypassing the correction process.

Use the authenticated bank notice as evidence and have the authorized reviewer compare the update with that notice. If the same change also arrives by supplier email, do not let the email substitute for the bank record. Resolve inconsistent instructions through known contacts before releasing another payment.

Save the old and new record references, person making the update, reviewer and completion time. If the software automatically applies notices, inspect its change log and confirm which systems it updates. Automation should leave a trace the accountant can follow when a later transaction differs.

Review the next applicable instruction before release and confirm that it uses the approved corrected data. After settlement, link the bank result to the change notice. A successful payment is useful follow-up evidence, but it should not replace the original explanation for the master-data change.

Keep the notice with the supplier payment history and record any recurring failure. If the next file still contains old details, investigate whether a template or integration overwrote the update. Close the task only when the supported correction reaches the actual payment source and the accounting treatment still reflects the original payment correctly.