What It Means & How Businesses Should Respond?

ACH return code R11 means a customer disputes a debit they actually authorized, because the transaction broke the agreed terms — wrong amount, wrong date, or another detail outside the authorization. You don’t need a new authorization to retry: correct the error and resubmit within the allowed window. NACHA repurposed R11 on April 1, 2020, replacing its old “Check Truncation Entry Return” definition with “Customer Advises Entry Not in Accordance with the Terms of the Authorization.” That separates it from R10, which covers customers claiming no authorization ever existed. R10 draws stricter monitoring; R11 flags a fixable process error instead.

What is an ACH Return Code?

ACH return codes are standardized three-character messages — a letter “R” followed by two digits — that the Receiving Depository Financial Institution (RDFI) sends back to the Originating Depository Financial Institution (ODFI) when a transaction cannot be completed as submitted. NACHA, the organization that governs the ACH Network, maintains more than 80 of these codes, covering everything from insufficient funds to closed accounts to disputed authorizations.  

Each code exists to give both parties in a transaction — the business originating the debit and the customer’s bank — a consistent, auditable reason for the failure. For businesses running recurring billing, subscription payments, or B2B invoicing over ACH, fluency in these codes is a basic operational requirement, not an occasional troubleshooting task.

Click here to learn about ACH Return Codes

ACH Return Code R11

ACH return code R11 indicates that a receiving customer disputes an otherwise authorized debit because it did not match the agreed terms — most often the wrong amount, an incorrect date, or a processing detail that fell outside the original authorization. Unlike a fully unauthorized transaction, an R11 return does not require a business to collect a new authorization before trying again; it requires correcting the error and resubmitting within the allowed window. Understanding this distinction is essential for any organization that originates recurring ACH debits, since R11 volume has climbed steadily since the code was repurposed and now represents a meaningful share of total returns.

Historically, R11 was defined narrowly as a “Check Truncation Entry Return,” used only for disputes tied to paper checks converted into electronic ACH debits (XCK entries). That definition changed under a NACHA rule that took effect April 1, 2020. R11 was repurposed to give ODFIs and originators a more precise signal than the older R10 code allowed.

Under the current NACHA Operating Rules, R11 is defined as “Customer Advises Entry Not in Accordance with the Terms of the Authorization.” It applies when a valid authorization exists between the originator and the receiver, but a specific transaction breaks the terms of that authorization — for example, an incorrect debit amount, a debit processed earlier or later than agreed, or another discrepancy in how the entry was executed.

This is a meaningful separation from R10, which is reserved for cases where the customer claims no authorization ever existed. The distinction matters because R10 returns are treated as fully unauthorized and monitored more strictly, while R11 returns signal a correctable process error rather than a breakdown in consent.

R11 vs. R10: Why the Difference Matters for Compliance

NACHA tracks unauthorized return rates at the ODFI level and enforces a 0.5% threshold; exceeding it can trigger corrective action, additional scrutiny, or restrictions on ACH origination privileges. Because R11 is categorized separately from true unauthorized returns like R10, R05, R07, and R29, businesses that correct genuine payment errors — rather than debiting without consent — are less likely to be flagged as high-risk originators. Accurately classifying returns, rather than lumping every dispute into the unauthorized bucket, has a direct effect on an organization’s standing with its processor and bank.

Common Causes of an R11 Return

Several recurring scenarios trigger an R11 return under an existing authorization:

• The debit amount did not match what the customer agreed to.
• The transaction was processed on a date outside the authorized window.
• A recurring payment was initiated with outdated billing details.
• The customer identified a documentation or record-keeping discrepancy tied to the original agreement.

Because an R11 return confirms that authorization exists, the underlying issue is almost always procedural — a data entry mistake, a timing misconfiguration, or an outdated payment record — rather than a dispute over consent itself. 

How to Resolve an ACH Return Code R11?

Businesses that receive an R11 return should treat it as a correction workflow rather than a collections problem:

1. Identify the specific discrepancy. Compare the returned entry against the original authorization to confirm what did not match — amount, date, or another term.
2. Correct the underlying record. Update billing systems, payment schedules, or account details so the error cannot recur on future attempts.
3. Resubmit within 60 days. NACHA rules allow a corrected entry to be submitted without obtaining a new authorization, provided it is initiated within 60 days of the original return’s settlement date.
4. Verify authorization terms before resubmitting. Confirm the corrected entry conforms exactly to the terms the customer originally agreed to, since a second mismatch can trigger another return or escalate customer frustration.
5. Document everything. Retain records of the original authorization, the error, the correction, and any customer communication in case the return is contested later.

Automated verification tools reduce how often these errors occur in the first place. ACHgenie’s real-time account and payment verification checks amount, timing, and account data against stored authorization records before a debit is submitted, which helps originators catch mismatches before they generate a return at all. 

Preventing Future R11 Returns

Reducing R11 volume comes down to tightening the processes around authorization data and payment execution:

• Keep customer authorization records current, especially after any change to billing amount or schedule.
• Reconcile payment dates against the authorized window before each batch submission.
• Use automated pre-submission checks to catch amount or timing mismatches before entries are sent to the ACH Network.
• Train billing and finance staff to treat R11 as a data-accuracy signal, not a fraud signal, and route it accordingly.

For businesses processing high volumes of recurring debits, manual reconciliation is rarely sustainable. Platforms like ACHgenie that build authorization-matching directly into the ACH origination workflow give originators a way to catch discrepancies proactively, rather than discovering them after a return and a fee. 

“FAQ’s”

What does ACH return code R11 mean?

R11 means “Customer Advises Entry Not in Accordance with the Terms of the Authorization.” It signals that a valid authorization exists, but a specific transaction — such as the amount or date — did not match what was agreed.

Is R11 considered an unauthorized return?

No. R11 is tracked separately from unauthorized returns like R10, R05, R07, and R29. It reflects an error within an authorized relationship, not a lack of consent.

Does a business need a new authorization after an R11 return?

No. A corrected entry can be resubmitted without a new authorization, as long as it is submitted within 60 days of the original return’s settlement date.

What used to cause an ACH return code R11 before 2020?

Before April 1, 2020, R11 was defined as “Check Truncation Entry Return” and applied specifically to disputed check-to-ACH conversion entries. That definition was replaced by the current authorization-error meaning.

How can businesses reduce R11 returns?

Keeping authorization records current, verifying payment amounts and dates before submission, and using automated pre-debit verification tools are the most effective ways to prevent R11 returns.