ACH Return Code R23: What It Means and How to Fix It

The Automated Clearing House (ACH) network is a core component of the U.S. payment system, enabling secure, cost-effective fund transfers between banks and credit unions. It supports a wide range of transaction uses, including payroll deposits, vendor payments, tax refunds, and customer refunds. For financial institutions, ACH processing is a daily operational function, and banks handle a high volume of payments through this rail constantly. 

Despite its reliability, the ACH network is not immune to transaction reversals. ACH returns occur when a payment cannot be processed as intended, and they safeguard the sending and receiving parties. Each return is identified by a NACHA-designated return code that specifies the reason.

Among these, ACH Return Code R23: Credit Entry Refused by Receiver signals that the receiving account holder has declined the credit. While less common than debit-related returns, it requires precise handling and proper reconciliation to maintain compliance and operational integrity.

This article examines R23 in depth, covering its technical definition, operational implications, reconciliation process, and strategies for prevention in banking environments.

What this blog covers:

• What is the ACH R23 return code and when it’s triggered
• How “Credit Entry Refused by Receiver” differs from other return codes
• Common causes behind an R23 rejection
• Step-by-step guide to handling or correcting an R23 return
• Best practices to prevent future R23 returns
• How Osfin streamlines reconciliation for R23 returns
• Real-world scenarios and examples involving R23
• Frequently asked questions around R23 and ACH credit refusals

What Is an ACH Return Code?

An ACH return code is a standardized three-character code defined under NACHA rules that explains why an ACH transaction could not be completed. These codes provide both operational and compliance clarity, allowing financial institutions to quickly identify the reason for failure and take corrective steps.

ACH return codes serve as a communication link between the Receiving Depository Financial Institution (RDFI) and the Originating Depository Financial Institution (ODFI). They ensure that all parties in the transaction, banks, businesses, and customers, understand why a return was made. 

There are two broad categories:

• Debit return codes for rejected withdrawals from an account.
• Credit return codes for refused deposits into an account.

What Is ACH Return Code R23?

Under NACHA rules, ACH Return Code R23 is defined as Credit Entry Refused by Receiver. It is used when the account holder at the Receiving Depository Financial Institution (RDFI) declines to accept an incoming ACH credit. This refusal is intentional, initiated by the receiver, and must be communicated within the allowable two-banking-day return window.

R23 applies only to credit entries, transactions where funds are being deposited into the receiver’s account. It does not apply to debits, which have separate return codes. This code typically appears in specific, customer-driven situations, such as:

• Disputed payments or billing errors.
• Duplicate credits.
• Payments were sent to the wrong beneficiary.
• Unsolicited credits that raise fraud or compliance concerns.

When a receiver instructs their bank to reject a credit, the RDFI processes the return and transmits it, along with the R23 code, back to the Originating Depository Financial Institution (ODFI) through the ACH Operator. The ODFI then updates its records, informs the originator, and manages the reversal of funds.

Common Reasons for ACH Return Code R23

While R23 (Credit Entry Refused by Receiver) can arise in multiple contexts, it is almost always tied to a specific, customer-initiated rejection. Here are the most frequent scenarios where R23 is used: 

1. Customer Refusal of Payment

The most common reason for R23 is when the receiver explicitly instructs their RDFI not to accept a credit. This can occur if the payment was unexpected, the customer does not recognize the sender, or they simply prefer not to receive funds from a specific party.

2. Account Closed Before Credit Posted

In some cases, the receiver’s account may have been closed prior to the credit posting. If the RDFI still receives the entry and the customer refuses it rather than processing it under R02 (Account Closed), the transaction is returned with R23. This often depends on internal posting and exception-handling workflows.

3. Payment Dispute

R23 may be used when the receiver believes the funds were not owed or the amount sent was incorrect. This can happen in business-to-business settlements, refunds, or incentive payouts where payment terms are contested.

4. Duplicate Payment

Suppose a payment is sent more than once, whether due to originator error or system malfunction, the receiver may refuse the duplicate credit. The RDFI will then return it as R23 to prevent over-crediting the account.

5. Unwanted Credits (Fraud Concerns)

Some receivers refuse credits if they suspect the origin of funds is fraudulent or tied to suspicious activity. In such cases, R23 allows for immediate rejection, and the RDFI may also initiate further fraud review processes in line with compliance policies.

What Does ACH Return Code R23 Mean for My Payment?

For customers, ACH Return Code R23 means the credit sent to their account was refused and never posted. The funds are returned to the sender, and no changes occur to the receiver’s account balance.

For financial institutions, R23 indicates that the RDFI has processed a customer’s refusal of a credit entry within the NACHA-defined time frame. The ODFI must reverse the original settlement, notify the originator, and update internal records. It also requires accurate reconciliation to match the returned credit with the initial transaction.

How to Fix ACH Return Code R23

When a credit entry is returned with R23: Credit Entry Refused by Receiver, banks must act quickly to address the failed settlement, protect client relationships, and maintain operational accuracy. Here’s how the R23 code can be fixed: 

1. Review NACHA Return Details

Start by analyzing the NACHA-formatted return file received from the ACH Operator. Confirm the R23 code, transaction amount, trace number, SEC code, and any addenda records. 

2. Identify the Originator

Pinpoint the corporate or retail originator associated with the returned entry. This often involves cross-referencing the trace number with core banking or payment gateway records.

3. Contact the Originator

Notify the originator promptly, explaining that the credit was refused by the receiver. Gather details about the payment’s intent and verify whether the receiver was expecting the funds.

4. Initiate Corrected Payment

