ACH returns
Explicitly, FedACH doesn’t intermediate disputes. This is different to the card networks. However, both the originator and recipient have the means to request a transfer be recalled:
- A recipient can Return a transfer back to the originator.
- An originator can request a Reversal of the transfer from the recipient.
When these mechanisms don’t work, Nacha recommends using non-ACH related dispute resolution mechanisms like contacting the account holder, collections agencies, or courts.
When you send an ACH transfer from Increase, you may receive a return from the receiving bank. When you receive an Inbound ACH transfer in your Increase account, you’ll be able to respond with a return.
How returns work with FedACH
Types of returns
Returns fall into three broad categories:
- Administrative returns are caused by issues like an unrecognized account number, an invalid routing number, or insufficient funds. The administrative ACH returns are
R02,R03andR04. - Unauthorized returns occur when the account holder states the transfer was not authorized. The unauthorized return codes are
R05,R07,R10,R11,R29andR51. - All other returns cover any alternative return reason. This includes the most common return reason:
R01“insufficient funds.”
Return rate monitoring
ACH Originators must keep their return rate below certain thresholds to remain in good standing with Nacha. Return rates are calculated on a 60-day rolling basis as a ratio between the received returns and originated debits in that sixty day window.
| Return type | Threshold |
|---|---|
| Administrative debits | 3.0% |
| Unauthorized debits | 0.5% |
| Total returns | 15% |
Reconciling returns
Returns can be correlated with originating transfers using the date, amount, account number, routing number, and trace number. Trace numbers are 15 digits but with only seven digits of entropy (the leading eight identify the originating financial institution). For any reasonably large institution, it’s usually not possible to uniquely rely on trace numbers for reconciling returns.
Increase automatically reconciles ACH returns and ACH transfers.
Return windows
ACH debits can be returned within two business days for commercial accounts0 and sixty calendar days for consumer accounts1. To reduce unauthorized returns, Nacha recommends (and in some cases requires) validation of account and routing number details before originating a transfer.
Late returns and proof of authorization
Despite the standard return windows, exceptions are made for claims that an ACH debit was unauthorized. In these situations, the receiving bank will ask for an exception to process a late return. The originating bank must provide the proof of authorization or the late return request will be allowed.
If you have a debit returned after the typical window, you’ll see a proof of authorization request appear in your Dashboard. The originating bank has 10 banking days to respond from the time they receive the request2. Alternatively, you can choose to accept the return and won’t need to provide the proof of authorization.
Reinitiating returned ACH transfers
A returned transfer can be reinitiated only under specific circumstances:
| Acceptable circumstances |
|---|
An ACH debit returned for reasons of insufficient or uncollected funds (R01, R09) can be reinitiated a maximum of two times to attempt to recollect funds. |
An ACH debit returned for a reason of a stopped payment (R08) may be re-initiated if it obtains a valid authorization from the receiver to do so. In this instance, it’s important to encourage the receiver to notify their receiving financial institution to remove any stopped payment blocks associated with the originator. |
| An ACH transfer was returned for a different reason, but the issue has been remedied by the originator. |
In all instances, reinitiating must take place within 180 days of the settlement date of the original transfer. Beyond 180 days, all resolution must take place outside of the ACH network.
A reinitiated transfer must be submitted with the company_entry_description set to RETRY PYMT. However, it otherwise must contain identical information to the original transfer, including the company_name, company_identification, and amount fields. Other fields may be modified only to the extent that they correct an error or enable successful processing of a transfer. Any modification to these fields in order to present it as a new transfer, will be treated as a violation of the Nacha rules.
Beyond the reasons above, reinitiating transfers is prohibited. However, Nacha rules specify four scenarios where a transfer is not considered a “reinitiated entry” and therefore is outside of the requirements above.
| Not considered a reinitiated entry |
|---|
| If an originator has preauthorization for sending recurring debits, and a debit transfer is returned, subsequent debits are not considered “reinitiated entries.” For example, if a user’s monthly credit card payment is returned due to insufficient funds, the following monthly payment is still eligible. |
| If an originator receives a new authorization from the receiver after receiving a return, the new transfer will not be considered a “reinitiated entry.” |
If an originator receives a return due to incorrect account or routing information (R03 R04), retrying the transfer with correct account information will not be considered a “reinitiated entry” because it is not technically associated with the same account. |
If an originator receives a return due to not being within the agreed terms of authorization (R11), and they are able to resolve the issue to meet the original terms, they can retry the transfer without obtaining a new authorization from the receiver. |
How returns work at Increase
If you receive a return, Increase will automatically reconcile it with the originating transfer and create a new Transaction to reduce your balance. You can view the return details, including the return_reason_code and the associated transaction_id on the initial transfer. This will allow you to instantly map each of your returns to their initial Transactions. You can also view these details in the Dashboard.
Return Reason Codes
ACH returns are accompanied with a Return Reason Code which is used to describe the reason for the return. While there are ~80 codes, returns most commonly use R01, R02, R03 ,R04, R05, R06, R07, R08, R09, and R10.
| Code | Description |
|---|---|
R01 | Insufficient Funds - The available balance is not sufficient to cover the amount of the debit entry. |
R02 | Account Closed - The previously active account has been closed by the customer or the bank. |
R03 | No Account on file - The account number does not correspond to the individual identified in the entry, or the account number designated is not an open account. |
R04 | Invalid Account Number - The account number provided is incorrect or improperly formatted. |
R05 | Unauthorized Debit to Consumer Account Using Corporate SEC Code - A CCD or CTX debit entry was posted to a consumer account, and the consumer has notified the receiving institution (RDFI) that the entry was not authorized. |
R06 | Returned per ODFI’s Request - The originating institution (ODFI) requested that the receiving institution (RDFI) return the transaction. |
R07 | Authorization Revoked by Customer - The Receiver revoked the authorization previously provided. |
R08 | Payment Stopped - The Receiver placed a stop payment order on the debit Entry |
R09 | Uncollected Funds - The Receiver has a sufficient cash balance but an insufficient available balance. |
R10 | Customer Advises Not Authorized - The Receiver has claimed that the provided authorization is not valid. |
R11 | Customer advises not within Authorization Terms - An authorization to debit exists, but the Receiver has claimed that the entry doesn’t conform to the terms of the authorization. For example, the amount is different or the settlement was earlier than authorized. |
R12 | Account Sold to Another DFI - The account has been sold to another financial institution. |
R13 | Invalid ACH Routing Number - The Receiving Depository Financial Institution (RDFI) is not qualified to participate in ACH or the routing number is invalid. |
R14 | Representative Payee Deceased - The representative payee is deceased or unable to continue in that capacity. The beneficiary is not deceased. |
R15 | Beneficiary or Account Holder Deceased - The beneficiary or account holder is deceased. |
R16 | Account Frozen - (1) Access to the account is restricted due to specific action by the Receiving Depository Financial Institution (RDFI) or by legal action. (2) OFAC has instructed the RDFI to return the entry. |
R17 | File Record Edit Criteria - (1) Field(s) cannot be processed by RDFI; (2) the Entry contains an invalid Account Number (account closed/no account/unable to locate account/invalid account number) and is believed by the RDFI to have been initiated under questionable circumstances. (3) Either the RDFI or Receiver has identified a Reversing Entry as one that was improperly initiated by the Originator or ODFI. |
R18 | Improper Effective Entry Date - Entries have been returned because the effective entry date is not a valid banking day or is more than two banking days in the future. |
R19 | Amount Field Error - (1) Amount field is non-numeric. (2) The amount field is not zero in a Prenotification, Notification of Change, refused Notification of Change, DNE, ENR, or zero dollar CCD, CTX, or IAT Entry. (3) The amount field is zero an Entry other than a Prenotification, Notification of Change, refused Notification of Change, DNE, ENR, or zero dollar CCD, CTX, or IAT. (4) The amount field is greater than $25,000 for ARC, BOC, and POP Entries. |
R20 | Non-Transaction Account - The ACH entry was attempted for a non-transaction account—an account against which transactions are prohibited or limited. |
R21 | Invalid Company Identification - The company ID information is not valid (usually applies to CCD and CTX entries). |
R22 | Invalid Individual ID Number - The Receiver has indicated that the individual ID number used in the entry is not valid. |
R23 | Credit Entry Refused by Receiver - The Receiver has refused the credit entry. |
R24 | Duplicate Entry - The Receiving Depository Financial Institution (RDFI) has identified the entry as a duplicate. The trace number, date, dollar amount and/or other data matches another transaction. |
R25 | Addenda Error - There is an error with the Addenda. (1) The Addenda Record Indicator value is incorrect. (2) The Addenda Type Code is invalid, out of sequence, or missing, (3) Number of Addenda Records exceeds allowable maximum, (4) Addenda Sequence Number is invalid. |
R26 | Mandatory Field Error - There is erroneous or missing data in a mandatory field. |
R27 | Trace Number Error - (1) The original Trace Number is not present in the Addenda of a Notification of Change or Return. (2) The Trace Number of an Addenda record doesn’t match the Trace number in a proceeding Entry Detail Record. |
R28 | Routing Number Check Digit Error - The check digit for a routing number is not valid. |
R29 | Corporate Customer Advises Not Authorized - The Receiver advises that the entry is not authorized. |
R30 | RDFI Not Participant in Check Truncation Program - The Receiving Depository Financial Institution (RDFI) doesn’t participate in a Check Truncation Program. |
R31 | Permissible Return Entry (CCD and CTX only) - The Receiving Depository Financial Institution (RDFI) has been notified by the Originating Depository Financial Institution (ODFI) that it agrees to accept a CCD or CTX return entry beyond normal return time frames. |
R32 | RDFI Non-Settlement - The Receiving Depository Financial Institution (RDFI) is not able to settle the entry. |
R33 | Return of XCK Entry - This Return Reason Code may only be used to return a XCK (Destroyed Check) entry. |
R34 | Limited Participation DFI - The Receiving Depository Financial Institution’s (RDFI) participation in a specific ACH program has been limited by a federal or state supervisor. |
R35 | Return of Improper Debit Entry - Debit Entries are not permitted to loan accounts or for CIE Entries. |
R36 | Return of Improper Credit Entry - Credit Entries are not permitted for ARC, BOC, POP, RCK, TEL, and XCK entries. |
R37 | Source Document Presented for Payment - The source document to which an ARC, BOC, or POC Entry relates has been presented for payment. |
R38 | A stop payment was placed on the source document of the transaction. - The Receiving Depository Financial Institution’s (RDFI) has determined that a stop order has been placed on the source document related to the ARC or BOC Entries. |
R39 | Improper Source Document |
R40 | Return of ENR Entry |
R41 | Invalid Transaction Code |
R42 | Routing Number / Account Number Mismatch |
R43 | Invalid DFI Account Number |
R44 | Invalid Individual Identifier |
R45 | Invalid Individual Name |
R46 | Invalid Representative Payee Indicator |
R47 | Duplicate Enrollment |
R50 | State Law Affecting RCK Acceptance |
R51 | Item is Ineligible, Notice Not Provided |
R52 | Stop Payment on Item |
R53 | Item and ACH Entry Presented for Payment |
R61 | Misrouted Return |
R62 | Incorrect Trace Number |
R63 | Incorrect Dollar Amount |
R64 | Incorrect Individual Identification |
R65 | Incorrect Transaction Code |
R66 | Incorrect Company Identification |
R67 | Duplicate Return |
R68 | Untimely Return |
R69 | Multiple Errors |
R70 | Permissible Return Entry Not Accepted / Notice Not Provided |
R71 | Misrouted Dishonored Return |
R72 | Untimely Dishonored Return |
R73 | Timely Original Return |
R74 | Corrected Return |
R75 | Return Not a Duplicate |
R76 | No Errors Found |
R77 | Non-Acceptance of R62 Dishonored Return |
R78 | Non-Acceptance of R68 Dishonored Return |
R79 | Incorrect Data in Return Entry |
R80 | IAT Entry |
R81 | Non-Participant in IAT Program |
R82 | Invalid Foreign Receiving DFI Identification |
R83 | Foreign Receiving DFI Unable to Settle |
R84 | Entry Not Processed by Gateway |
R85 | Incorrectly Coded Outbound International Payment |