ACH Exception Handling and Return Research. A practitioner deep dive into ACH exception investigation, original-entry matching, return research, evidence, unmatched items, bank-to-bank inquiries, settlement reconstruction, reconciliation and root-cause closure.
ACH exception handling begins where a simple status code stops being enough. A return arrives. A corporate customer says a payroll credit never reached the employee. A debit is disputed but the account team cannot immediately find the original authorization. An incoming return cannot be matched to the payment hub. An ODFI believes an RDFI returned an entry too late. A recovery team has contacted another bank, but nobody can tell the customer whether funds were actually recovered. At that point the task is no longer merely to know what an ACH return, reversal or Notification of Change means. The task is to reconstruct what actually happened, prove it from evidence, decide the next permissible action and close the case without damaging the financial history.
That is the purpose of Chapter 13.
Chapter 11 explained the ACH mechanisms themselves: Returns, Reversals, Notifications of Change, dishonored returns, contested/corrected dishonored returns and Request for Return. Chapter 12 explained preventive and detective fraud controls. Chapter 13 is the operations and investigation layer that joins those network events to customer instructions, files, settlement evidence, account postings, case evidence and corrective action.
A strong ACH investigator does not begin with “Which R-code is this?” The investigator begins with a broader set of questions:
What was the original instruction? What entered the ACH Network? What did the ACH Operator process? What settled? What did the RDFI do? What exception event followed? What did the customer account show? What evidence is still missing? What rule clock applies? What can the bank still do?
The chapter uses this investigation model throughout:
exception intake → classify the business problem → identify the original entry → reconstruct network chronology → reconstruct customer/accounting chronology → validate reason and timing → collect evidence → contact the right party when needed → decide the next action → reconcile the financial position → communicate accurately → document root cause → close with auditable evidence.
For a roughly 60-minute core session, spend about 35 minutes on Sections 2–7 and Sections 10–14. For the next 10 minutes, use the chapter’s three diagrams to follow identifiers from the original entry to case closure. Use 10 minutes to work through one case in Section 16, then spend the final 5 minutes explaining: What evidence is still missing when a recovery request exists but no recovered funds are recorded? Treat these timings as a study guide. The remaining sections, additional cases and extended reference material are follow-up study; completing the whole chapter takes longer.
Chapter navigator
- What ACH exception research really is
- Exception intake, triage and ownership
- Finding and proving the original ACH entry
- Reconstructing the network timeline from file to settlement
- Researching returns and return-reason evidence
- Unauthorized debit research, WSUD and authorization evidence
- Reversal and duplicate-payment research
- NOC and corrected-master-data research
- Dishonored, contested and corrected-return research
- Unmatched returns, rejects and orphaned exception events
- Bank-to-bank research, ACH Contact Registry and recovery communication
- Case statuses, evidence quality and customer communication
- Settlement, accounting and reconciliation during investigation
- Operational reporting, ageing, root cause and management information
- Real-bank operating model, resilience and investigation controls
- End-to-end cases, BA checklist and testing
1. What ACH exception research really is
ACH exception research is the disciplined process of turning fragmented operational evidence into one defensible payment story.
That sounds obvious, but in a real bank the evidence is rarely stored in one place. The customer instruction may be in an online-banking platform. The ACH file may be created by a payment hub. Operator acknowledgements may sit in the ACH gateway. Settlement advice may come through Federal Reserve reporting. The customer posting may be in a deposit system. A return can arrive in another file several days later. A fraud case may have separate notes. A customer-service agent may record a phone call in a CRM. If those records are treated as separate truths, the investigation becomes slow and contradictory.
The investigator’s job is to connect them without inventing missing facts.
A useful distinction is between known network facts, known internal facts, customer assertions and analyst conclusions.
A FedACH or EPN processing record can establish that a particular ACH entry or return was processed by the operator. A core ledger can establish that an account posting occurred. A customer statement that “I never authorized this debit” is important evidence, but it remains a customer assertion until handled through the applicable authorization/WSUD process. An analyst conclusion that “the payment was probably duplicated by the upstream ERP” is not a fact until the source-file evidence proves it.
A mature case therefore does not store everything as free-text notes. It distinguishes evidence classes.
For example:
NETWORK_FACT = return entry processed
INTERNAL_FACT = customer account credited
CUSTOMER_ASSERTION = debit not authorized
ANALYST_FINDING = authorization record unavailable
FINAL_DISPOSITION = returned under applicable reason / originator remediation required.
Research is not the same as exception creation
Chapter 11 taught how the network exception mechanisms work. Chapter 13 asks whether the bank can prove that the exception was handled correctly.
A return may already have settled when the case is opened. Research then focuses on why it happened, whether the Original Entry was matched correctly, whether the Originator was informed, whether the receivable or customer account was corrected, and whether further action is needed.
A reversal request may arrive before any reversing entry exists. Research then determines whether the sender error qualifies, whether the five-Banking-Day timing window is still open, whether a duplicate really occurred and whether the requested correction would create an additional error.
An NOC may be informational, but research may be needed when the Originator says it already changed the account information or when repeated NOCs suggest the corrected data is not reaching the right system.
The operational principle is:
the network event is one piece of the case; the investigation must explain the whole business and financial consequence.
The quality test for an investigation
A strong investigation should let a second analyst, auditor or customer-service specialist reproduce the conclusion without relying on the first analyst’s memory.
If the case closure says only Resolved - return received, the investigation is weak.
A defensible closure might say, in human terms:
Original corporate ACH credit was transmitted in file F123, settled on 4 August, and was returned by the RDFI because the receiving account was closed. The return was received and settled on 6 August, matched to the original trace, posted back to the Originator account, reported to the corporate customer, and the beneficiary record was flagged for repair. No new payment was automatically created.
That tells the story.
2. Exception intake, triage and ownership
Not every ACH exception should enter the same queue with the same priority.
A real operations day can include an unmatched return, a customer unauthorized-debit claim, a suspected duplicate payroll file, an NOC requiring a master-data update, an urgent fraud-recovery request and an operator rejection. They are all “ACH exceptions,” but their clocks, financial risk and required expertise are different.
The intake process should therefore classify the event before assigning work.
Useful intake categories include:
network return — a Return Entry has been received;
customer dispute — a Receiver or Originator has raised a problem, but the network mechanism may not yet be known;
reversal/recovery request — the originating side wants to correct or recover funds;
NOC/master-data correction — corrected data needs to be applied or researched;
operator/file exception — a file or entry was rejected, duplicated, missing or could not be matched;
settlement/accounting exception — network evidence and ledger evidence do not agree;
bank-to-bank inquiry — another financial institution is asking for information or action.
Triage should consider both clock and harm
An exception with a formal rule deadline needs priority even if its dollar value is small.
A $40 consumer unauthorized debit near the end of the applicable return period may be more urgent from a rule-timing perspective than a $500,000 credit return that already settled and only needs customer reporting.
A suspected duplicate payroll file can be urgent because thousands of employees may be affected even if a formal reversal clock still has time remaining.
A good priority model can use:
rule_deadline_remaining
financial_value
number_of_affected_entries
consumer_protection_impact
payroll/critical-payment impact
fraud/recovery urgency
customer tier or servicing priority
manual action required.
These are prioritization inputs, not excuses to ignore a rule deadline.
Ownership must be explicit
An exception should have one accountable owner even when multiple teams contribute evidence.
Payments operations may own the ACH case while fraud supplies fraud findings, customer service supplies customer statements, the account team obtains supporting authorization evidence and finance resolves a suspense item.
The case should still show:
case_owner
current_action_owner
next_action_due
external_dependency
escalation_owner.
A case with five teams copied and no owner is operationally unowned.
Separate case priority from customer emotion
Urgent customer calls matter, but the operational process should not let the loudest caller replace the rule-based queue.
A good servicing experience can acknowledge urgency while still performing the correct investigation. For example:
We have confirmed the payment settled through ACH. We are now researching the receiving-bank exception and will update you when the return or recovery status is evidenced.
That is better than promising an outcome before the facts are known.
3. Finding and proving the original ACH entry
Most ACH research becomes much easier once the original entry is identified with confidence.
The original entry is the anchor for the entire exception chain. Without it, the analyst cannot reliably interpret the return reason, calculate deadlines, evaluate reversal eligibility, locate authorization evidence or reconcile settlement.
The strongest match usually uses network and bank identifiers together.
Useful fields can include:
bank_payment_id
customer_payment_reference
trace_number
Company ID
SEC Code
amount
effective_entry_date
settlement_date
ODFI routing number
RDFI routing number
receiver account token/masked account
file_id
batch_number
entry sequence.
Not every system will have every field, but the investigation service should preserve enough stable identity to avoid matching solely by amount and date.
Why amount/date-only matching is dangerous
Imagine a payroll processor sends 40,000 credits of $1,250 on the same day. A return for $1,250 cannot be matched safely using amount and settlement date alone.
If the trace number and original RDFI/account reference are available, they provide much stronger evidence.
Secondary matching can be useful for legacy or migration cases, but it should return a confidence result rather than silently force a match.
For example:
MATCH_CONFIDENCE = HIGH
matched on trace + amount + RDFI
is very different from:
MATCH_CONFIDENCE = LOW
matched only on amount + date + customer.
Low-confidence cases should enter controlled manual research.
Preserve the original exactly as processed
If the beneficiary account is later corrected, the historical original entry should not be rewritten to show the new account number.
Research depends on historical truth.
The original record should show what was actually sent. A repaired payment or corrected master creates a later event.
Research across migration boundaries
A common production problem occurs when the original ACH payment was created before a system migration but the exception arrives after cutover.
The new platform may not have the old payment ID, but the network trace and historical archive should still allow the case to be reconstructed.
Migration planning should therefore retain lookup capability for historical trace numbers, file identifiers, account references, Settlement Dates and customer references for the period in which later exceptions can still occur.
A cutover test should deliberately include:
legacy forward entry → new-platform return.
4. Reconstructing the network timeline from file to settlement
Once the original entry is found, the investigator reconstructs chronology.
Chronology matters because ACH status is not one moment.
A typical forward sequence can include:
customer instruction created
approved/released
file created
file transmitted
operator accepted
operator distributed
interbank settlement
RDFI received
customer posting/availability.
An exception sequence can then add:
return/reversal/NOC created
exception transmitted
operator accepted exception
exception distributed
exception settlement
originating/receiving bank posting
customer notification
reconciliation completed.
The exact sequence varies by event, but separating the stages prevents bad conclusions.
Operator acceptance is not settlement
A FedACH reference or file-acceptance record shows that the operator accepted a file/item for processing. It should not automatically be displayed to a customer as settled.
Settlement evidence should come from the applicable settlement reporting or ledger effect.
Federal Reserve services provide settlement summaries and ACH reporting that institutions can use to reconcile processed activity. FedPayments Reporter also provides return-item reports and files containing original-forward and return information for investigation and customer reporting.
Use the operator schedule to explain timing
FedACH electronic returns have multiple transmission/distribution/settlement windows during the day. Some settle the same day; later windows can settle the next business day.
Therefore an analyst should not assume:
return received today = return settled immediately.
The processing timestamp and settlement schedule need to be checked.
Build a timeline rather than a paragraph first
A practical investigation view can show:
| Time | Event | Evidence source |
|---|
| 08:14 | Corporate released file | Channel audit |
| 08:19 | ACH file transmitted | Gateway |
| 08:21 | Operator accepted | Operator acknowledgement |
| 13:00 | Forward settlement | Settlement advice |
| Next Banking Day 09:07 | RDFI return created | Return entry |
| 13:00 | Return settlement | Settlement advice |
| 13:14 | Originator account corrected | Ledger |
| 13:20 | Corporate notified | Portal/report |
The actual times are examples, not universal cutoffs. The value of the timeline is the evidence structure.
5. Researching returns and return-reason evidence
A return reason code is the start of research, not the entire conclusion.
The analyst should understand what the code means, whether the original entry type is compatible with that reason, whether the return arrived within the applicable timeframe, and what customer/business action should follow.
For an account-closed credit return, research is usually straightforward: confirm the original credit, identify the returned entry, confirm the account-closed reason, reconcile the returned value and route the Originator toward beneficiary repair.
For an unauthorized debit return, the research is deeper because authorization evidence and customer claims matter.
For a return indicating an improper reversal or improper reinitiation, the analyst may need to inspect the prior exception chain.
Do not replace the official code with an internal label
An internal taxonomy can help operations, but it should remain separate.
For example:
network_return_code = R02
internal_family = ACCOUNT_CLOSED
customer_action = REPAIR_BENEFICIARY
is better than replacing R02 with a generic BENEFICIARY_ERROR value and losing the network evidence.
Validate the return against the original population
The investigator should check:
- original direction: credit or debit;
- consumer/non-consumer context where relevant;
- SEC Code;
- original Settlement Date;
- return transmission/settlement date;
- return reason;
- whether a prior return/reversal already exists;
- whether the return was received more than once;
- whether the value matches the original where required.
The objective is not to second-guess every RDFI decision. It is to ensure the bank processes the event correctly and identifies anomalies requiring further action.
Proposed rule changes must not contaminate current research
Nacha issued a 2026 Request for Comment proposing shorter timeframes for certain system-decisionable returns. That proposal is not the same as a currently effective rule.
An investigation engine should therefore store effective-dated rule logic and never calculate a historical case using an unadopted proposal.
The same principle applies when a rule is approved for a future date: historical cases use the rule effective when the relevant event occurred.
Return research should lead to an action
Typical outcomes include:
financially reconciled / customer notified
new payment instruction required
authorization review required
possible reinitiation review
dishonor eligibility review
fraud/risk escalation
no further network action available
manual bank-to-bank inquiry required.
A case should not remain open indefinitely just because the analyst can continue collecting information. The purpose of research is to support the next permissible decision.
6. Unauthorized debit research, WSUD and authorization evidence
Unauthorized-debit cases require disciplined separation of the customer claim, ACH return mechanics and the underlying authorization record.
Suppose a consumer says, “I never agreed to this debit.”
The RDFI may need a Written Statement of Unauthorized Debit (WSUD) for the applicable extended-return path. The ODFI/Originator may later need to produce authorization evidence. The investigator should not collapse those into one document.
The WSUD records the Receiver’s claim.
The Originator’s authorization evidence records the basis on which the debit was originated.
Those two pieces of evidence can conflict, which is precisely why research is needed.
A good unauthorized-debit case package
The RDFI-side package can include:
original debit details
customer complaint timestamp
WSUD version/content
WSUD signature/affirmative-action evidence
return reason
return transmission and settlement evidence
customer provisional/final credit evidence where applicable.
The ODFI/Originator-side research can include:
authorization record
authorization version
method/channel
date/time captured
related account-validation evidence
revocation history
prior transactions under the authorization
proof-request correspondence.
Do not infer authorization merely from prior payments
The fact that similar debits posted previously can be relevant, but it is not a substitute for the required authorization evidence.
Likewise, the fact that a customer disputed one debit does not automatically prove every historical debit from the Originator was unauthorized.
R10 and R11 business meaning matters
Current Nacha guidance differentiates a situation where the Originator is not known/not authorized from a situation where an underlying authorization exists but the entry does not conform to it, such as certain wrong-date or wrong-amount cases. The research team should preserve that distinction because remediation can differ.
A valid authorization with a nonconforming entry may need correction of execution behavior.
No valid authorization can indicate a more fundamental origination problem.
Regulation E and ACH research are connected but not identical
A consumer error-resolution case can involve legal obligations separate from ACH network processing. An ACH return may be one part of the bank’s response, while provisional credit, notices and investigation periods can be governed by Regulation E and bank procedures.
Chapter 13 should not replace a full Regulation E course. The operational point is that the case should show both tracks without pretending they are the same event.
7. Reversal and duplicate-payment research
Duplicate-payment research is one of the clearest examples of why evidence matters before action.
A customer may say, “You sent this twice.” The bank should first determine whether there were truly two ACH entries, whether both were released by the customer, whether one was a replay caused by a technical timeout, whether both settled and whether either already has an exception.
Prove the duplicate
Useful evidence includes:
- customer instruction identifiers;
- file hashes;
- channel upload IDs;
- idempotency keys;
- file control totals;
- ACH trace numbers;
- amounts and beneficiary data;
- release audit trail;
- operator acceptance records;
- settlement evidence.
Two entries with the same amount and beneficiary are not automatically duplicates. Recurring legitimate payments can look identical.
A strong duplicate conclusion shows why the second event lacked an independent business purpose.
Research before reversal
If a genuine sender error is confirmed, Chapter 11’s reversal rules apply. The investigator should record:
error_type
original settlement date
discovered_at
five-Banking-Day deadline
supporting evidence
requested reversal population
approver
reversal trace/settlement if executed.
The reversal should not be used merely because a fraud victim wants funds back after deliberately approving a payment to the wrong party under deception.
Large-file duplicate incidents
When an entire file is duplicated, research must work at population level.
Suppose file A contains 25,000 payroll credits and was transmitted twice because an upstream system timed out and retried without idempotency.
The bank should prove:
intended population = file A once
erroneous population = second transmission
affected entries = exact duplicate population
reversal population = exact entries being corrected.
Do not build a reversing file by manually selecting “roughly the same” payroll entries.
Root cause is part of closure
If the cause was a missing idempotency key, closing only the financial reversal case leaves the system defect alive.
The case can have two closures:
financial correction complete
and
root-cause remediation tracked.
8. NOC and corrected-master-data research
Notifications of Change create a different kind of investigation because the primary issue is information, not value.
An NOC tells the Originator that information used for future entries should be corrected. If the same NOC keeps returning, operations must determine why the correction is not sticking.
Start by finding the authoritative master
The receiving ACH gateway is rarely the final owner of customer payment master data.
For a corporate payroll payment, the employer may own the employee bank details.
For a bank-managed recurring transfer, the bank may own the payment instruction.
For a Third-Party Sender arrangement, the NOC may need to travel through the TPS to the underlying Originator.
The investigation therefore asks:
Who owns the field that must change?
Then:
Did the NOC reach that owner? Was the change applied? Did the next payment use the corrected data?
Evidence chain for NOC research
A useful chain is:
original entry → NOC received → NOC matched → correction interpreted → master owner identified → change approved/applied → downstream propagation → next generated entry inspected.
The final step matters. A database can show the master was updated while a scheduler still uses a cached copy of the old data.
Corrected NOCs and versioning
If a corrected NOC supersedes an earlier NOC, the case should preserve both versions.
Do not delete the first NOC from history.
The record should show why the active correction changed.
Repeated NOC as a process defect
A repeat NOC can indicate:
- the Originator ignored the first correction;
- the ODFI failed to deliver it;
- a processor updated the wrong customer record;
- a recurring scheduler did not refresh its data;
- a corrected NOC was mishandled;
- the next entry was generated before the correction became effective.
The analyst should determine which link failed rather than treating each NOC as an isolated event.
9. Dishonored, contested and corrected-return research
Dishonor research begins when the ODFI believes an incoming return itself has a qualifying defect.
This is a specialized process. It is not a general right to reject a return simply because the Originator disagrees with the outcome.
Under the current 2026 rules reflected in Nacha’s return-efficiency consultation materials, the ODFI’s dishonored-return timeframe is five Banking Days after the Settlement Date of the Return Entry, and the RDFI’s contested/corrected dishonored-return timeframe is two Banking Days after settlement of the dishonored return. Nacha was consulting in 2026 on potentially shortening these periods; those proposals should not be treated as already effective.
Reconstruct the clock mathematically
An investigation view should show:
original forward settlement
return settlement
return availability/transmission evidence
applicable Banking Day calendar
dishonor deadline
dishonor transmission
dishonor settlement
contest/correction deadline
contest/correction transmission.
The analyst should be able to explain the calendar calculation rather than simply reading timely = false from a system flag.
Preserve both institutions’ positions
A dishonor case can become a disagreement between financial institutions.
The ODFI may assert that the return was untimely.
The RDFI may contest that assertion using evidence that the ODFI’s chronology or calculation is wrong.
The case should retain both positions, the network events and the final disposition.
IAT boundary
IAT entries have special considerations. Nacha’s public IAT guidance states that automated dishonored and contested dishonored return codes are not supported for IAT entries; related requests need to be handled outside the ACH Network. Chapter 51 owns IAT depth, but Chapter 13 must avoid routing an IAT research case into an unsupported automated dishonor workflow.
10. Unmatched returns, rejects and orphaned exception events
An unmatched exception is not a harmless data-quality issue. It can represent money that moved but cannot be connected to the bank’s internal customer/payment record.
Examples include:
- return received after platform migration;
- malformed or truncated internal reference;
- payment originated through an old processor;
- duplicated inbound file causing one copy to lose normal matching state;
- return received for a payment whose archive was moved;
- file or entry rejected before the normal payment ID was created;
- customer/account merger changing internal identifiers.
Never force-match to clear the queue
The purpose of research is not to reduce the unmatched count at any cost.
A forced match to the wrong original can debit the wrong customer, corrupt return-rate reporting and create an audit problem.
A controlled matching ladder can use:
- exact network trace/original trace relationship;
- exact internal bank payment ID where carried/linked;
- file/batch/entry identity;
- RDFI/ODFI + amount + date + account token;
- customer-level secondary research;
- manual evidence review.
Each step should increase or decrease confidence transparently.
Suspense is a temporary accounting state, not closure
If the financial return has settled but the customer record cannot yet be identified, a suspense account may be used depending on bank architecture.
The suspense item still needs:
owner
exception_reference
amount
age
reason_unmatched
next_action
escalation_date.
A suspense balance with no linked case is hidden operational debt.
Operator rejects are different from customer returns
An operator-rejected entry may never have completed forward ACH processing. It should not be reported as an RDFI Return Entry if it never reached that stage.
FedACH provides rejected-entry information that can be used to analyze entries rejected during FedACH processing. Research screens should preserve the difference between:
operator rejection
and
RDFI return.
The customer impact can be similar—payment did not complete—but the network story is different.
Orphaned NOCs
NOCs can also be unmatched. An unmatched NOC may not create immediate financial exposure, but it can cause the next payment to fail or generate another NOC.
NOC ageing deserves the same operational ownership discipline as financial exceptions.
11. Bank-to-bank research, ACH Contact Registry and recovery communication
Some cases cannot be resolved from internal data alone.
An ODFI may need to ask an RDFI about a suspected fraudulent credit. An RDFI may need to contact an ODFI about debit authorization. A duplicate payment may require a Request for Return. A WSUD copy or letter of indemnity may need to be exchanged. These are exactly the kinds of operational and fraud-management use cases for which Nacha maintains the ACH Contact Registry.
The ACH Contact Registry is accessed by authorized users through Nacha’s Risk Management Portal. Nacha describes registered contact information as being for ACH Network operational, risk and fraud-management purposes.
Contact the right function, not a random branch
A high-quality case should record:
institution contacted
registry/approved contact source
contact function = ACH operations | fraud/risk
date/time
case purpose
information sent
response received
next action.
The investigator should avoid using unverified contact information supplied by a customer or fraudster when an established bank-to-bank channel exists.
Protect customer data during research
Bank-to-bank research can involve sensitive account and transaction information. The case should share only what is necessary through approved channels and retain evidence of what was exchanged.
A public email address found through a web search is not a substitute for an approved bank operational contact process.
Request for Return research
A Request for Return should be tracked as a request lifecycle.
The current Nacha framework requires an RDFI to advise the ODFI of the status of a Request for Return within ten Banking Days of receipt, while compliance with the return request remains optional under the applicable rule framework.
A consumer unauthorized-debit return has different clocks. In addition to the outer extended-return deadline, the prompt-return requirement uses the opening of the sixth Banking Day after completion of review of the signed WSUD. Capture that review event in the evidence timeline. Chapter 11 explains this rule; it must not be replaced with the ten-day Request for Return response clock.
The investigation must therefore distinguish:
request sent
status response received
RDFI agreed/declined/other
actual return/recovery received
final amount recovered.
A status response is not proof of funds recovery.
Fraud recovery often needs parallel workstreams
For a fraud-induced credit, the ACH operations case may run alongside fraud investigation, receiving-bank fraud contact, law-enforcement processes and customer servicing.
All can be linked to one recovery case, but only actual ACH Return Entries should be represented as ACH returns.
12. Case statuses, evidence quality and customer communication
A case-management system should show what is known and what is still being researched.
Weak statuses such as OPEN, PENDING and CLOSED are not enough for ACH operations.
A more useful state model can include:
INTAKE_RECEIVED
ORIGINAL_MATCH_PENDING
ORIGINAL_MATCHED
NETWORK_TIMELINE_RECONSTRUCTED
EVIDENCE_REQUESTED
BANK_TO_BANK_INQUIRY_SENT
CUSTOMER_ACTION_REQUIRED
FINANCIAL_ACTION_PENDING
FINANCIALLY_RESOLVED
ROOT_CAUSE_PENDING
READY_TO_CLOSE
CLOSED.
Not every case uses every state.
Evidence quality should be explicit
An analyst may have partial evidence.
For example:
operator return item found
but
customer ledger posting not yet found.
The case should show that gap rather than allow the analyst to close based on assumption.
A practical evidence checklist can classify:
required — case cannot close without it;
supporting — useful but not mandatory for this case type;
not applicable — deliberately excluded with reason.
Customer language should match certainty
A customer asking “Where is my money?” deserves a human answer, but it must be accurate.
Poor wording:
The payment failed.
Better:
The original ACH credit settled, but the receiving bank returned it because the account was closed. We have received the return and credited it back to your account.
For a recovery case:
We sent a recovery request to the receiving bank. We have not yet received funds back, so recovery is not guaranteed.
For an investigation with missing evidence:
We have confirmed the ACH file was accepted. We are still reconciling the settlement and receiving-bank outcome.
Do not expose internal jargon unnecessarily
Customers may not need to hear R02, R17, dishonored return, operator advice or settlement suspense unless the customer is a treasury professional who benefits from that detail.
The system can show the code to operations and a clear business explanation to the customer.
13. Settlement, accounting and reconciliation during investigation
ACH research is incomplete until the financial story agrees with the network story.
A case can be technically understood yet financially unresolved.
For example, the investigator may identify the correct return but discover that the return settlement posted to an ACH control account and never reached the customer ledger because of a downstream failure.
That case is not closed.
Reconcile each financial event independently
For a returned debit collection:
forward debit settlement
customer/Originator credit
return settlement
customer/Originator debit
receivable reopened
fees if any as separate product event.
For a duplicate credit plus reversal:
intended credit
duplicate credit
reversing debit
final customer position.
For an NOC:
no direct value settlement from NOC
but
master-data correction and next-payment outcome.
Settlement source should be authoritative
Federal Reserve settlement summaries, account statements and operator reporting can support the bank’s reconciliation. The exact evidence source depends on the ACH Operator and bank architecture.
The investigator should not infer settlement merely because a payment hub status says sent or because a customer ledger changed.
A three-way reconciliation model
A useful operating control is:
network evidence ↔ bank settlement/accounting evidence ↔ customer/product evidence.
If all three agree, the financial story is strong.
If the network shows a $7,500 return settled but the ACH GL has $7,500 unresolved and the customer was never debited, the investigation should route to accounting repair.
If the customer was debited but no return settlement exists, the bank may have an internal posting error.
Reconciliation should survive replay
If the exception-processing service is restarted, it must not post the same return financial effect twice.
Stable exception IDs, operator identifiers and idempotent accounting interfaces are essential.
The research screen should show whether the event was replayed and whether duplicate protection was applied.
14. Operational reporting, ageing, root cause and management information
Exception research produces valuable operational intelligence when cases are classified consistently.
A dashboard should answer more than “How many cases are open?”
Useful measures include:
- cases opened by exception type;
- unmatched returns and NOCs;
- average/median time to original-entry match;
- cases near rule deadline;
- bank-to-bank inquiries awaiting response;
- Request-for-Return recovery outcomes;
- authorization evidence requests outstanding;
- suspense amount and age;
- dishonor/contest cases;
- duplicate-payment incidents;
- repeated NOCs;
- return-reason trends;
- customer-notification delays;
- reconciliation breaks;
- root-cause categories;
- reopened cases.
Age from the right event
Case age and rule age can be different.
case_opened_at may be 10:00 a.m.
return_received_at may be 7:00 a.m.
original_settlement_date may be two days earlier.
Operational dashboards should not use case creation time as a substitute for all clocks.
Root cause should be controlled taxonomy plus narrative
Useful root-cause families can include:
CUSTOMER_DATA_ERROR
ORIGINATOR_AUTHORIZATION_PROCESS
BENEFICIARY_MASTER_ERROR
DUPLICATE_SUBMISSION
CHANNEL_REPLAY
RDFI_ACCOUNT_STATUS
NOC_NOT_PROPAGATED
MIGRATION_MATCH_FAILURE
ACCOUNTING_INTERFACE_FAILURE
OPERATOR/CONNECTIVITY_EXCEPTION
CUSTOMER_DISPUTE
FRAUD/SCAM
UNKNOWN_PENDING_FURTHER_REVIEW.
A taxonomy supports trend reporting; a short narrative explains the specific incident.
Measure repeat problems
If the same corporate sends recurring files with the same beneficiary error, or the same internal component repeatedly creates unmatched returns, the bank should see the pattern.
Research should feed preventive improvement.
Chapter 13 is therefore not only about closing yesterday’s exception. It is also about reducing tomorrow’s exception volume.
15. Real-bank operating model, resilience and investigation controls
ACH investigation is a production capability.
It needs entitlements, audit, resilience, handoffs, secure evidence and tested contingency procedures.
Segregation of duties
An analyst who researches a suspected duplicate may not automatically be entitled to originate a reversal. A user who can change beneficiary master data may not be allowed to close the related investigation without review.
High-impact actions should be separated according to bank policy.
Evidence must be immutable enough for audit
Case notes can be corrected, but the system should retain who changed what and when.
Attachments such as WSUDs, operator reports, customer correspondence and bank-to-bank communications need controlled retention and access.
A user should not be able to delete inconvenient evidence after a case decision.
Queue resilience
If the case platform is unavailable, rule deadlines continue to exist.
Business continuity should provide a way to identify deadline-sensitive cases, preserve inbound exception files and resume work without losing chronology.
A queue outage should not cause returns or NOCs to vanish from operational awareness.
File replay and exactly-once financial intent
Inbound ACH exception files may be reprocessed after a technical failure.
The platform should distinguish:
file received
file parsed
entry matched
case created
financial posting sent
financial posting confirmed
customer notification sent.
On restart it should resume from the missing stage rather than repeat every stage.
Role-based access to sensitive investigations
Fraud cases, consumer disputes and corporate account information can contain sensitive data. Access should follow role and need.
Operations users may need payment evidence without needing full fraud intelligence. Fraud investigators may need broader account behavior. Audit may need read-only evidence.
External dependency monitoring
Some cases wait on another bank, an Originator, TPS, customer, fraud team or legal team.
The case should not sit silently in PENDING.
It should show:
waiting_for
requested_at
expected_response_by
follow_up_due
escalation_path.
Investigation quality assurance
High-risk cases can be sampled or reviewed for:
- correct original-entry match;
- correct rule/timing interpretation;
- evidence completeness;
- financial reconciliation;
- customer wording;
- root-cause accuracy;
- appropriate escalation.
Quality review should improve analyst consistency without turning every case into a second full investigation.
16. End-to-end cases, BA checklist and testing
Case 1 — returned payroll credit cannot be matched
A $3,250 payroll return arrives, but the new payment platform cannot find the original entry because payroll was originated before migration.
The investigator searches the historical archive using original trace information, amount, RDFI and Settlement Date. The original legacy payment is found and linked to the return. Settlement evidence confirms the return value. The corporate customer is informed that the employee account was closed, and the employee master is flagged for repair.
The case should not modify the historical payment to the new bank account.
Test historical lookup, match confidence, migration archive access, return settlement and customer reporting.
Case 2 — consumer disputes recurring debit
A consumer says a recurring ACH debit was unauthorized.
The RDFI intake captures the claim and applicable WSUD evidence. The return path is handled under the applicable ACH timeframe. The ODFI later requests/collects Originator authorization evidence.
The research record distinguishes the customer claim from the Originator evidence and the final ACH return outcome.
Test WSUD capture, original-entry matching, authorization-evidence linking, customer credit/accounting and case closure.
Case 3 — corporate says supplier payment was duplicated
The customer sees two $85,000 ACH credits to the same supplier.
Research finds two different ACH trace numbers but one customer instruction ID. Gateway logs show the first API request timed out after acceptance; the client retried without an idempotency key. Both entries settled.
A genuine duplicate sender error is established. Reversal eligibility is reviewed under Chapter 11 rules. The technical root cause becomes an API idempotency defect.
Test that two legitimate recurring payments with the same amount are not falsely classified as duplicates.
Case 4 — NOC keeps repeating
A corporate receives the same NOC for an employee account three payroll cycles in a row.
The bank proves that the NOC was received and reported to the corporate after the first cycle. The corporate updated its HR master, but the payroll file generator was using a cached account export created before the change.
The root cause is not RDFI sent duplicate NOC. It is stale upstream data.
Test NOC lineage through master ownership and next-payment generation.
Case 5 — ODFI believes return is untimely
A return arrives and the ODFI’s system flags it as potentially late.
The analyst reconstructs the original Settlement Date, return reason, return processing timestamp and applicable Banking Day calendar. The current rule timeframe is applied. If the return is eligible for dishonor, the case routes to the specialist workflow before the deadline.
Test weekends, federal holidays, historical calendar versions and a case where the initial system flag is wrong.
Case 6 — fraud recovery request does not equal recovery
A corporate customer was deceived into approving a $260,000 ACH credit to a fraudster-controlled account.
The ODFI sends a Request for Return and contacts the receiving institution through an approved fraud/operations route. The RDFI provides a status response, but no funds have yet been returned.
The customer portal must show recovery requested / awaiting financial outcome, not payment reversed.
Test bank-to-bank contact evidence, ten-Banking-Day status tracking, partial recovery and no-recovery outcomes.
Case 7 — network return settled but customer account not corrected
Operator and settlement reporting prove that a $12,000 debit return settled back to the ODFI. The Originator account did not receive the corresponding debit because an internal posting interface failed.
The investigation is technically complete at the network layer but financially incomplete.
The case remains open until the ledger posting is repaired and reconciled.
Test three-way reconciliation and prevention of duplicate manual posting during retry.
Case 8 — operator-rejected entry mistaken for RDFI return
A customer sees payment failed. The servicing system labels it as returned, but research shows the entry was rejected during operator processing and never reached the RDFI.
The case corrects the customer explanation and root-cause reporting.
Test that operator rejects and RDFI Return Entries remain distinct status families.
BA requirements checklist
Before approving an ACH exception-research capability, ask:
- Can every case link to the original ACH entry with a confidence level?
- Are network facts, internal facts, customer assertions and analyst findings stored separately?
- Can the platform reconstruct the full file/operator/settlement timeline?
- Are original and exception Settlement Dates stored separately?
- Can return reason and timing be validated using effective-dated rules?
- Can unauthorized-debit cases link WSUD and Originator authorization evidence without conflating them?
- Can duplicate research prove whether two entries share one business intent?
- Can reversal research show the five-Banking-Day deadline without automatically creating a reversal?
- Can NOC research identify the authoritative master and prove the next payment used corrected data?
- Can dishonor/contest cases reconstruct Banking Day calculations?
- Are unmatched returns and NOCs owned, aged and reconciled?
- Can operator rejects be distinguished from RDFI returns?
- Can analysts use approved bank-to-bank contact channels and retain communication evidence?
- Does Request for Return status remain separate from funds-recovery status?
- Are customer statuses written from proven evidence rather than optimistic assumptions?
- Can settlement/accounting/customer positions be reconciled three ways?
- Is suspense temporary, owned and aged?
- Are root causes versioned and reportable?
- Can inbound files be replayed without duplicate financial posting?
- Are historical/migration lookup paths tested?
Testing minimum
A serious Chapter 13 test pack should include ordinary matched returns, unmatched return, legacy-system return, consumer WSUD case, missing authorization evidence, duplicate-payment research, false duplicate, reversing-file research, repeated NOC, corrected NOC, untimely-return review, dishonor/contest timing, IAT boundary, Request for Return, partial recovery, operator rejection, settlement mismatch, customer-posting mismatch, suspense ageing, duplicate inbound file, file replay, stale case data, external-bank response delay and production cutover.
The final practitioner rule is:
Do not close an ACH exception because you found a code. Close it only when you can explain the original instruction, the network chronology, the exception mechanism, the financial outcome, the customer impact, the evidence supporting the conclusion and the corrective action that prevents the same problem from remaining hidden.
Current/future R-code status
Nacha's approved R90 sanctions-compliance return code is future-effective March 17, 2028. It is not a current 2026 return code. Keep proposed return-efficiency material labelled as proposed and select return behavior from the effective Nacha Rules and the institution's controlled implementation.
Authoritative references
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.