ACH return codes are the standardized “R” codes (R01 through R85) that financial institutions use to explain why a debit or credit failed. NACHA governs the rules behind them, and the timing you must track splits into two windows: most returns come back within 2 banking days, while consumer unauthorized-debit claims can surface up to 60 calendar days later. Your first job when one lands is simple: figure out whether you can retry it, or whether you need to stop and document it.


TL;DR:

  • Retry timing varies: R01 (insufficient funds) typically allows a 3-5 business day wait before reattempting, while R09 (uncollected funds) depends on deposit clearance.
  • Correct SEC codes are crucial since consumer transactions like PPD have a 60-day unauthorized-debit window, whereas corporate codes like CCD or CTX have just 2 banking days.
  • Common return causes include account closure, incorrect routing or account numbers, and authorization disputes, all requiring specific documentation and timely action.
  • NACHA’s recent rule changes permit correcting certain authorization mismatches via R11 within 60 days of settlement, provided the original terms are unchanged.
  • High return rates can trigger NACHA compliance scrutiny, potentially leading to account restrictions; proactive monitoring and data hygiene are key for mitigation.

Table of Contents

What Is an ACH Return, and How Do Return Codes Work?

Every ACH return starts at the receiving end. The Receiving Depository Financial Institution, or RDFI, is the bank holding the account your business tried to debit or credit. When that transaction can’t settle, the RDFI generates a return and attaches an “R” code that spells out exactly why. That return travels back through an ACH Operator to your bank, the Originating Depository Financial Institution, or ODFI, which then notifies you as the Originator.

Think of it as a two-party relay with your bank as the middleman. The RDFI decides the code. Your ODFI relays it and, in most cases, is on the hook to NACHA for your return-rate performance. That’s why your bank cares about your return codes just as much as you do, sometimes more, since repeated violations threaten their own standing with NACHA, not just yours.

The Standard Entry Class (SEC) code you assign to each transaction determines which return window applies. Consumer transactions coded as PPD (Prearranged Payment and Deposit) trigger the 60-calendar-day window for unauthorized-debit claims. Corporate transactions coded as CCD or CTX generally fall under the tighter 2-banking-day standard return window, because business account holders are expected to reconcile faster and have fewer unauthorized-debit protections. Get the SEC code wrong, and you can misjudge your entire exposure window.

Clean data matters more than it seems. Accurate SEC codes, complete addenda records, and correct account and routing information are what keep returns rare in the first place. Sloppy onboarding data is the single biggest driver of preventable returns, and it’s entirely within your control before a transaction is ever originated.

Complete ACH Return Code Reference (R01–R85)

Not every code carries equal weight. Some are routine cash-flow hiccups. Others are compliance flashpoints that can put your origination privileges at risk if mishandled. The table below groups the codes you’ll encounter most, along with the standard return window and the action each one typically demands.

| R09 | Uncollected funds | 2 banking days | Retry eligible | | R10 | Customer advises originator is not known / not authorized | 60 calendar days | Stop, WSUD required | | R11 | Entry not in accordance with terms of authorization | 60 calendar days | Correct and may resubmit | | — | Account sold to another DFI | 2 banking days | Stop, update account details |

| — | Invalid ACH routing number | 2 banking days | Stop, correct routing number |

| — | Representative payee deceased or unable to continue | 2 banking days | Stop, terminate arrangement |

| R15 | Beneficiary or account holder deceased | 2 banking days | Stop, terminate arrangement | | — | Account frozen | 2 banking days | Stop, contact customer |

| R17 | File record edit criteria / suspected fraud (RDFI discretion) | 2 banking days | Investigate before retry | | — | Improper effective entry date | 2 banking days | Correct file, resubmit |

| R19 | Amount field error | 2 banking days | Correct file, resubmit | | — | Non-transaction account | 2 banking days | Stop, verify account type |

| — | Invalid company identification | 2 banking days | Correct file, resubmit |

| — | Invalid individual ID number | 2 banking days | Correct file, resubmit |

| — | Credit entry refused by receiver | 2 banking days | Stop, contact customer |

| — | Duplicate entry | 2 banking days | Correct file, remove duplicate |

| R25 | Addenda error | 2 banking days | Correct file, resubmit | | — | Mandatory field error | 2 banking days | Correct file, resubmit |

| — | Trace number error | 2 banking days | Correct file, resubmit |

| R28 | Routing number check digit error | 2 banking days | Correct file, resubmit | | R29 | Corporate customer advises not authorized | 2 banking days | Stop, no consumer WSUD protections apply | | — | RDFI not participant in check truncation program | 2 banking days | Stop, use alternate method |

| — | Permissible return by RDFI | 2 banking days | Coordinate with RDFI |

| — | RDFI non-settlement | 2 banking days | Investigate with ODFI |

| R33 | Return of XCK entry | 2 banking days | Investigate with ODFI |