If the payment remains valid, reissue it after confirming updated receiver details or use an alternate settlement method, such as a wire transfer or physical check, to ensure timely completion.

5. Maintain an Audit Trail

Document all communications, system actions, and resolution steps. This supports audit readiness and ensures compliance with NACHA and internal governance requirements.

6. Manage Corporate Expectations

Provide the corporate originator with actionable guidance, including the precise return reason and preventive measures, to avoid repeated R23 instances.

How to Prevent Future R23 Returns

Reducing R23 occurrences requires both proactive validation and collaboration with originators to improve payment accuracy. Banks can integrate operational safeguards at multiple points in the payment process.

1. Validate account and routing details at payment initiation, and recommend pre-note transactions for corporate clients.
2. Confirm the receiver’s consent before sending first-time or high-value credits.
3. Train corporate originators on NACHA return codes and the risks of unsolicited credits.
4. Use real-time risk filters to detect unusual, duplicate, or erroneous credits.
5. Track R23 return patterns and address recurring issues with targeted client outreach.

How to Reconcile R23 ACH Return Code 

‍

Reconciling an R23-Credit Entry Refused by Receiver return involves accurately identifying the transaction, validating settlement records, updating internal and customer data, and managing exceptions in line with operational and compliance requirements.

1. Ingest Data Across Various File Formats

Banks receive R23 return information primarily through NACHA-formatted return files from the ACH Operator, but reconciliation requires bringing together multiple data sources. These can include core banking system exports, payment gateway reports, treasury/Nostro account statements, and ACH settlement statements. 

The challenge is that these can arrive in varied file formats such as Excel, CSV, XML, or MT940 and must be normalized and parsed before being processed. If you use a file-format agnostic solution that can handle multiple formats, like Osfin.ai, it not only ingests data using 170+ integrations but also automatically parses various file formats and cleans the data set to ensure accurate reconciliation.  

{{banner1}}

2. Match Transactions and Cross-Reference

Once data is ingested, operations teams must match the returned credit to the original transaction using identifiers like the trace number, batch number, SEC code, and transaction date. This is followed by cross-referencing against settlement data from the Federal Reserve or The Clearing House to confirm the reversal has been accurately reflected in the bank’s accounts.

3. Update Internal and Customer Records

After confirmation, internal ledgers must be updated to reflect the reversal. Customer-facing systems, including corporate treasury portals, should display the return status, reason code, and any relevant instructions from the bank to the originator. This transparency helps corporate clients quickly decide whether to resend the payment or take alternative settlement actions.

4. Flag and Escalate Exceptions

Some R23 returns may lack complete transaction identifiers, appear in aggregated return batches, or have mismatched details between the return file and internal records. These exceptions must be automatically flagged with accurate reasons for manual review, investigated promptly, and escalated to relevant teams, such as compliance, fraud prevention, or corporate relationship management, before the return process is closed.

Automating ACH Payments Reconciliation with Osfin.ai 

Reconciling ACH returns such as R23 – Credit Entry Refused by Receiver becomes increasingly complex when banks manage high transaction volumes, multiple file formats, and tight settlement timelines. Manual processes often struggle to keep pace, leading to delays, mismatches, and compliance risks. Osfin.ai streamlines this process end-to-end with automation built specifically for high-volume, multi-source reconciliation.

Osfin.ai is file-format agnostic and integrates with 170+ systems, enabling direct import of ACH return files, settlement statements, and core banking exports regardless of format (CSV, Excel, XML, MT940, etc.). During ingestion, it applies custom deviation tolerances to filter out poor-quality data while detecting duplicates and outliers early to prevent reconciliation delays.

Osfin’s logic-based transaction matching engine can handle up to 30 million records in just 15 minutes. It also auto-reconciles payment gateway reports, factoring in commissions, taxes, and fees for precise ACH-related settlements. Osfin.ai automatically flags unmatched transactions, assigns an accurate reason, and routes them to the right team with its ticketing and exception handling engine.

The platform delivers audit-ready compliance reports, maintains full transaction traceability, and secures data with 256-bit encryption, role-based access, and two-factor authentication. It’s fully compliant with SOC 2, PCI DSS, ISO 27001, and GDPR.

For banks looking to reduce operational overhead, improve accuracy, and speed up ACH reconciliation, Osfin.ai offers a faster, safer, and more scalable way forward. Book a demo with Osfin.ai today to see it in action.

FAQs on R23 Return Code

1. What is the time frame for returning an ACH credit under R23?

R23 returns must be initiated by the RDFI within two banking days of the settlement date. This short window allows prompt reversal of funds and ensures the ODFI can quickly notify the originator and take corrective action.

2. Does R23 apply to both consumer and corporate accounts?

Yes, R23 can apply to both consumer and corporate accounts. Any account holder may refuse an ACH credit if they believe it was sent in error, is unsolicited, or is otherwise unwanted, provided the refusal is made within the allowable return period.

3. How is R23 different from R02 (Account Closed)?

R23 is used when the receiver refuses a credit to an open account, while R02 applies when the credit is sent to a closed account. R23 typically reflects customer choice or dispute, whereas R02 results from account status.

4. Can a bank override a customer’s refusal of a credit?

No, a bank cannot override a customer’s explicit refusal of credit. NACHA rules require RDFIs to honor valid refusal requests within the return time frame, regardless of the bank’s assessment of the payment’s origin or purpose.

5. Are there NACHA penalties for frequent R23 returns?

While NACHA does not levy direct penalties for high R23 volumes, frequent returns can trigger reviews of the ODFI’s origination practices. Persistent issues may lead to corrective action requirements under NACHA’s rules and increased monitoring by the ACH Operator.