ACH Notification of Change (NOC): Codes, Deadline, and Corrections

An ACH Notification of Change is a message from the recipient’s bank telling you that a field in your payment file was wrong and needs to be corrected before your next payment. The payment itself still goes through. The receiving bank figured out where the money belonged, posted it, and sent the correction back through the network so you can update your records. You have six banking days from receipt, or until you send the next entry to that account, whichever comes later, to apply the fix.

Why the Payment Still Went Through

An NOC and an ACH return are different animals, and the difference decides how urgently you need to act. When the receiving bank can identify the intended recipient despite a bad field in your file, it posts the funds and sends an NOC. When the bank cannot locate the account, or the account is closed, it sends the payment back as a return and the recipient does not get paid.1Nacha. ACH Network Rules Pandemic-Related FAQs

So an NOC means the current payment landed, but the next one might not if the underlying data stays wrong. A return means the payment failed right now. Treat an NOC as a warning; treat a return as a missed payment.

What the NOC Tells You

Your bank (the ODFI) receives the NOC from the recipient’s bank (the RDFI) and forwards you the details you need to make the fix: the change code, the original entry trace number, the original RDFI identification, and the corrected data itself.2Nacha. ACH File Details Some banks deliver this as a formatted report through their online portal; others pass along raw file data you’ll need to parse.

The corrected data field is the important one. It contains the exact replacement value straight from the receiving bank’s system, so you’re not calling the recipient or guessing at the right number. The original entry trace number links the NOC back to the specific transaction that triggered it, which is how you find the right recipient record in your own system.2Nacha. ACH File Details

Reason Codes You’ll Actually See

Every NOC carries a standardized change code that tells you which field was wrong. The codes are set by NACHA and used the same way by every bank.

Account and routing issues:

Transaction code and combined issues:

Name and identification issues:

  • C04 — Incorrect individual name. The recipient changed their name or you submitted it incorrectly.
  • C09 — Incorrect individual ID number tied to the recipient.
  • C10 — Incorrect company name in a business payment.
  • C11 — Incorrect company identification number.
  • C12 — Both company name and identification wrong.

The Six-Banking-Day Deadline

NACHA rules require you to apply the correction within six banking days of receiving the NOC or before you send the next ACH entry to that account, whichever comes later. A banking day is any calendar day other than a Saturday, Sunday, or federal holiday.

If you run weekly payroll and the NOC arrives on a Tuesday, you generally have until the following Wednesday to update your files, assuming no holidays fall in between. The “whichever is later” piece matters for infrequent payments. If you pay a vendor quarterly and receive an NOC the day after a payment, you have months before the next entry. The six-banking-day clock still starts, but the practical deadline shifts to the next payment. Best practice is to make the update immediately anyway, rather than relying on your memory three months out.

Applying the Correction

The actual fix is straightforward once you have the corrected data.

  • Find the recipient’s profile in your payroll system, accounting software, or payment platform. Use the original entry trace number from the NOC to confirm you’re editing the right record.
  • Replace the outdated field with the value from the corrected data field. If the change code covers multiple fields (C03, C06, or C07), update every flagged field, not just the first one.
  • Pull the record back up and verify the change saved correctly. A transposed digit during manual entry creates the exact problem you’re trying to solve.
  • Document the NOC with the date received, the change code, and the date you applied the fix. That audit trail matters if your ODFI asks for compliance records.

Some payment platforms parse incoming NOC files automatically and apply corrections without manual intervention. If you process high volumes of ACH payments, that automation is worth the setup time. Manual handling is fine for a few dozen payments per cycle, but the error rate climbs fast as volume grows.

What Happens If You Ignore It

Failing to act sets off a chain of expensive problems. The first is practical: the next payment you send with the uncorrected data may come back as a return rather than another NOC. The receiving bank gave you one chance to fix it, and a repeat error signals nobody is paying attention.

Beyond returned payments, most ODFIs charge originators a fee for each NOC received, and fees increase when the same errors recur. Poor NOC management also raises compliance flags. NACHA’s enforcement framework allows fines that scale with the severity and persistence of violations, and in serious cases your ODFI can be directed to suspend you as an originator, cutting off your ACH access entirely.

Preventing NOCs Before They Happen

The cheapest NOC is the one you never receive. A few upfront habits reduce the volume sharply.

Prenotification entries (prenotes) are zero-dollar test transactions you send through the ACH network before transmitting a live payment. The receiving bank validates the account information and sends back an NOC or return if anything is wrong. You can send your first real payment as soon as three banking days after the prenote settles, provided no NOC or return comes back. Prenotes are optional under NACHA rules, but they catch errors before money is at stake.

Account validation services offered by banks and third-party providers verify routing numbers, account numbers, and account ownership in real time at the point of enrollment. They catch typos, closed accounts, and mismatched names before the data ever enters a payment file.

Then there’s basic data hygiene. When employees or vendors tell you their bank information has changed, update your records immediately rather than waiting for the next payment cycle. A surprising number of NOCs come from information someone already provided verbally but that never made it into the system.

When the Correction Itself Is Wrong

Occasionally an originator concludes the corrected data in an NOC is actually wrong: the original information was right, or the correction would route the payment to the wrong person. NACHA provides a Refused Notification of Change, using codes in the C61–C69 range, to push back.3Treasury Financial Experience. A Guide to Federal Government ACH Payments – Section: Change Reason Codes Federal agencies and other high-volume originators use them when a receiving bank’s correction doesn’t match their own verified records.

Refused NOCs are uncommon for most businesses. If you genuinely believe the correction is wrong, contact your ODFI before sending one. Your bank can help verify whether the corrected data is valid and advise on the right response. Refusing a legitimate NOC puts you back in the compliance crosshairs you were trying to avoid.