Beyond R33, the codes shift toward file-format and network-level exceptions rather than day-to-day merchant disputes. R34 through R39 cover RDFI-side settlement and format issues. R40 through R51 largely apply to specific network entries like ARC, BOC, and POP conversions. R61 through R85 handle dishonored and contested-dishonored returns, the mechanism a bank uses when it wants to reverse a return it already sent, typically because the original return itself was improper. Your operations team rarely touches these directly; they’re a bank-to-bank conversation, but knowing they exist helps you understand why a resolved return can occasionally reopen.

The codes that deserve the most attention from a merchant’s standpoint fall into three buckets. Authorization disputes (R05, R07, R10, R11, R29) require documentation and often a Written Statement of Unauthorized Debit. Fraud-suspect returns (R17) demand investigation before you consider any retry. File and formatting errors (R19 through R28) are entirely fixable on your end and should never repeat once your onboarding process catches the root cause.

The Codes You’ll See Most, and What to Do About Each

Here’s what each one actually means for your operation, according to the standard mappings Plaid and Modern Treasury both document for common ACH returns.

  • R01 (Insufficient Funds): The account simply didn’t have the balance to cover the debit at that moment. This is retry-eligible, and Payments & Risk recommends waiting 3 to 5 business days before a second attempt, timed around typical payroll or benefit deposit cycles.
  • R02 (Account Closed): No retry. The account no longer exists. Contact the customer for updated payment information before you attempt anything else.
  • R03 (No Account / Unable to Locate): Usually a data-entry problem at onboarding. Verify the account number character by character before resubmitting.
  • R04 (Invalid Account Number): Similar to R03, but often points to a transposed digit or an account-type mismatch. Correct and reverify rather than guess and retry blind.
  • R05, R07, R10, R11, R29 (Unauthorized or Revoked): These are the codes that create real liability. Document the original authorization the moment you originate any transaction, and be ready to produce it fast. For consumer accounts, a Written Statement of Unauthorized Debit is often the deciding piece of evidence when a dispute escalates, and its timing matters as much as its content.
  • R09 (Uncollected Funds): Different from R01. The account shows a balance, but those funds haven’t cleared yet, often from a recent deposit still in hold status. Retry timing here should track the deposit’s own clearing schedule rather than a fixed calendar rule.

Pro Tip: Keep a running log of every R05, R07, R10, R11, and R29 return with the original authorization record attached. If a dispute ever reaches your ODFI or NACHA, having that documentation assembled in minutes, not days, is often what separates a resolved case from an origination review.

How Long Do You Have to Return or Retry an ACH Transaction?

NACHA rules count in banking days for most returns and calendar days only for the consumer unauthorized-debit exception. A banking day excludes weekends and federal holidays, so a Friday return effectively has until the following Tuesday if Monday is a holiday. Calendar days count every single day, no exceptions, which is why the 60-day window for R05, R07, and R10 claims can quietly slip past a team that isn’t tracking it separately.

Retry-eligible codes come with practical, not regulatory, wait-time guidance. R01 is commonly retried after 3 to 5 business days, giving the account time to receive a fresh deposit. R09 retries should track the specific hold or clearing schedule rather than a flat number of days.

Correction rules changed meaningfully with R11’s repurposing by NACHA. When an entry comes back as R11 for a fixable authorization-terms mismatch, you can transmit a corrected entry within 60 days of the original return’s settlement date, provided the corrected entry conforms exactly to the terms of the original authorization. That’s a meaningfully longer runway than the 2-day window most operational teams assume applies across the board, and missing that distinction costs merchants retry opportunities they actually had.

What NACHA’s Recent Rule Updates Mean for Your Returns

NACHA has spent the last several rule cycles tightening the line between legitimate correction and unauthorized-debit abuse, and the changes land squarely on how you’re allowed to handle R11, R17, and R06.

What NACHA's Recent Rule Updates Mean for Your Returns — overview diagram

R11 no longer means what it used to. NACHA repurposed the code to mean “Entry not in accordance with the terms of the authorization,” giving originators a defined path to correct certain authorization-configuration errors, like a wrong debit date or amount, and resubmit without going back to the customer for brand-new authorization. That correction still falls under the unauthorized-entry fee structure, so it’s a compliance win on process, not a way to dodge cost.

The October 1, 2024 risk-management update codified how RDFIs can use R17 for suspected fraud, expanded when an ODFI can request a return through R06, and sharpened expectations around WSUD timing.

R17’s fraud-suspect use remains at the RDFI’s discretion, not a mandatory flag, and it still carries the standard 2-banking-day return window rather than the longer consumer window. That discretion matters: a merchant seeing R17 shouldn’t assume automatic fraud confirmation, only that the receiving bank had reason to pause the entry.

Practically, this means your team needs a documented WSUD process ready before a dispute ever lands, not scrambled together after. NBT Bank’s summary of these expectations puts the WSUD front and center as the evidentiary standard RDFIs lean on when a consumer disputes a debit.

What ACH Returns Cost Your Business

Every return carries a fee, and in most merchant agreements, you’re the one absorbing it, not your customer. Return fees from your ODFI typically range from a few dollars to several tens of dollars per incident, layered on top of whatever revenue the failed transaction represented.

