Streamline Your Payment Flows From End to End With Virtual Account Numbers. Sign Up to Access!

As an Accredited Payments Risk Professional (APRP), part of my job is to answer questions from clients and coworkers about the logistics and rules around the ACH Network. While ACH return codes and reversals may not be the most exciting topics, it’s imperative for businesses that participate in ACH transfers to understand.

ACH returns (sometimes reversals) are a part of life when powering account-to-account payments. No matter how many safeguards are in place, the opportunity still exists for account information to be incorrectly entered, for funds to be unavailable or an account to close without your knowledge.

While Dwolla’s payment technology automates aspects of the returns and reversals process, we are not responsible for managing the effects of an ACH return or reversal on behalf of our clients or partners—that responsibility still falls on you. But you don’t have to become an expert on ACH returns or reversals, you just need to know where to look within your Dwolla Dashboard.

Some of the most common questions I get with ACH returns and reversals are:

  • What are ACH return codes?
  • Why am I receiving an ACH return?
  • What are the return codes and their respective time frames?
  • What are return rates?
  • What is my recourse for a return that I don’t agree with?
  • When can I request a reversal?

ACH returns and reversals are complex, at best. In an attempt to make it easier to understand, we’ll answer these questions and highlight some important information to help you navigate the waters.

Blog: Why Knowing Your Customers Matters

 

ACH Participants

As a high level overview, there are five main participants involved in an ACH transaction:

  1. Originator – Submits transfer instructions to ODFI.
  2. Originating Depository Financial Institution (ODFI) – Receives the payment instructions and then transmits the ACH entries to the ACH Operator.
  3. ACH Operator – The central facility for the clearing, delivery and settlement of entries between or among participating Financial Institutions.
  4. Receiving Depository Financial Institution (RDFI) – Receives ACH entries from the ACH Operator and posts the entries to the accounts of its depositors (Receivers).
  5. Receiver – Individual or business whose account is receiving the credit or debit who has authorized an Originator to initiate an ACH entry to the Receiver’s account held at the RDFI.

What Are ACH Returns?

An ACH return is, put simply, a message that lets the ODFI know the ACH Network couldn’t collect funds from or deposit funds into a Receiver’s account. Typically, an ACH return comes from the RDFI, but in some instances the ODFI or even the ACH Operator itself might send such a message. ACH returns must be sent within time frames established by Nacha rules.

For a few best practices to help lower returns, prevent losses due to returns and eliminate the need for reversals, read to the end of this blog!

Why Am I Receiving ACH Returns?

ACH returns are not unusual in ACH processing, and standard practices exist to manage them efficiently. The returns received provide an indicator to alert the Originator of the reason for return. These are called return codes and they consist of an R followed by two numeric digits (i.e., R01).

There are around 70 unique return codes, which help the Originator of the transaction to identify the reason for a return. Each return code is specific to certain entry types and has specific time frames for return.

What Are Some Common Return Codes?

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
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 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.
Written Statement is required.
CCD, CTX (consumer only) 60 calendar days
Authorization Revoked by Customer R07 Consumer who previously authorized entries has revoked authorization with the Originator.
Written Statement is required.
PPD, TEL and WEB 60 calendar 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
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.
Written Statement is required.
ALL DEBIT ENTRIES (except CCD, CTX and RCK) 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 receive or amount was inaccurately obtained.
Written statement is required.
ALL DEBIT ENTRIES (except CCD, CTX and RCK) 60 calendar 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
Corporate Customer Advises Not Authorized R29 Receiver has notified RDFI that corporate debit entry transmitted to a corporate account is not authorized. CCD, CTX 2 banking days

 

Entry Types and Time Frames for Return

Another way to classify ACH transactions is by a Standard Entry Class (SEC) Code. This is a three-letter code that enables a financial institution (FI) to identify the purpose of a transaction. A few examples of SEC codes are:

  • WEB (Internet Initiated/Mobile Entries) — A credit or debit entry initiated online or via mobile device to a consumer’s account.
  • CCD (Corporate Credit or Debit Entries) — A credit or debit entry used to facilitate business-to-business payments.
  • PPD (Prearranged Payment and Deposit Entries) — A credit of debit entry originated by an organization to a consumer’s account, based on standing or single entry authorization.

As you can see, some of the return codes apply to all SEC codes, while others are specific to certain types.

Have Questions? Talk to a Payments Expert

 

Time Frame for Returns

The typical time frame for an RDFI to return a transaction is two banking days. Certain situations (such as unauthorized transactions) allow for an extended time frame of 60 calendar days for the RDFI to initiate a return when the transaction involves a consumer account.

Proof of Authorization to Debit

