R06 ACH Return Code: What "Returned per ODFI's Request" Means for Merchants

R06 is the ACH return code for "Returned per ODFI's Request." It means the bank that originated the entry — the ODFI — asked the receiving bank to send the transaction back. That makes it an unusual code. Most returns describe a problem on the receiving end; R06 starts on your side of the network.

Here is what the code means, why it happens, and what to do when one posts to your account.

What the R06 ACH Return Code Means

Every ACH return carries a reason code, and R06 tells you the return was not the receiving bank's idea. The originating depository financial institution requested it, and the receiving depository financial institution sent the entry back in response. If an R06 posts to your account, the request came from the bank your processor used to originate the payment — not from your customer's bank acting alone.

That changes where you look for answers. Most return codes point you toward something on the receiver's end. R06 points you back toward your own processor and its originating bank.

ODFI and RDFI: Who Requests the Return, and Who Sends It

Two banks touch every ACH entry, and R06 only makes sense once you know which is which. The ODFI, the originating depository financial institution, puts the entry into the ACH network on behalf of the originator — your business. When you debit a customer's account, the bank your processor originates through is the ODFI.

What Does RDFI Mean in Banking?

RDFI stands for receiving depository financial institution: the bank that holds the account an ACH entry debits or credits. In a typical merchant debit, the RDFI is your customer's bank. When an entry has to go back through the network, the RDFI is the bank that sends the return.

With R06, the roles are fixed. The ODFI makes the request, and the RDFI executes the return. Knowing which bank sits where tells you where to direct your questions — and with R06, that is your own processor and its originating bank.

Why an ODFI Requests a Return

An ODFI typically requests a return for one of a few reasons:

• The entry was erroneous — a wrong amount or a wrong account, caught after the entry went out.
• A credit entry was originated without the originator's authorization — money moved that the business never approved.
• The transaction is believed to be fraudulent — and the originating side wants it unwound before it causes a larger problem.

In each case, the originating side has identified a problem with the entry after it was sent. Notice what the three reasons share: none of them starts with your customer. An R06 usually begins on your own processor's side of the network, which is why your first call should go there.

The Nacha Rule Change That Expanded R06

For years, R06 was reserved for a limited set of specific cases. Nacha has since expanded the permissible uses of the Request for Return, allowing an ODFI to ask the RDFI to send an entry back for a broader range of reasons.

The practical effect for merchants is straightforward. Expect to see R06 more often than you once did, and treat each one as a prompt to find out exactly why your originating bank made the request. The code tells you who asked. It does not tell you why.

R06 vs. Customer-Initiated Returns

An R06 is a bank-to-bank event. Your customer did not dispute the debit, and their bank did not act on a claim from the account holder — the request originated with the ODFI.

That distinction decides how you respond. A customer dispute is a separate process with its own rules and deadlines, and treating an R06 like one sends you down the wrong path: you end up reviewing the customer relationship when the question sits with your processor. If a customer does dispute an ACH debit, we cover how ACH chargebacks and disputes work in a dedicated guide.

What to Do When You Receive an R06 Return

Four steps, starting the day the return posts:

• Contact your processor or ODFI the same business day. Ask why the return was requested. R06 does not carry the underlying reason on its own, and you need that reason before you act.
• Pause re-origination of the affected entry. Do not resubmit until you know whether the problem was the entry data, the authorization, or something larger.
• Correct the entry before resubmitting. If the return traces to an error — a wrong amount, a wrong account — fix the record first.
• Keep your authorization on file. If the question is whether the entry was authorized, that document answers it faster than anything else.

ACH Processing Built for High-Risk Merchants

When a return posts to your account, you should be able to find out why. Apply today and we will tell you where you stand. We work only with high-risk businesses, and ACH payment processing is part of what we place every day.