A PAYMENTS OPERATOR NOTE · 2026-05-15 · LAST REVIEWED 2026-05-15

Rejected ACH Transaction · 2026 Diagnostic Guide

For small and mid business owners who just got a rejected-ACH notification in their inbox and need to know what to do today. Operator-honest diagnostic — decode the Nacha return code, decide whether to retry, decide when it's a one-off vs a systemic problem. No vendor pitch.

PJ Zonis Single operator · SideGuy Solutions · honest 2026 payments references for SMB owners · text 858-461-8054 — about →

LAST REVIEWED 2026-05-15 · operator-current

Quick Answer — Rejected ACH Transaction

Find the Nacha return code (R01-R85) in your processor dashboard. R01 (insufficient funds) — retry in 3-5 business days, target Tuesday or Wednesday. R02 (account closed), R03 (no account), R04 (invalid account) — STOP, do not retry, contact the customer to fix the info. R29 (corporate not authorized) — STOP, investigate authorization hygiene. R10 (consumer not authorized) — STOP, same investigation. If you see the same code repeatedly across multiple customers, it's systemic — not isolated.

Why this page exists

Three days in a row, someone typed "rejected ach transaction" into Google and SideGuy appeared near the answer. The query is consistent enough to deserve a real page — and not a vendor pitch. The audience for this page is a small or mid business owner who just got a rejected-ACH notification, doesn't know what the return code means, and needs to decide today: retry, contact the customer, or pause. Not a payments engineer. An operator with a single rejected transaction in front of them who needs the honest answer in 5 minutes.

What "rejected ACH transaction" actually means (one paragraph)

ACH transactions aren't rejected in real time. They're submitted to the ACH network, processed, and then 1-3 business days later one of two things happens: the money settles (success) or the transaction comes back with a Nacha return code (rejection). "Rejected" is operator language; "returned" is the technical term. Either way the result is the same — the money didn't move, and you have a return code that tells you exactly why. There are 80+ Nacha return codes (R01-R85), but for SMB scenarios you really only need to know 8-10 of them.

Step 1 — Find the Nacha return code

Log into your payment processor dashboard (Stripe, Modern Treasury, Dwolla, Plaid, GoCardless, etc.). Find the rejected transaction. Look for the return code in the transaction metadata or notification email. It will look like "R01" or "R02" — a single letter followed by 2 digits. That code is the entire diagnosis. Everything else flows from it.

Step 2 — Decode the return code

Retryable · most common

R01 — Insufficient Funds

What happened: The customer's bank account is open and valid but doesn't have enough money to cover the debit.

What to do today: Wait 3-5 business days. Schedule a retry for a Tuesday or Wednesday after a typical payday cycle (mid-month for B2B, end-of-week for B2C). Nacha allows up to 2 retries within 180 days. If both retries fail, you need a new authorization.
Pattern signal: Single customer — probably one-off, the customer is having a thin month. Multiple customers — you have a timing or billing-day problem.

Stop · contact customer

R02 — Account Closed

What happened: The customer closed the bank account. It no longer exists.

What to do today: Do NOT retry. Contact the customer, ask for new bank info, capture fresh authorization, then re-initiate with the new account. Treat it as a new authorization, not a continuation.
Pattern signal: Most R02s are isolated — customers change banks. If you see R02 spiking across many customers, you have a customer-communication problem (people are leaving and not telling you).

Stop · data quality issue

R03 — No Account / Unable to Locate Account

What happened: The routing number is valid but no account with that number exists at that bank. Almost always a typo or a bad copy/paste at signup.

What to do today: Do NOT retry. Contact the customer. Verify the account info. Re-enter and re-attempt only after you've confirmed the numbers.
Pattern signal: If you see R03 more than rarely, you have a signup-flow data-quality problem. Add Plaid, Finicity, or your processor's account verification at signup. This fixes most R03 entirely.

Stop · data quality issue

R04 — Invalid Account Number

What happened: The account number structure is wrong — wrong length, fails check digit validation, malformed.

What to do today: Do NOT retry. Same fix as R03 — verify the info with the customer. Add automated account verification at signup to catch these before they ever debit.
Pattern signal: Recurring R04 is a signup-flow problem, not a customer problem.

