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.
How returns work with FedACH
ACH transfers can be returned. For corporate accounts this period is two business days. For consumer accounts, this is sixty days. To reduce unauthorized returns, Nacha recommends (and in some cases requires) validation of account and routing number details.
Common return reasons are that the account number isn’t recognized, the account has insufficient funds, and that the account holder states the transfer is unauthorized. Transfer returns can roughly be divided into administrative return (the account number isn't recognized, for example) and unauthorized returns (the account holder stated the transfer wasn’t authorized). Nacha mandates that administrative returns must be limited to 15% and unauthorized returns must be limited to 0.5%. Both are calculated on monthly count.
Returns can be correlated with originating transfers by using the date, amount, account number, routing number, and the trace number. Trace numbers are 15 digits but with only seven digits of entropy (as the leading eight identify the original financial institution). Trace numbers need to be unique in a Nacha file and monotonically increase. For any reasonably large institution, it’s usually not possible to uniquely rely on trace numbers for reconciling returns.
Most ACH debits are typically able to be returned within 2 days for debits from commercial accounts [0] and 60 days for debits from consumer accounts [1]. Despite these 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 request [2].
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, its 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 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 |
[0] NACHA Operating Guidelines, Section II, Chapter 26 Returns of Unauthorized/Improper Corporate Debits
[1] NACHA Operating Guidelines, Section II, Chapter 26 Returns of Unauthorized/Improper/Incomplete Consumer Debit Entries
[2] NACHA Operating Rules Subsection 2.3.2.7 Retention and Provision of the Record of Authorization