The most common return codes are listed below. You can find a list of all return codes in the Nacha Operating Rules. Return codes are essential for identifying and resolving issues quickly.
\nUnless otherwise noted, the return timeframe is 2 banking days from the settlement date of the original debit.
\nThe available balance in your end-customer's bank account is not enough to cover the ACH debit.
\nRecommended approach:
\nYour end-customer has placed a Stop Payment on the ACH debit.
\nRecommended approach:
\nA sufficient balance exists in your end-customer's bank account, but the available balance is not enough to cover the dollar amount of the ACH debit.
\nRecommended approach:
\nThe debit was returned because the bank account was frozen due to action taken by the RDFI or legal action, OR the debit was returned by OFAC's instruction.
\nRecommended approach:
\nThis return code warrants attention. If the account is in a \"frozen\" status and a debit is re-initiated without contacting the customer, it is highly likely that the debit will be returned again.
\nThe debit was originated with an invalid account number leading the RDFI to believe it was originated under questionable circumstances.
\nRecommended approach:
\nPlaid's Auth Product typically prevents \"Invalid Account Number\" returns, which signify that the receiving financial institution (RDFI) does not recognize the account number used in the ACH transaction. If this type of return occurs:
\nThe ACH entry is destined for a non-transaction account, for example an IRA or General Ledger account.
\nRecommended approach:
\nReturns in this category consist of three types. Validating account and routing details, along with verifying end-customer identity, can greatly decrease these return types.
\nA previously active account is now closed by action of the account holder or their financial institution.
\nRecommended approach:
\nIf an account is closed, it will not be re-opened, so debits returned with this code should never be re-initiated.
\nThe account number structure is valid, but the account number does not correspond to the individual identified in the transaction, or the account number provided does not correspond to an existing account. The RDFI is not obligated to check whether the name on the transaction matches the name on the account, but they may do so at their discretion. The RDFI may have also included the reason for the R03 return in the addenda record of the return entry.
\nRecommended approach:
\nThis return code indicates a high-risk scenario, potentially stemming from compromised account details and unauthorized usage. Upon receiving this type of return, the following actions should be taken:
\nThe account number in the ACH transfer is incorrect or improperly formatted.
\nRecommended approach:
\nFor a debit initiated to a Chase Bank account, check if the return webhook reason is USER_PERMISSION_REVOKED to determine if the TAN was revoked.
If the return is from another bank:
\nOnce an unauthorized debit return is received, it cannot be disputed or contested through the ACH network, even in cases of suspected friendly fraud. Any disputes regarding unauthorized debit returns must be resolved outside of the ACH network, such as through legal action.
\nUnauthorized ACH debits are often assumed to be fraudulent, but the reality is more complex. These returns can stem from various issues, including actual fraud, a customer revoking authorization, consumer confusion about charges, misunderstandings regarding payments, or failures to adhere to authorization regulations by you, the originator of the transaction.
\nCustomers may return debits as unauthorized for several reasons:
\nA consumer disputed an ACH debit to their bank account, claiming it was unauthorized. The transaction was coded as business-to-business. Consequently, the RDFI returned the debit with an R05 code, indicating the account is not a business account and the consumer (owner) did not authorize the debit.
\nRecommended approach:
\nThe customer returned the unauthorized debit, claiming they revoked permission with you beforehand, indicating a potential timing issue between revocation and debit processing. Investigation is needed.
\nRecommended approach:
\nThe account holder does not recognize the debiting party, has no relationship with them, or did not authorize the debit to their bank account.
\nRecommended approach:
\nThe end-customer, having acknowledged authorizing the debit, is disputing it as unauthorized, claiming a breach of the agreed-upon terms. An ACH debit can be disputed as unauthorized if the debit date or amount is incorrect.
\nRecommended approach:
\nThe business entity has not given the Originator permission to debit their account, or hasn't authorized the debit amount or date.
\nReturn window: 2 banking days from the settlement date — unlike the consumer unauthorized return codes above (R05, R07, R10, R11), R29 applies to corporate accounts and uses the shorter administrative return window, not the 60-day consumer window.
\nRecommended approach:
\nAn RCK entry is considered to be ineligible or improper.
\nThis return code is not applicable to Transfers, as RCK coded debits are not supported.
","user_segment_ids":[]}}