ACH Returns

AN ACH return is a rejection of an ACH transaction. For example, an ACH debit may be returned if there is insufficient funds in the bank account being debited.

Merchant Responsibilities related to ACH Returns

The merchant should have processes in place to manage the following when processing ACH transactions:

  • Regularly review ACH Returns, root causing why they occurred and how to prevent future returns
  • Implement logic to ensure transactions meet NACHA's retry rules
  • Ensure the ACH program is staying below NACHA return rate thresholds
  • Manage Notifications of Change (NOCs)
  • Handing POA requests
  • Request WSUDs, where applicable

ACH Return Reporting

ACH reporting will be received either by the ACH Return File, if using file-based ACH, or the Daily Exceptions Report, if using the ACH API. Note that if you are using the ACH API, you may request the ACH Return File in addition to the Daily Exceptions Report by emailing [email protected]. Review the returns and the return reasons to root cause why the returns are occurring, and how they can be avoided in the future.

Information on ACH Return Reason Codes can be found here.


Retrying Transactions with Returns

For returned entries other than RCK entries, the NACHA Operating Rules only permit reinitiating a returned entry if:

  1. The entry has been returned for insufficient or uncollected funds
    1. IMPORTANT: The entry can only be reinitiated a maximum of two times following the return of the original entry
  2. The entry has been returned for stopped payment and reinitiation has been authorized by the Receiver
  3. The merchant has taken corrective action to remedy the reason for the return.

NACHA Return Rate Thresholds

When originating ACH debits, merchants are responsible for monitoring their compliance with NACHA’s “ACH Network Risk and Enforcement Rule”, which established an unauthorized return rate threshold of 0.5%, an administrative return rate threshold of 3.0%, and an overall return rate threshold of 15.0%.

Unauthorized Return Rate: the rate at which a Client’s debit Entries are returned on the basis that they were unauthorized (Return Reason Codes R05, R07, R10, R11, R29, or R51)

Administrative Return Rate: the rate at which a Client’s debit Entries are returned for administrative reasons (Return Reason Codes R02, R03, or R04)

Overall Return Rate: the rate at which a Client’s debit Entries, excluding RCK Entries, are returned, regardless of reason

Merchants’ ACH programs are required to stay below these thresholds to remain compliant with NACHA’s rules. These thresholds are measured over a rolling 60-day period. To calculate these thresholds, divide the total count of returns in a rolling 60-day period for the relevant return codes by the total count of forward debits in a rolling 60 day period.

If a merchant is above the aforementioned thresolds, the ACH program is at risk of being suspended. TabaPay may require that the merchant provide a detailed remediation plan to remain in compliance with NACHA and Bank expectations.


Notification of Change (NOC) Process

Notification of Change (NOC) is a non-dollar entry transmitted by the Receiving Depository Financial Institution to notify the ACH Originator that information in the originated ACH is erroneous and/or is outdated and must be changed. In the instance of a received NOC, the merchant will see the NOC via the daily ACH Returns file (or Exceptions file when using the ACH API). The ACH Rules require the ACH Originator to make the requested changes within 6 business days of receipt of the NOC or prior to the next ACH entry, whichever is later.

Therefore, the merchant must have a process in place to review the ACH returns daily and correct the information as required by the return code reason. The NOC return codes have a 'C' prefix; see this table for a list of NOC return codes and their descriptions.


Request for Proof of Authorization (POA)

The bank may contact TabaPay asking that the merchant provide proof of authorization (POA) for an ACH debit. The merchant must provide POA within 10 calendar days from when the bank received the request. Otherwise, the merchant will accept liability for the return. If the merchant does not have POA, they need to modify their upstream process to ensure they are capturing authorization from the customer before initiating any ACH debits.

Upon receiving a POA request, gather all relevant transaction details, including: the original authorization form (e.g., signed document, verbal authorization recording, or electronic authorization), date and time of the transaction, customer details (name, account number, etc.), and any additional evidence that the customer authorized the debit. Merchants must verify the customer’s authorization was valid and obtained correctly, and that all documentation is completed and accessible.


Written Statement of Unauthorized Debits (WSUD)

While there is no dispute process for ACH returns as there is for card transactions, there are instances where merchants can submit documentation to request a Written Statement of Unauthorized Debits (WSUD) when an unauthorized return occurs. When requested, the RFDI (institution where the debited bank account is from) is required to answer within 10 banking days. If you would like to request to go through the WSUD process, please submit the request to [email protected] and include the following information:

  • Trace Number
  • Settlement Date
  • Receiver Name
  • Amount of transaction
  • Unauthorized Return Code


Questions? Contact Sales or make a post