Return
A return sends an ACH entry back because it could not be accepted or completed under the applicable reason. The return code describes that exception.
ACH return guidance
What is an ACH return code?
An ACH return code is a standardized reason label attached when an ACH entry is sent back through the network instead of being completed as submitted. The code helps the financial institutions and payment service involved identify the type of exception. For a business, it is a starting point for investigation, not a complete diagnosis or permission to submit the payment again.
What the code communicates
ACH return reason codes use an R followed by two digits. Nacha's return-reason table pairs each code with a title, description, initiating party, applicable account context, and other handling information. A provider dashboard or bank report may show the code beside the returned entry, a short description, the original transaction reference, and the date the return was reported.
The reason may relate to available funds, account status, account information, authorization, entry formatting, or another network condition. Similar-looking customer situations can produce different codes, so staff should preserve the exact code and provider message. Avoid replacing it with a guess such as "bank problem" or "customer error."
A return is not the same as a reversal
Reversal
A reversal is a separate entry used by an originator to correct certain erroneous entries. It is not simply another name for a returned payment.
Notification of change
A notification of change communicates corrected payment information for future entries. It follows a different purpose and uses change codes rather than return reason codes.
How a business should read a return notice
Start with the transaction record supplied by the bank or payment provider. Match the exact return code to the provider's current explanation and connect it to the original customer, invoice, subscription, or disbursement record. Confirm the payment direction, account type, submission channel, amount, original entry reference, and any customer communication already on file.
The code should guide the next question, not automatically trigger a retry. Some exceptions may call for corrected information, some may require customer contact through an established channel, and some may need review by the financial institution or provider. The appropriate response can depend on facts that are not visible from the code alone. Follow the current provider workflow and applicable operating rules rather than copying instructions from an old code list.
Use a consistent return-triage process
- Capture the exact notice: record the return code, description, transaction reference, original submission date, and provider-reported date without changing the source wording.
- Match the business record: connect the entry to the correct customer, invoice, authorization record, subscription, payroll item, vendor payment, or other documented purpose.
- Confirm the payment rail: verify that the item was actually an ACH entry rather than a card, wire, check, or other bank-payment transaction.
- Route the exception: assign review to the employee responsible for payments, customer service, accounting, or provider support according to the nature of the notice.
- Pause automated action: do not let a generic workflow resubmit every returned entry. Obtain the service-specific direction needed for that code and situation.
- Preserve the outcome: document any correction, customer contact, provider response, accounting adjustment, or decision not to resubmit.
Keep code references current
Return-code definitions and related rules are maintained within the Nacha Operating Rules, and clarifications can take effect over time. For example, Nacha published a clarification effective January 1, 2026 concerning wording associated with Return Reason Code R17. That kind of update is why a business should use its provider's current documentation and the current Nacha rules instead of a static list saved years earlier.
This page provides an operational overview, not a code-by-code rulebook. It does not define return deadlines, decide whether an entry was authorized, or tell a business whether resubmission is permitted. Those questions require the exact code, entry type, account context, provider process, and current authoritative rules.
Protect customer and bank information
Investigating a return rarely requires sending complete bank-account details through an ordinary message. Use the bank's or provider's secure support channel and share only the information it requests. Limit employee access to the systems and records needed for their responsibilities, and use individual accounts where the service supports them.
A general Payments Max inquiry can describe the return code, payment direction, business workflow, user roles, reporting needs, and redacted references. Do not submit online-banking credentials, complete bank-account numbers, cardholder data, passwords, personal identity documents, or secret API keys through a general contact form.
Prepare a useful return summary
Before contacting a financial institution or payment provider, gather the exact return code, redacted transaction reference, payment direction, entry purpose, account context, submission channel, and internal record owner. Payments Max can help organize the operational questions to ask without deciding the code's legal effect, promising a particular resolution, or replacing provider-specific guidance.
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