Stop · authorization problem · HIGH RISK

R29 — Corporate Customer Advises Not Authorized

What happened: The corporate customer (B2B) claims they never authorized this debit. The AP person at their company doesn't recognize the vendor or doesn't have an authorization on file.

What to do today: Do NOT retry. R29 counts toward your Nacha 0.5% unauthorized return rate cap. Audit your authorization capture for this customer — do you have a signed form, a recorded call, a ToS-click event with timestamp and IP? If yes, dispute the return with documentation. If no, you have an authorization-hygiene problem.
Pattern signal: Recurring R29 is a serious problem. Exceeding 0.5% unauthorized return rate can mean termination by your processor.

Stop · authorization problem · HIGH RISK

R10 — Customer Advises Not Authorized

What happened: A consumer (B2C) disputes the debit, claiming they didn't authorize it. Common with unclear recurring billing terms.

What to do today: Do NOT retry. Same hygiene investigation as R29. If recurring, your signup flow is not clearly disclosing the recurring debit terms.
Pattern signal: R10 and R29 together cap at 0.5%. Both are tracked closely by your processor. Trending up = imminent processor call.

Step 3 — Decide retry vs stop

The decision is binary based on the return code:

Retry (only): R01 (insufficient funds), R09 (uncollected funds), R20 (non-transaction account) — wait 3-5 business days, time it to Tuesday/Wednesday
Do not retry: R02 (account closed), R03 (no account), R04 (invalid account), R10 (consumer not authorized), R29 (corp not authorized), R07 (authorization revoked), R08 (payment stopped) — fix the underlying problem first

Step 4 — Pattern-spot to catch systemic issues

Operator-honest disclosure A single rejected ACH is usually a one-off. A pattern of rejections is a system. If you see the same return code across multiple customers in a week, you have a systemic problem to fix — not isolated bad luck.

Open your processor dashboard, filter the last 60 days by return code:

R01 dominating: Timing or retry-logic problem. You're debiting on bad days or retrying too aggressively.
R03/R04 dominating: Signup-flow data-quality problem. Add Plaid or Finicity verification at account creation.
R10/R29 trending up: Authorization-hygiene problem. Audit your consent capture and signup disclosure language.
R02 surge: Customer-communication problem. Your customers are switching banks and not telling you. Send a 30-day-pre-debit confirmation email.
Multiple codes spiking together: Probably a processor or integration issue — escalate to your account manager.

Honest risks of mismanaging a rejected ACH

Aggressive retry on non-retryable codes Retrying R02, R03, R04, or R29 is pointless — and worse, each pointless retry adds to your administrative or unauthorized return rate. Cross the Nacha caps (15% overall, 0.5% unauthorized, 3% administrative) and you can be fined or terminated by your processor.

Ignoring R10/R29 trend Unauthorized returns (R10 and R29) are the most serious. Exceeding 0.5% means processors will often terminate immediately rather than work with you. If you see either trending up, fix the root cause within the same week.

Damaging the customer relationship An aggressive retry on a closed account or a disputed debit can prompt the customer to dispute even harder — turning a single R02 into multiple R29 events. Each customer deserves a human reach-out before any retry of a non-R01 return.

Treating systemic problems as isolated The biggest operator mistake is treating each rejected ACH as a one-off when the data shows a clear pattern. Pull your 60-day return report monthly. Spot the dominant code. Fix the system, not the symptom.

If you have a rejected ACH in front of you right now — the 4-step diagnostic

Find the Nacha return code in your processor dashboard. R01-R85. That code is the entire diagnosis.
Classify it. R01 (and R09, R20) = retryable. Everything else = STOP and fix the underlying problem first.
Act. If retryable, schedule a smart retry 3-5 business days out, target Tuesday or Wednesday. If not retryable, contact the customer and fix the underlying issue (new account info, fresh authorization, dispute resolution).
Log the event and pattern-spot. If you're seeing one return code repeatedly across multiple customers, it's systemic. Pull the 60-day return report, apply the matching fix from the Reduce ACH Declines guide.

What to NOT do Do not retry R02, R03, R04, R10, or R29 without fixing the underlying problem. Do not panic over a single isolated rejection — most are one-offs. Do not switch processors because of one rejected ACH — the new processor will inherit your data quality and authorization-hygiene problems. Do not let a vendor sell you a $15K "ACH optimization" service to do what return-code triage and Plaid verification can do.