Although the rules generally require RDFIs to process returns within 2-60 days, an RDFI may request proof of authorization and/or permission to return within two years of the settlement date. Therefore, the Originator has the responsibility to retain all appropriate documentation showing authorization to debit. Dwolla works with our clients to ensure that these obligations are met.

If the provided proof of authorization does not meet the Nacha Rules and Guidelines, the ODFI may be required to permit the RDFI to return the transaction. An authorization must include the full name of the Receiver, match the individual’s name authorized on the bank account and:

  • Be readily identifiable as an authorization.
  • Have clear and readily understandable terms.

What can I do if I receive an ACH return because my customer claims a transaction was unauthorized?

Per Nacha rules, certain consumer returns (as shown in the chart above) require a Written Statement of Unauthorized Debit (WSUD). If the ODFI receives a WSUD with data that can’t be rebutted with an appropriate proof of authorization, the return must be accepted. For example, if the user name on the account does not match the name of the individual who provided authorization.

How do I know if I received an ACH return?

Dwolla’s webhook subscriptions allow a business to systematically receive a notification with links to additional information when certain activities, such as ACH returns, occur.

A webhook will also be received when transactions are initiated and complete.

Is there any penalty for having ACH transactions returned?

Yes. Nacha rules require that each Originator maintain a percentage of ACH debit returns under specific thresholds:

  • Administrative Returns must stay below 3%. This percentage is calculated based on ACH debit returns for the preceding 60 days on the following return reason codes: R02, R03 and R04.
  • Unauthorized Returns must stay below 0.5%. This percentage is calculated based on ACH debit returns for the preceding 60 days on the following return reason codes: R05, R07, R10, R29 and R51.
  • Overall Returns must stay below 15%. This percentage is calculated based on ACH debit returns for the preceding 60 days and includes all return reason codes. This includes NSF (non-sufficient funds) returns (reason codes R01 and R09).

Dishonoring ACH Returns

Dwolla can request the ODFI send back (or dishonor) a return if it is:

  • Untimely (not within the proper time frames for return)
  • Contained incorrect information
  • Misrouted
  • Duplicated
  • Resulted in an unintended credit to the Receiver related to the reversal process.

A dishonored return must be transmitted within five banking days of the settlement date of the return. Please be aware that the RDFI is able to contest a dishonored return, in which case recovery of the funds would need to happen outside of the ACH Network.

ACH Reversals

Dwolla can also request our ODFI send a reversing entry to attempt to reverse an erroneous or duplicate file. The following ACH transfers qualify as an erroneous entry:

  • A duplicate of an entry previously initiated by the Originator.
  • Payment to or from a Receiver different than the Receiver intended to be credited or debited by the Originator.
  • Payment in an amount different than was intended by the Originator.
  • Orders payment of a debit entry on a date earlier than the Receiver was intended to be debited by the Originator, or payment of a credit entry on a date later than the Receiver was intended to be credited by the Originator.
  • A PPD credit entry satisfying each of the following criteria:
    • The PPD credit is for funds related to a Receiver’s employment.
    • The value of the PPD credit is fully included in the amount of a check delivered to the same Receiver at or prior to the Receiver’s separation from employment.
    • The PPD credit entry was transmitted prior to the delivery of the check to the Receiver.

Reversing entries must be transmitted to or made available to the RDFI within five banking days following the settlement date of the erroneous entry. Eligible entries for reversals must clearly fit into the categories outlined above, claims of fraud are not eligible.

Please note that ACH reversals are not a guarantee that funds will be returned because the funds may have already been withdrawn. Once a reversal request has been sent, the RDFI has two banking days from the settlement date to return the entry.

The Fewer Returns, The Better

Return codes can happen regardless of the number of safeguards in place. Depending on the type of returns you are receiving, there are several best practices you can implement to help lower returns, prevent losses due to returns and eliminate the need for reversals.

  • Monitor for excessive returns by end users within your platform.
  • Have a fraud monitoring/prevention process in place to combat unauthorized returns and malicious users.
  • Establish transaction limits and tiered onboarding for users (ex: customers onboard for less than 30 days, repeat NSF offenders, low transaction volume).
  • Give your end users the option to cancel a transaction within a set time frame. This can help prevent them from submitting a payment they didn’t intend to and then disputing it as unauthorized.
  • Conduct balance checks and use name returns when verifying bank accounts to ensure your user’s name matches the account holder’s and there are funds in the account.
  • Monitor IP address usage. An end user signing in from a new IP or multiple IP addresses at the same time could indicate fraud.
  • Again, build out your own robust CIP/KYC. Onboarding with additional information from your end users can help you understand who they are and what they’re trying to do. Asking for additional documentation such as bank statements and photo IDs can help ensure the person who signed up on your platform is who they say they are.

 

Ready to Get Started?

Stay Updated