Most finance teams treat ACH return codes as a payment operations problem. But they are one of the most underused fraud and error detection tools in the disbursement function.
When an ACH vendor payment comes back, the typical response is remediation: update the account number, contact the vendor, resubmit. The return code is treated as a label on a broken transaction, not as information worth analyzing.
That’s a missed opportunity. Return codes are the ACH network’s built-in diagnostic layer — a standardized vocabulary that the receiving bank uses to tell you exactly why a payment failed. Taken individually, most returns are unremarkable. Taken in context — across vendors, over time and against the pattern of your disbursement activity — they tell a more interesting story.
Financial operations teams that treat return codes as a control signal rather than an operational nuisance gain an early-warning capability that most of their peers miss.
The Codes That Matter Most for Vendor Disbursements
Not all return codes carry equal diagnostic weight. The following represent the highest-signal codes for organizations focused on vendor payment integrity. They fall into two groups: account validity indicators and authorization red flags.
Account Validity Indicators
R02 — Account Closed The account existed but has since been closed. In a vendor context, a single R02 on a new vendor is a yellow flag. A cluster of R02 returns on recently onboarded vendors — or on vendors whose banking information was recently updated — is a red flag. Ghost vendor schemes and fraudulent vendor redirects often involve accounts that were opened temporarily, used to receive one or more payments, and then closed. The timing between account setup, payment and return is worth examining closely.
R03 — No Account / Unable to Locate Account The account number doesn’t match any account at the receiving institution. This is frequently a data entry error, but it can also indicate that fraudulent banking credentials were submitted during vendor onboarding or in a change-of-bank-account request. An R03 return on a vendor whose banking information was recently modified — particularly if the modification came in by email rather than through a verified channel — warrants immediate investigation before any retry.
R04 — Invalid Account Number Structure The account number is structurally malformed. Like R03, this is often benign. But if it appears on a new vendor or following a bank account change, it may indicate that fabricated credentials were submitted and the perpetrator got the format wrong.
R16 — Account Frozen / OFAC Return The account has been frozen — either by the receiving financial institution or because the account holder has been identified on an OFAC watchlist. An R16 on a vendor payment is a serious flag that should trigger immediate escalation, not routine remediation.
Authorization Red Flags
R17 — File Record Edit Criteria (Fraud Flag) Originally a technical error code, R17 was expanded by Nacha in October 2024 to explicitly cover suspected fraud. When an RDFI returns a transaction under R17 and the addenda record contains the notation “QUESTIONABLE,” it means the receiving bank’s own fraud detection flagged the transaction. That is a significant signal — one financial institution has already assessed the payment as suspicious. Treat an R17/QUESTIONABLE return as a potential fraud incident, not a processing error.
R06 — Returned Per ODFI’s Request The originating bank has requested the return of the payment. This is often initiated when the ODFI’s own fraud monitoring flags a transaction. Nacha expanded the use of R06 in October 2024, making it easier for ODFIs to request returns for any reason when they indemnify the receiving bank. An R06 on a vendor payment is worth a conversation with your bank about what triggered the request.
The Tier Below: Reference Codes Worth Knowing
The following codes are less immediately alarming but appear frequently enough in vendor payment workflows that your team should recognize them:
| Code | Meaning | Operational Note |
| R01 | Insufficient Funds | Unusual for vendor payments to business accounts; worth noting if recurring |
| R03 | No Account | See above; context determines severity |
| R07 | Authorization Revoked | Vendor has revoked authorization; stop all future payments to that account pending resolution |
| R08 | Payment Stopped | Stop payment placed; contact vendor directly |
| R10 | Not Authorized | Debit not authorized; requires direct vendor contact before retrying |
From Signal to Protocol: Building a Return Code Response Framework
Recognizing which codes carry diagnostic weight is only half the work. The other half is having a defined response protocol so that high-signal returns don’t fall into the same remediation queue as routine failures.
A defensible return code response framework has three components:
1. Triage by code, not by dollar amount. The instinct in most organizations is to escalate returns based on payment size. That’s the wrong filter. An R17/QUESTIONABLE return on a $4,200 invoice is more urgent than an R01 on a $40,000 payment. Dollar amount is the secondary variable. Code classification is primary.
2. Separate the remediation track from the investigation track. Administrative returns (R02, R03, R04) on established vendors with stable banking relationships belong in a remediation workflow: verify, correct, resubmit. High-signal returns on new vendors, on recently modified vendor records, or on any vendor where banking information arrived via unverified channels belong in an investigation workflow: hold the payment, verify the vendor out-of-band, escalate to management before any retry.
3. Log returns as control data, not just as payment events. Return codes are only useful as a fraud detection signal if they’re being aggregated and reviewed — not just resolved and closed. A vendor that generates two R03 returns over six months is not necessarily a problem. A vendor whose account generates an R03 return two weeks after a bank account change request is a different matter entirely. That pattern is only visible if you’re keeping return history tied to vendor records.
A Note on Nacha’s Evolving Fraud Framework
Nacha has been actively strengthening the fraud-related return infrastructure over the past two years. Beyond the R17 and R06 expansions noted above, rule amendments effective March 2026 impose new requirements on Originators around fraud monitoring — making it explicit that fraud detection is not solely the bank’s responsibility. Financial operations teams that have treated ACH compliance as a banking function should take note: the trend in the rules is toward shared responsibility, and the return code framework is one of the primary mechanisms through which that shared responsibility is exercised.
The Takeaway
ACH return codes are diagnostic data. The question is whether your organization is reading them or just clearing them. Building a return code response protocol — tiered by risk signal, with separate tracks for remediation and investigation — is a relatively low-cost control enhancement that can meaningfully improve your ability to detect vendor payment fraud before it scales.The codes are already there. The signal just needs someone to receive it.
VendorInfo is a Nacha Preferred Provider. To learn how VendorInfo can help you with vendor bank account verification, contact us.