Check Truncation Return: What R11 and R30 Mean for Your Business

If an ACH return has come back labeled a check truncation return, you are looking at one of two codes: R11 or R30. They point to different problems, and R11 no longer means what it meant a few years ago. Here is what each code tells you, and what to do once you know which one you have.

What a check truncation return is

Check truncation is the conversion of a paper check into an electronic entry so it can be processed through the ACH network instead of moving as paper. A check truncation return is the receiving bank sending one of those entries back. The return code that accompanies it tells you why, and the two codes call for different responses.

R11: the legacy check truncation entry return

Under the original Nacha definition, R11 was the code for returning a check truncation entry, and it was to be used only when no other return reason code applied. It was a catch-all for converted checks, which is why older documentation and plenty of glossary pages still describe it that way.

If the guidance you are reading stops at that definition, it is out of date. The code was reassigned in 2020, and the reassignment changes what an R11 asks of you.

How Nacha changed R11 on April 1, 2020

Effective April 1, 2020, Nacha repurposed R11. The code now means the customer advises that the entry is not in accordance with the terms of the authorization. Nacha noted there had been no forward transactions under the old check truncation definition, so the code was reassigned to a dispute that actually occurs.

This matters in practice. An R11 you receive today is not a note about check conversion. It is your customer's bank telling you the debit did not match what the customer authorized — a different amount, a different date, or terms the customer never agreed to. Treat it as an authorization problem, because that is what it is.

R30: the other check truncation return code

R30 is the code tied to check truncation participation: the receiving bank is not part of a check truncation program, so it cannot accept the entry in that form. It is generally a rare code to encounter. If you see it, the issue is with how the payment was routed, not with your customer's authorization.

What to do when you receive a check truncation return

Start with the code, because the response differs.

For R11: pull the original authorization and compare it line by line with the entry that was returned. Look for the mismatch between what the customer agreed to and what was debited. Correct the discrepancy before you present the debit again, and keep the authorization on file so you can answer the next question without a search.

For R30: the receiving bank will not process the entry as a truncated check. Route that payment through a channel the bank will accept, and flag the account so future payments from that customer do not take the same path.

In both cases, document what happened. A pattern of authorization-related returns is something your processor's risk team will notice before you do, and you want your records ready when they ask.

ACH returns and your processing account

Returns are part of running ACH payments, but repeated R11s point to a gap between your authorizations and your debits, and that gap puts your account at risk. Fixing the authorization process is the durable answer. So is working with a processor that underwrites your industry knowingly rather than discovering it later.

We specialize in high-risk processing. Our ACH payment processing is built for businesses that mainstream processors turn away, our chargeback management tools help you get ahead of disputes before they become a threshold problem, and we approve 86% of the merchants who apply for a high-risk merchant account. If ACH returns are putting your processing at risk, contact us and we will review your file.