ACH payments FAQ
An ACH payment is returned when the receiving financial institution sends the entry back through the ACH Network instead of allowing it to remain completed. The return includes a standardized reason code that identifies the category of the problem.
Common causes include insufficient funds, a closed or unlocatable account, invalid account data, a stop-payment instruction, a duplicate entry, or an authorization-related concern. The code shown by the bank or payment provider is the best starting point because the next step depends on that specific code, the entry type, and the provider's current process.
A return notice should include an R-code and a description. Nacha's published return-code materials identify R01 with insufficient funds, R02 with a closed account, R03 with an account that cannot be located, and R04 with an invalid account-number structure. Federal Reserve reporting examples also show the return code and description as part of an ACH return-item report.
Do not diagnose the result from a generic dashboard label alone. Open the transaction details, export, or bank report and record the exact code, the original transaction reference, whether the entry was a debit or credit, and the return date. Then compare the code with current documentation from the merchant's bank or ACH provider. Learn more about what an ACH return code means.
The receiving account may lack available funds, be closed, be frozen, or be an account type that does not accept the entry. The return code distinguishes these situations, so staff should not describe every failed debit as insufficient funds.
The routing or account information may not identify an open account, or the account-number structure may be invalid. Compare the returned details with the information the customer supplied without copying full bank details into email, chat, or general notes.
A bank may return an entry because of a stop-payment instruction, revoked authorization, an unrecognized originator, or a payment that does not match the terms the customer authorized. These categories are not interchangeable, and the provider's exact code should guide escalation.
Some returns identify a duplicate entry, incorrect transaction information, formatting trouble, or another operational exception. Review the original record before anyone creates a replacement payment.
Do not automatically resubmit every returned entry. A corrected account-data issue, a funding issue, and an authorization-related return can require different handling. Review the information used for an ACH payment before requesting any corrected details.
Use neutral language and share only what the return record supports. Tell the customer that the ACH payment was returned, identify the business transaction involved, and provide the provider's plain-language reason when appropriate. Avoid accusing the customer of wrongdoing or claiming that a bank made an error without evidence.
If corrected information is needed, direct the customer to an approved, secure collection method. Do not request complete bank account numbers, passwords, cardholder data, security codes, or online-banking credentials through a general contact form, ordinary email, text message, or support note. Staff should not paste sensitive data from a return report into a broadly accessible customer record.
For recurring arrangements, review how recurring ACH payments may work. A returned payment should be reviewed separately from any future scheduled entry, using the provider's instructions for the exact return reason.
A consistent intake and review process can catch some preventable mistakes before submission. Use the payment provider's supported bank-information collection flow, confirm that required fields are present, show customers a clear description of the payment, and limit staff access to sensitive records. When a provider offers account-validation tools, evaluate the documented scope instead of assuming they eliminate every possible return.
Track return codes by category and look for repeated operational patterns, such as transposed account digits, outdated stored instructions, duplicate submissions, or unclear customer-facing descriptions. The pattern can help a business improve training and checkout instructions, but it does not replace review of each individual return. For broader context, see what ACH payment processing is and the ACH, eCheck & Bank Payments FAQ hub.
Document where staff find the return code, who reviews each category, how customers receive a neutral notice, and which secure channel collects corrected information. Then verify that process against the current instructions from the business's bank and ACH provider.
Discuss ACH payment requirements
Share only business contact details and a high-level workflow description through a general form. Do not submit cardholder data, passwords, bank credentials, complete account numbers, security codes, or secret API keys.
To learn more about how TSYS can help improve the way your organization accepts payments, markets to new customers, or manages its HR responsibilities, get in touch by calling 585-981-8463 to get started.
CONTACT US
