## ACH Returns FAQ

- Jul 22, 2025
- Knowledge

### Information

**Title**  
ACH Returns FAQ  
**Summary**

#### What is the dispute process for ACH?

Unfortunately, the disputes come from the Receiver (the RDFI's customer) of the transaction and as long as the return is within the appropriate time frame, they have the right to dispute. It is important to obtain a valid authorization and know your customer to help mitigate some of that risk.

Unlike credit card disputes (chargebacks) ACH returns do not have a back and forth dispute process. While some returns can be dishonored with another return code issued to the RDFI, there are specific guidelines that need to be met. Returns can be dishonored within five banking days of the settlement date of the return (as long as it is received by opening of business on the 5th banking day) but only if it has one of these reasons: "was untimely; contained incorrect information; was misrouted; was a duplicate; or resulted in an unintended credit to the Receiver related to the reversal process."

#### What is the difference between a Return and a Reversal?

An ACH reversal refers to an erroneous ACH payment that a payment originator requests to take back or reverse. The Client can request a reversal within 5 banking days of the transaction being initiated (the settlement date). We would need  the transaction information and the reason for the reversal:

1. Duplicate payment
2. Incorrect payment recipient
3. Incorrect payment amount
4. Payment date earlier than intended (ACH debit only)
5. Payment date later than intended (ACH credit only)

An ACH return occurs when the Receiving Depository Financial Institution (RDFI) initiates a return to the Originating Depository Financial Institution (ODFI). There are various reasons an RDFI would have a reason to initiate a return ranging from an incorrect account or routing number, name mismatch, or the transaction is being reported as unauthorized by the account holder. Below is a chart of the most common return codes, their meanings and other helpful information.

##### Administrative Returns

|     |     |     |     |     |
| --- | --- | --- | --- | --- |
| Reason for Return | Return Code | Description | Entry Type | Time Frame |
| Account Closed | R02 | Previously active account has been closed | ALL | 2 banking days |
| No Account/Unable to Locate Account | R03 | Account number structure is valid but doesn’t match individual identified in entry or is not an open account | ALL | 2 banking days |
| Invalid Account Number | R04 | Account number structure is not valid | ALL | 2 banking days |

##### Unauthorized Returns

|     |     |     |     |     |
| --- | --- | --- | --- | --- |
| Reason for Return | Return Code | Description | Entry Type | Time Frame |
| Unauthorized Debit to Consumer Account Using  Corporate SEC Code | R05 | A debit entry was transmitted to a consumer account that was not authorized by the Receiver. | CCD (consumer only) | 60 calendar days |
| Authorization Revoked by Customer | R07 | Consumer who previously authorized entries has revoked authorization with the Originator. | PPD, TEL and WEB | 60 calendar days |
| Customer Advises Originator is Not Known to Receiver and/or Originator is Not Authorized by Receiver to Debit Receiver’s Account | R10 | Receiver has no relationship with the Originator or has not authorized the Originator to debit the account. | ALL | 60 calendar days |
| Customer Advises Entry Not in Accordance with the Terms of the Authorization | R11 | The debit entry was inaccurate or improperly initiated. Other reasons include: source document was ineligible, notice was not provided to the receiver or the account was inaccurately obtained. | ALL (except CCD, CTX and RCK) | 60 calendar days |
| Corporate Customer Advises Not Authorized | R29 | Receiver has notified RDFI that corporate debit entry transmitted to a corporate account is not authorized. | CCD | 2 banking days |

##### General Returns

|     |     |     |     |     |
| --- | --- | --- | --- | --- |
| Reason for Return | Return Code | Description | Entry Type | Time Frame |
| Insufficient Funds | R01 | Available balance is not sufficient to cover the dollar value of the debit entry | ALL | 2 banking days |
| Payment Stopped | R08 | The Receiver has requested the stop payment of a specific ACH debit entry. | ALL | 2 banking days |
| Uncollected Funds | R09 | Sufficient balance exists, but value of uncollected items brings available balance below amount of debit entry. | ALL | 2 banking days |
| Account Frozen | R16 | Funds unavailable due to action by the RDFI or legal action | ALL | 2 banking days |
| Non-Transaction Account | R20 | RDFI policies/regulations restrict activity to account | ALL | 2 banking days |

#### Can returns happen outside of the standard timeframe?

For warranty claims relating to non-consumer accounts, RDFIs must make their claims to the ODFIs within one year from the Settlement Date of the reported unauthorized transaction.

For warranty claims relating to consumer accounts, the Rule allows a longer time: two years from the Settlement Date.

In this context, “warranty” means that the financial institution sending the transaction warrants that the RDFI’s customer gave the party receiving the payment authorization to debit the Receiver’s bank account. NACHA Rules determine the time frame in which a claim made by the RDFI is permissible.

#### What recourse do I have for an Unauthorized Return?

If the return is initiated by the RDFI within the 60 day NACHA Timeframe,  Dwolla is not able to dishonor the return, nor have the opportunity to ask for additional information before the return takes place. If you are not already established with one of our bank validation partners, we’d be happy to explore the various options available to you for incorporating identity and balance checks when onboarding your end users.

#### What is a ‘Proof of Authorization’ Request?

Dwolla receives requests as "Proof of Authorization" for Unauthorized Return codes from our ODFI. The Dwolla Risk team will provide that documentation to the ODFI who passes it along to the RDFI requesting to see what was collected. At times the Risk team may reach out to request additional supporting documentation to prove that the authorization and transactions were valid.

If a proof of authorization does not match the information provided by the RDFI about their customer or the authorization is not considered valid, permission to return may be granted.

Common practices to mitigate this risk would be KYC due diligence and/or a verification process confirming the account owner 1) created the authorization and 2) is listed with the RDFI as an account holder or authorized signer.

