An ACH Return is the message that describes why an ACH was returned and is accompanied by the corresponding ACH return code defining the reason. Returns need to be viewed from two perspectives - one as the ODFI and the other as the RDFI.
When you're sending payments (Column as the ODFI), some of these payments may be returned by the RDFI. When you're receiving payments to a bank account on Column (as the RDFI) you can initiate returns. Both can be programmatically handled through Column's API and your dashboard.
An ACH Return is sent by the receiving bank (RDFI) through the ACH network in response to an ACH transfer you initiated via Column. The ACH network doesn't send a acknowledgment that an ACH payment has succeeded - the payment is determined successful by not receiving a return.
A return means the transaction was not settled successfully for a reason specified by the ACH Return Code (there are 80+ of these) the RDFI sends back. Common reasons include:
- The receiving account has insufficient funds to cover the account debit (
- The receiving account has been closed or the account number is invalid (
- The owner of the receiving bank account requested a stop payment on the debit (
- The owner of the receiving bank account did not authorize the transaction (
NACHA, the governing body for the ACH network, has specific rules for the time frame within which the RDFI can initiate an ACH return. Most returns need to be submitted within
2 business days, otherwise the transaction will be settled. However, some return codes (e.g. unauthorized claims) can be sent back within
60 calendar days.
The industry refers to returns that must be sent within 2 days as t+2 returns. ACH transfers between commercial customers must generally be returned within 2 days. Returns that need to be sent under 60 days are referred to as t+60 returns. ACH transfers to consumers may generally be returned within 60 days.
After receiving your ACH transfer requests, Column will submit them to the Federal Reserve based on the effective dates of your requests.
- For outgoing debit ACH requests, if we do not receive any returns from the RDFIs for your requests within
2business days of the effective date, we will settle your transfers and send
ach.outgoing_transfer.settledevents via webhook endpoints.
- If we receive a return in the defined window , we will mark the transfers as returned and send the
ach.outgoing_transfer.returnedevent via the webhook endpoint. As mentioned above, RDFIs may send returns within
60calendar days, even after we settle the transfers. In that case, we will mark the transfers as returned and send the
ach.outgoing_transfer.returnedevent as well.
If we do not receive any returns after
60 calendar days, we will make the transfers as completed and send
ach.outgoing_transfer.completed events via webhook endpoints. A completed ACH transfer cannot be returned.
We offer the ability to simulate a return on an outgoing ACH. In order to do this, you can set the "receiver_name" field on an outgoing ACH to the following:
|receiver_name||ACH Return Code||Description|
|"RETURN_NSF"||R01||Not-sufficient funds in recipient account|
|"RETURN_ACCOUNT_CLOSED"||R02||Recipient account has been closed|
|"RETURN_STOP_PAYMENT"||R08||Recipient has requested a stop payment on this transfer|
For inbound ACH transfers that you receive from other ODFIs (Column is the RDFI for inbound transfers), you can submit requests to return those inbound transfers on behalf of your customers via our ACH Return API. While you can call our API to initiate returns, Column will automatically submit returns on your behalf in a lot of cases. Column automatically submits return for codes
Each inbound transfer can be returned only once (you can verify by checking if
ach_transfer.returned_at field is set). You cannot submit requests to return outbound transfers (i.e.
ach_transfer.is_incoming = false) that you initiate via our ACH Transfer API..
In the rare situation where there is an ACH return back to a closed account, Column will process the transaction and update the balance of the closed account. If funds are being returned to a closed account, the account balance will increase. If funds need to be returned out of a closed account, the account balance will go negative. Funds from your overdraft reserve, or program reserve will be used to cover the return.
An ACH Return can have the following statuses:
Initiated: The return request has been created. If returning an incoming credit, funds are removed from the account.
Sent: The return has been sent to the Fed for processing.
Dishonored: The return has been dishonored by the ODFI.
Contested: The return status of the return is contested between ODFI and RDFI. This must be solved manually outside the ACH network.
Completed: A contested return has been resolved offline and successfully processed.
Rejected: A contested return has been resolved offline and not processed.
There are strict rules that dictate when you can initiate a return. For administrative returns, you must initiate the return no later than the opening of business on the
2nd banking day following the inbound ACH transfer. For unauthorized returns, the return must be before the opening of business on the
60th calendar day following original inbound ACH transfers.
Assume an inbound transfer has a settlement date of Monday. You must submit your return request via our API by the cutoff business time on Tuesday if return code
R22 is used, so that the ODFI will receive the return request on the morning of Wednesday.
The ACH Return API accepts the following return codes only:
- The following return codes can be used before the opening of business on the
2ndbusiness day after the settlement date:
- The following return codes can be used before the opening of business on the
60thcalendar day after the settlement date:
- The following return codes can be used any number of days after the settlement date:
For certain return codes, you are responsible to collect a copy of signed Written Statement of Unauthorized Debit (WSUD) from your customers. If you'd like help drafting this or would like a template, feel free to email us. The ODFI has the right to request a copy of this WSUD. We'll email you for this document if we get a request, we then have to respond within
10 banking days. The following return codes require copies of signed WSUD:
The following table provides information for all the return codes accepted by our ACH Return API.
|Code||Description||WSUD||Days to send|
|R01||The available and/or cash reserve balance is not sufficient to cover the dollar value of the debit Entry.||No||2|
|R02||A previously active account has been closed by action of the customer or the RDFI.||No||2|
|R03||The account number structure is valid and it passes the check digit validation, but the account number does not correspond to the individual identified in the Entry, or the account number designated is not an existing account.||No||2|
|R04||The account number structure is not valid.||No||2|
|R05||CCD or CTX debit Entry was Transmitted to a Consumer Account of the Receiver and was not authorized by the Receiver.||Required||60|
|R06||The ODFI has requested that the RDFI return an Erroneous Entry, or a credit Entry originated without the authorization of the Originator. The RDFI is not obligated to return.||No||any|
|R07||The RDFI's customer (the Receiver) revoked the authorization previously provided to the Originator for this debit Entry.||Required||60|
|R08||The Receiver has placed a stop payment order on this debit Entry.||No||2|
|R09||A sufficient ledger balance exists to satisfy the dollar value of the transaction, but the available balance is below the dollar value of the debit Entry.||No||2|
|R10||The RDFI has been notified by the Receiver that the Receiver does not know the identity of the Originator; has no relationship with the Originator; or has not authorized the Originator to debit his account. For ARC and BOC entries, the RDFI has been notified by the Receiver that the signature on the source document is not authentic, valid, or authorized. For POP Entries, the RDFI has been notified by the Receiver that the signature on the written authorization is not authentic, valid, or authorized.||Required||60|
|R11||The RDFI has been notified by the Receiver that the Originator and Receiver have a relationship and an authorization to debit exists, but there is an error or defect in the payment such that the entry does not conform to the terms of the authorization (for example, the entry is for an amount different than authorized; the entry was initiated for settlement earlier than authorized; the entry is part of an Incomplete Transaction; the debit entry was improperly reinitiated; for ARC, BOC, or POP entries: ineligible source document, notice was not provided; amount of the entry was not accurately obtained from the source document; The Reversing Entry was improperly initiated by the Originator or ODFI; The Receiver did not affirmatively initiate a Subsequent Entry in accordance with the terms of the Standing Authorization.||Required||60|
|R12||A financial institution received an Entry to an account that was sold to another financial institution.||No||2|
|R14||The representative payee is either deceased or unable to continue in that capacity. The beneficiary is not deceased.||No||2|
|R15||The beneficiary is deceased, or the account holder is deceased.||No||2|
|R16||(1) Access to the account is restricted due to specific action taken by the RDFI or by legal action; or (2) OFAC has instructed the RDFI or Gateway to return the Entry.||No||2|
|R17||(1) Field(s) cannot be processed by RDFI; (2) the Entry contains an invalid DFI 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; or (3) either the RDFI or Receiver has identified a Reversing Entry as one that was improperly initiated by the Originator or ODFI.||No||2|
|R20||ACH Entry to a non-Transaction Account.||No||2|
|R21||The Identification Number used in the Company Identification Field is not valid.||No||2|
|R22||The Receiver has indicated to the RDFI that the number with which the Originator was identified is not correct.||No||2|
|R23||Any credit Entry that is refused by the Receiver may be returned by the RDFI.||No||any|
|R24||The RDFI has received what appears to be a duplicate Entry; i.e., the trace number, date, dollar amount and/or other data matches another transaction.||No||2|
|R29||The RDFI has been notified by the Receiver (Non-Consumer) that a specific Entry has not been authorized by the Receiver.||No||2|
|R31||The RDFI may return a CCD or CTX Entry that the ODFI agrees to accept.||No||any|
|R33||This Return Reason Code may only be used to return XCK Entries and is at the RDFI's sole discretion.||No||60|
|R37||The source document to which an ARC, BOC, or POP Entry relates has been presented for payment.||Required||60|
|R38||The RDFI determines a stop payment order has been placed on the source document to which the ARC or BOC Entry relates.||No||60|
|R39||The RDFI determines that: (1) the source document used for an ARC, BOC, or POP Entry to its Receiver's account is improper, or (2) an ARC, BOC, or POP Entry and the source document to which the Entry relates have both been presented for payment and posted to the Receiver's account.||No||2|
|R51||An RCK Entry is considered to be ineligible or improper.||Required||60|
|R52||A stop payment order has been placed on the item to which the RCK Entry relates.||No||60|
|R53||In addition to an RCK Entry, the item to which the RCK Entry relates has also been presented for payment.||Required||60|
The following sections are extremely rare, and in a vast majority of cases we'll automatically handle everything on the backend for you. However, for transparency and educational purposes we'll walk you through them.
When you, as the RDFI submit a return, the ODFI can reject your return by submitting a return (against your return) known as a dishonored return entry.
Dishonored return entries must be received within
5 banking days after the settlement date of return entries.
|R61||The financial institution preparing the Return Entry (the RDFI of the original Entry) has placed the incorrect Routing Number in the Receiving DFI Identification field.|
|R62||The Originator's/ODFI's use of the reversal process has resulted in, or failed to correct, an unintended credit to the Receiver.|
|R67||The ODFI has received more than one Return for the same Entry.|
|R68||The Return Entry has not been sent within the time frame established by these Rules.|
|R69||One or more of the field requirements are incorrect.|
|R70||The ODFI has received a Return Entry identified by the RDFI as being returned with the permission of, or at the request of, the ODFI, but the ODFI has not agreed to accept the Entry or has not requested the return of the Entry.|