ACH returns reconciliation. Every return tied to the payment it undoes.

ACH returns reconciliation, in short

ACH returns reconciliation links every returned entry to the original payment it undoes, records why it came back, and reverses its effect in your ledger, so the payment, the return and the bank movement all agree. A return is not a new payment. It is late evidence about an old one, and it can arrive after the day, or even the month, was closed.

Handled well, a return reopens exactly one payment with its reason code attached. Handled badly, it becomes an unexplained credit or debit on the bank statement, and the recipient or customer is left in the wrong state until someone notices.

Returns, reversals and notifications of change

Three different things come back through the ACH Network, and each needs different treatment.

• A return is an entry sent back because it could not be accepted by the receiving financial institution: the account is closed, has no funds, or the payment was not authorised. It carries a return reason code.
• A reversal is the originator correcting its own error, such as a duplicate payment, a wrong amount or the wrong account. Under the Nacha Rules, reversals must be transmitted within five banking days of the original settlement date.
• A notification of change is not a return at all. The payment went through, and the receiving bank is telling you to correct the account details for next time.

Common return codes and what they mean for reconciliation

The codes and return windows are set by the Nacha Operating Rules; check the current Rules and your bank’s agreement for the full list. The point for reconciliation is the timing: most returns arrive within days, but unauthorised consumer returns can arrive two months later.

How to match a return to its original entry

A return entry carries the trace number of the original entry and a return reason code. That trace number is the strongest key you have, so store it for every entry you originate. Then match on, in order:

1. The original entry trace number carried in the return.
2. Your own reference, if you put one in the individual identification number or addenda of the original.
3. Amount, receiving account, effective date and company entry description, as a fallback within a narrow window.

Never net a return against unrelated activity to make a day balance. A return that cannot be linked to an original entry is an orphan, and should be investigated as one.

What a return does to your ledger and bank

For a payout, a return means the recipient was not paid and the money came back. The payout should reopen, the recipient’s balance should be restored with the reason, and support should be able to tell them why. For a collection, a return means money you thought you had is gone. The customer’s balance should reverse, and any service you delivered against it needs a decision.

On the bank side, returns can appear as separate lines, as part of a batch, or netted against the next settlement, depending on your bank and provider. Match the return file to the bank movement as well as to the original entry, so the cash and the reason agree.

Returns when you originate through a provider

If you send ACH payments through a payment provider rather than directly through your bank, returns reach you differently. The provider usually reports the return through its API, webhooks and daily reports, often with its own status names alongside the return reason code, and the money moves back as part of a later settlement rather than as a separate bank line.

That adds a step. Link the provider’s return event to your original payment, then find the return inside the provider’s settlement, then match that settlement to the bank. If the provider nets returns against new payments, the settlement arithmetic has to account for them explicitly, or the net will be short with no visible reason. Ask each provider how it reports returns, which identifiers it carries through from the original payment, and how long after the return the money moves.

Designing for late returns

Because unauthorised consumer returns can arrive weeks after settlement, a payment that looked finished can reopen long after the day closed. Design for that from the start:

• Keep every ACH payment reopenable, with its original entry, trace number and your reference stored together.
• When a late return arrives, reopen the payment and the day it belonged to, with the earlier closure kept on record rather than rewritten.
• Decide in advance what happens to a customer or seller balance when a collection comes back after you have already paid it out.
• Report returns by reason code and by origin, so a rise in one code, or from one source, is noticed early.

Return rates matter beyond reconciliation. Nacha monitors return rates, and unauthorised returns, including R10 and R11, are counted in the unauthorised entry return rate. A rise in those codes is a risk signal as well as a reconciliation task.

A daily ACH returns routine

1. Load the day’s return and notification of change files from your bank or provider.
2. Link each return to its original entry by trace number, then by your own reference.
3. Reopen each linked payment with the reason code, and reverse its effect in the ledger.
4. Match the return amounts to the bank movements they appear in.
5. Raise anything unlinked as an orphan, and update account details from notifications of change.
6. Review returns by code and age, and give every open item an owner.

What to tell customers and recipients

A return is usually felt first by a person, not by finance: a contractor who wasn’t paid, or a customer whose payment bounced. Support needs to see the return, its reason in plain language, and the next step, on the same record as the original payment. “The account number was closed; please send new details” is a useful answer. “The payment failed” is not.

That is only possible when the return is linked to the original entry as soon as it arrives. If returns sit in a separate file or an unmatched bank line, support gives a guess, the recipient chases, and finance finds the gap weeks later.

How Flominzo handles ACH returns

In Flominzo, a return is new evidence for an existing payment. It is linked to the original entry, the reason code is recorded, and the payment reopens so the reversal is explained rather than lost. A return that arrives after a day was closed raises a post-closure exception, with the earlier decision kept on record. Nacha return files and bank reports are mapped as evidence sources for your deployment, and BAI2 and other bank layouts are assessed during scoping.

Flominzo is software: it works through the licensed banks and providers you use, and it does not hold customer funds.

Questions

Sources

• Nacha: differentiating unauthorized return reasons (R10, R11, R29)
• Nacha: a second chance, understanding ACH reversals

Related guides