#### Maintaining acceptable return rate thresholds

NACHA (National Automated Clearing House Association) is the governing body that defines rules and standards for ACH payments. Dwolla expects all clients to remain within the Return Risk Thresholds, established by NACHA, as follows:

[Unauthorized](https://docs.google.com/document/d/1daDg0SlrZdTd8AN8vpZyzVUdwW_EVLfRMPQddyWvjrg/edit#heading=h.u6dsde7cikz4) = 0.5% or less  
[Administrative](https://docs.google.com/document/d/1daDg0SlrZdTd8AN8vpZyzVUdwW_EVLfRMPQddyWvjrg/edit#heading=h.pvdv1b53tcuh) =  3% or less  
[Overall](https://docs.google.com/document/d/1daDg0SlrZdTd8AN8vpZyzVUdwW_EVLfRMPQddyWvjrg/edit#heading=h.2qianpz4qnw7) = 15% or less

#### How can I be proactive about my return rates?

We have compiled helpful information in our [Dwolla ACH Operational Guide](/content/p/ach-operational-guide/index.html), chapter 2 covers returns and is a great place to start. We encourage you to monitor and track your own return rates to identify and address any patterns early on. You can use our [Developer Documentation](https://developers.dwolla.com/api-reference/transfers/retrieve-a-transfer-failure-reason) to build your own custom reporting and analysis.

Understanding how return rates are calculated is also an important part of proactive return rate management. Divide the number of debit Entries returned as unauthorized (see all [unauthorized](https://docs.google.com/document/d/1daDg0SlrZdTd8AN8vpZyzVUdwW_EVLfRMPQddyWvjrg/edit#heading=h.u6dsde7cikz4) return codes to include) for the preceding sixty days or two calendar months by the total number of debit Entries originated for the preceding sixty days or two calendar months, respectively. Follow this same calculation for [Administrative](https://docs.google.com/document/d/1daDg0SlrZdTd8AN8vpZyzVUdwW_EVLfRMPQddyWvjrg/edit#heading=h.pvdv1b53tcuh) and [Overall](https://docs.google.com/document/d/1daDg0SlrZdTd8AN8vpZyzVUdwW_EVLfRMPQddyWvjrg/edit#heading=h.2qianpz4qnw7) Return rates including all appropriate return codes for each category.

#### Negative balance resolution

It is important to ensure that when end users are onboarded through your platform that you are performing appropriate identity and financial checks prior to allowing transactions to be initiated. Per the [Dwolla Platform Agreement](/content/legal/platform-agreement/index.html), section 1.10 “You are solely responsible for you and your end users’ payment activity initiated using the Dwolla Platform Services, including, without limitation, any fraudulent activity.” Subsequently, we recommend that you have appropriate transaction monitoring procedures in place to ensure you are not exposed to unnecessary financial loss due to your end user’s activity, as this is not a service that Dwolla provides to our clients.

**URL Name**  
ACH-Returns-FAQ