Common questions (operators ask)

What does it mean when an ACH transaction is rejected?

An ACH transaction isn't rejected in real time the way a credit card is — it's submitted, processed, then RETURNED 1-3 business days later if something is wrong. 'Rejected ACH transaction' is the common-language operator term; the technical term is an ACH return. The Nacha return code (R01-R85) tells you exactly why. Most common: insufficient funds (R01), closed account (R02), wrong account info (R03/R04), customer disputing (R29).

How do I find out why a specific ACH transaction was rejected?

Your payment processor will give you a Nacha return code in the rejection notification. Log into your dashboard (Stripe, Modern Treasury, Dwolla, etc.), find the transaction, and look for the return code in the metadata. It will look like 'R01' or 'R02'. That code maps to a specific reason from Nacha's official return code list. For SMB scenarios you really only need to know the top 8-10.

Should I retry a rejected ACH transaction?

It depends entirely on the return code. R01 (insufficient funds) — YES, retry in 3-5 business days, time it to Tuesday or Wednesday. R02, R03, R04 — NO, the account info is wrong. R10, R29 — NO, this is an authorization problem you need to investigate before doing anything else. Retrying non-retryable codes will just generate another return and damage your rolling rate.

How long do I have to wait before retrying a rejected ACH?

For R01, wait 3-5 business days. Retrying the next morning almost always fails. Time the retry to a Tuesday or Wednesday after a typical payday cycle (mid-month B2B, end-of-week B2C). Modern processors (Stripe, Modern Treasury, Dwolla) have built-in smart retry logic that handles this automatically. For other return codes, do not retry — pause and resolve the underlying issue first.

What's the difference between R10 and R29 returns?

Both are unauthorized return codes and both count against the 0.5% Nacha unauthorized return rate cap. R10 (Customer Advises Not Authorized) is filed by a consumer (B2C). R29 (Corporate Customer Advises Not Authorized) is filed by a business (B2B). Both are serious — exceeding 0.5% can mean termination by your processor. If either trends up, audit your authorization capture and signup disclosure immediately.

Can a rejected ACH transaction hurt my business beyond the lost payment?

Yes, in three ways. (1) Return rate cap risk — every rejection adds to your rolling return rate; Nacha caps are 15% overall, 0.5% unauthorized, 3% administrative. (2) Processor risk reviews — most processors will pull you into a review or impose a reserve hold before the Nacha cap. (3) Customer relationship — aggressive retries can damage the relationship and trigger more disputes. Manage each rejection deliberately.

What if my processor is showing a return code I don't recognize?

Nacha maintains the full list (R01-R85). The common SMB codes are R01, R02, R03, R04, R05, R07, R08, R09, R10, R16, R20, R29, R31. Less common codes often relate to specific transaction types — international (IAT), tax payments (CCD+), or corporate edge cases. Search 'Nacha return code R##' for the official definition, then escalate to your processor's support if unclear. Don't retry until you understand what happened.

What's the 4-step diagnostic for a single rejected ACH transaction?

Step 1: Find the Nacha return code in your processor dashboard. Step 2: Classify it — retryable (R01 only) vs not-retryable. Step 3: If retryable, schedule a smart retry 3-5 business days out. If not retryable, contact the customer and fix the underlying problem. Step 4: Log the event so you can spot patterns. Repeated same-code rejections = systemic problem.

Where SideGuy fits

SideGuy is a software and AI operator, not a payment processor. This page exists because real small business operators are typing this query into Google and AI agents at the moment they have a rejected ACH in front of them — and they deserve a fast, honest answer instead of a vendor pitch. If you want help reading a specific return code in your dashboard, deciding whether to retry, or pattern-spotting whether your rejections are systemic, text PJ at 858-461-8054. Operator help, not vendor help. If SideGuy can't help with what you described, you'll hear "no" in the same text thread.

PJ Zonis · SideGuy Solutions · NCSD coastal
Single operator. Honest 2026 references for SMB owners. Same-day reply. No retainer.
Text 858-461-8054 with the return code — yes/no diagnostic in seconds.