R01 is the ACH return code for insufficient funds. Nacha defines it as an available or cash reserve balance that isn't enough to cover the debit. The customer's bank (the RDFI) sends it, and it has two banking days after settlement to do so. R01 is not an unauthorized or administrative return, but it counts toward Nacha's 15.0% level for all debit returns. The customer's authorization still stands. On a payment plan, contact the customer, agree when the money will be there, and keep the next scheduled payment separate from the missed one.
What does R01 mean?
R01 is "Insufficient Funds." In Nacha's words, the available and/or cash reserve balance is not sufficient to cover the dollar value of the debit entry. It applies to every kind of ACH debit and to personal and business accounts alike.
A close relative is R09, "Uncollected Funds." That code means the ledger balance is big enough, but the money isn't available yet, for example because a deposited check hasn't cleared. Stripe treats R01 and R09 the same way and reports both as insufficient_funds.
Who sends an R01, and how fast?
The customer's bank, called the RDFI in Nacha's rules. It has two banking days. The return must reach the business's bank no later than the opening of business on the second banking day after the debit's settlement date.
That means an R01 usually arrives within a few days of the payment date. It doesn't come weeks later the way an unauthorized return can.
Does R01 count against my return rates?
Only in the overall rate. Nacha watches three rates over the preceding 60 days or two calendar months:
| Rate | Codes | Level |
|---|---|---|
| Unauthorized | R05, R07, R10, R11, R29, R51 | 0.5% |
| Administrative | R02, R03, R04 | 3.0% |
| Overall | Every debit return, any reason | 15.0% |
R01 isn't in the first two groups. It does count toward the 15.0% overall level. Nacha calls that level a point where it may look more closely at how a business originates debits.
Can I send the debit again?
The authorization is still valid, because nobody disputed it. Nacha calls a second attempt at a returned debit a "reinitiation" and sets rules for it:
- The new debit must carry "RETRY PYMT" in the company entry description.
- The company name, company ID and amount must match the original.
- Changing the amount, up or down, is an improper reinitiation.
Nacha's rules also limit how many times and for how long a returned debit can be reinitiated. Ask your bank or processor for the limit that applies to you before you try again.
Stripe doesn't block a bank account for past insufficient-funds returns. Its guidance is to confirm with the customer that the money is there before you try again.
What should I do when a plan payment comes back R01?
- Contact the customer the day it arrives. Ask when the money will be in the account.
- Agree on the date for the missed payment. Send it again only once they confirm.
- Leave the next installment alone. Nacha says a debit in a recurring series is not a reinitiation as long as it doesn't depend on whether an earlier one was returned. So the next scheduled payment can run as planned.
- Don't fold the missed amount into a larger debit without checking with your bank. A reinitiated debit has to match the original amount.
Example: the $1,108.33 installment due on the 1st returns R01. The customer says their pay lands on the 5th. You send the same $1,108.33 again after that date, marked "RETRY PYMT," and the installment due on the 1st of next month runs as scheduled.
For other codes, see ACH return codes.
- Nacha: ISO 20022 guide to mapping U.S. ACH return codes (return code names and descriptions)
- Nacha: ACH Risk Management 2023 rule text, Appendix Four table of return reason codes
- Nacha: ACH network risk and enforcement topics
- Nacha: how to calculate unauthorized return rate
- Stripe: network decline codes
- Stripe: blocked bank accounts
Every figure on this page was checked against these sources on Oct 6, 2026. General information, not legal or tax advice.