The bigger risk lives in NACHA’s return-rate thresholds. Payments & Risk documents the three thresholds NACHA monitors: 0.5% for unauthorized returns, 3% for administrative returns, and 15% for overall returns. Cross any of these consistently, and your ODFI faces its own compliance review with NACHA, which means your account moves under increased scrutiny fast, often before you’ve even noticed the pattern yourself.

ACH return rate threshold comparison

For subscription and high-risk merchants running recurring billing, these thresholds are easier to breach than most teams expect. A single billing-cycle glitch that hits thousands of accounts at once can spike your unauthorized rate well past 0.5% in a single reporting period. The consequences escalate from monitoring, to mandatory remediation plans, to possible loss of origination privileges if return patterns do not improve. For some high-volume merchants, excessive returns are a leading cause of losing ACH access.

Building a Prevention Playbook That Actually Reduces Returns

Cutting your return rate isn’t about reacting faster. It’s about making fewer returns happen in the first place, and that starts well before you ever originate a transaction.

  1. Lock down authorization records at the point of signup. Every consumer debit needs a clear, retrievable record of what the customer agreed to, in what format, and when. This is your first line of defense against R05, R07, R10, and R29.
  2. Verify accounts before you originate. Prenotes give you a structural check on routing and account numbers but take a day or two to clear. Micro-deposits confirm actual account ownership at the cost of some customer friction. Account-verification APIs move faster but occasionally miss coverage at smaller institutions, so pick the method that matches your onboarding volume and risk tolerance.
  3. Audit your file hygiene regularly. Correct SEC codes, complete addenda records, accurate trace numbers, and valid routing check digits eliminate nearly the entire R19 through R28 category before it ever starts.
  4. Run velocity and anomaly checks on your transaction batches. A sudden spike in returns from one billing run, one acquisition channel, or one customer segment is usually the earliest signal of a problem, whether that’s a bad list, a pricing dispute, or fraud.

Pro Tip: Run your verification method selection by transaction size. Micro-deposits make sense for high-value, low-frequency debits where friction is acceptable. APIs make more sense for high-volume, low-value subscription billing where speed protects your conversion rate.

Your Step-by-Step Runbook When a Return Comes In

When a return hits your system, speed and sequence both matter. Here’s the order that keeps you compliant and keeps your ODFI relationship intact.

  1. Identify the code, the settlement date, and the SEC class immediately. This tells you which window applies, 2 banking days or 60 calendar days, and whether it’s retry-eligible.
  2. Stop any scheduled re-origination the moment you see an unauthorized-category code. Re-running R05, R07, R10, or R29 without new documentation is exactly the pattern that draws NACHA scrutiny.
  3. Contact the customer for corrected information, or request a Written Statement of Unauthorized Debit if the return is contested. Get this in writing and store it with the original authorization record.
  4. Confirm whether you’re eligible to re-present or need fresh authorization before you resubmit anything, especially for R11 corrections within the 60-day window.
  5. Update your return-rate dashboard and flag your ODFI proactively if your numbers are trending toward the 0.5%, 3%, or 15% thresholds, rather than waiting for them to raise it first.

How Davincipay Supports Merchants Managing ACH Returns

Return management gets harder the moment your business runs recurring billing across a high-risk vertical, whether that’s supplements, telehealth, or subscription commerce. Some payment providers work with merchants in these categories, pairing domestic and international acquiring relationships with underwriting support built for businesses that standard processors turn away.

The operational support that matters most here is the boring stuff done consistently: authorization recordkeeping practices, return-rate monitoring so you see a threshold breach coming instead of reacting to it, and re-presentment strategy that keeps you compliant with the 2-day and 60-day windows instead of guessing. Fraud and chargeback mitigation tools sit alongside recurring billing management, since the same infrastructure that reduces unauthorized ACH returns tends to reduce card disputes too.

Every merchant’s return profile looks different depending on their acquisition channel and billing cadence, and payment infrastructure should be built around that reality rather than a generic template to optimize your RTV processing and supplier credit recovery.

— Peter

Get ACH Support Built for High-Risk and Subscription Merchants

Multiple acquiring relationships mean you’re not stuck with one bank’s risk appetite when your vertical, whether nutraceuticals, telehealth, or subscription commerce, runs hotter return patterns than typical retail.

Davincipay

Underwriting support, fraud prevention tools, chargeback mitigation, and recurring billing management all work together here, because a merchant fighting ACH returns is usually fighting card disputes with the same root causes: weak authorization records, poor verification at signup, or a billing cadence that doesn’t match customer expectations. Davincipay’s payment processing services are built specifically around the operational realities of high-risk and complex ecommerce, not a one-size-fits-all merchant account.

If you’re running a nutraceuticals business or a supplement brand and your return-rate reports are starting to worry you, don’t wait for your current processor to flag it first. Apply now to talk through your specific return patterns and get a payments setup built to handle them.

Where to Verify These Rules Directly

For rule text and risk-management guidance straight from the source, consult NACHA’s pages on differentiating unauthorized return reasons and the October 2024 risk-management updates. Practical explainers from Plaid and Modern Treasury helped ground the operational examples here. For anything specific to your account or origination status, your ODFI remains the authoritative contact.

Sources