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.

ODFI - returns when initiating ACH transfers

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 (R01)
  • The receiving account has been closed or the account number is invalid (R02, R04)
  • The owner of the receiving bank account requested a stop payment on the debit (R08)
  • The owner of the receiving bank account did not authorize the transaction (R07, R10)

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.

People in the industry refer to returns that need to be sent in under 2 days as administrative returns or t+2 returns. The returns that need to be send under 60 days are referred to as unauthorized returns or t+60 returns.

After receiving your ACH transfer requests, Column will submit them to the Federal Reserve based on the effective dates of your requests.

  • If we do not receive any returns from the RDFIs for your requests within 2 business days, we will settle your transfers and send ach.outgoing_transfer.settled events 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.returned event via the webhook endpoint. As mentioned above, RDFIs may send returns within 60 calendar days, even after we settle the transfers. In that case, we will mark the transfers as returned and send the ach.outgoing_transfer.returned event as well.

You can receive the details of the return by accessing that transaction (note: we are in the process of breaking out returns into a separate data model, with its own dedicated APIs). 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.

RDFI - returns when receiving ACH transfers

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 R01, R02, R03, R04, R20, R33, R67.

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..

ACH returns to closed accounts

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.

ACH return statuses

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.

Administrative Return example

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 2nd business day after the settlement date: R01, R02, R03, R04, R08, R09, R12, R14, R15, R16, R17, R20, R21, R22, R23, R24, R29, R39.
  • The following return codes can be used before the opening of business on the 60th calendar day after the settlement date: R05, R07, R10, R11, R33, R37, R38, R51, R52, R53.
  • The following return codes can be used any number of days after the settlement date: R06, R31.

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: R05, R07, R10, R11, R37, R51, R53.

Return Reason Codes

The following table provides information for all the return codes accepted by our ACH Return API.

CodeDescriptionWSUDDays to send
R01The available and/or cash reserve balance is not sufficient to cover the dollar value of the debit Entry.No2
R02A previously active account has been closed by action of the customer or the RDFI.No2
R03The 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.No2
R04The account number structure is not valid.No2
R05CCD or CTX debit Entry was Transmitted to a Consumer Account of the Receiver and was not authorized by the Receiver.Required60
R06The 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.Noany
R07The RDFI's customer (the Receiver) revoked the authorization previously provided to the Originator for this debit Entry.Required60
R08The Receiver has placed a stop payment order on this debit Entry.No2
R09A 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.No2
R10The 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.Required60
R11The 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.Required60
R12A financial institution received an Entry to an account that was sold to another financial institution.No2
R14The representative payee is either deceased or unable to continue in that capacity. The beneficiary is not deceased.No2
R15The beneficiary is deceased, or the account holder is deceased.No2
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.No2
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.No2
R20ACH Entry to a non-Transaction Account.No2
R21The Identification Number used in the Company Identification Field is not valid.No2
R22The Receiver has indicated to the RDFI that the number with which the Originator was identified is not correct.No2
R23Any credit Entry that is refused by the Receiver may be returned by the RDFI.No2
R24The 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.No2
R29The RDFI has been notified by the Receiver (Non-Consumer) that a specific Entry has not been authorized by the Receiver.No2
R31The RDFI may return a CCD or CTX Entry that the ODFI agrees to accept.Noany
R33This Return Reason Code may only be used to return XCK Entries and is at the RDFI's sole discretion.No60
R37The source document to which an ARC, BOC, or POP Entry relates has been presented for payment.Required60
R38The RDFI determines a stop payment order has been placed on the source document to which the ARC or BOC Entry relates.No60
R39The 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.No2
R51An RCK Entry is considered to be ineligible or improper.Required60
R52A stop payment order has been placed on the item to which the RCK Entry relates.No60
R53In addition to an RCK Entry, the item to which the RCK Entry relates has also been presented for payment.Required60

Dishonored returns and contested dishonored returns

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.

Dishonored returns

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.

R61The financial institution preparing the Return Entry (the RDFI of the original Entry) has placed the incorrect Routing Number in the Receiving DFI Identification field.
R62The Originator's/ODFI's use of the reversal process has resulted in, or failed to correct, an unintended credit to the Receiver.
R67The ODFI has received more than one Return for the same Entry.
R68The Return Entry has not been sent within the time frame established by these Rules.
R69One or more of the field requirements are incorrect.
R70The 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.