When reversal is needed and who triggers it
Reversal is used only when an ACH entry is erroneous under NACHA rules. It is not a general cancel tool.
Typical triggers (NACHA-permitted reasons):
- Duplicate entry/file (same payment sent more than once).
- Wrong Receiver (payment sent to unintended account/person).
- Wrong amount (amount is incorrect).
- Wrong date error (debit was sent earlier than intended, or credit later than intended).
Who triggers it:
- Originator (or its ODFI acting on its behalf) initiates the Reversing Entry.
- RDFI does not “initiate reversal for the Originator”; RDFI may instead return an improper reversal.
Rule limits and boundaries (NACHA)
Key constraints to enforce in your runbook:
Important: Even when a reversal is originated within the NACHA timing window and formatted correctly, it is not guaranteed to be accepted as a forced outcome. RDFI/Receiver-side handling can still result in rejection/return, so operations should treat reversal as a controlled remediation attempt, not an assured rollback.
-
Timing limit
Reversal must be transmitted so it is made available to the RDFI within 5 banking days following the settlement date of the erroneous entry. -
Formatting requirements
In the batch header, Company Entry Description must includeREVERSAL(uppercase).
The reversal must keep these fields identical to the original entry:- Company ID (or Originator ID for IAT entries)
- SEC code
- Amount
- Reversing entry should use a new trace number (do not reuse the original trace number).
- Operational best practice: include the original trace number in addenda/remittance context so downstream teams can reconcile original vs reversal quickly.
-
Not all reasons are valid
Reversal is improper if used for a reason outside NACHA-permitted error categories, if sent late, or if used due to failure to fund the original entry. -
Not a cross-type rewrite
Because SEC must match the original entry, reversal is not a tool to “change transaction type.” It is a corrective offset tied to the same underlying entry context.
Practical samples
Sample 1: Duplicate payroll credit file
- Scenario: payroll batch was submitted twice; employees would be overpaid.
- Action: Originator/ODFI sends reversing entries for the duplicate batch with
REVERSALdescription. - Checks: same SEC, same amount, same originator identity; submitted inside the timing window.
Sample 2: Wrong amount on consumer debit
- Scenario: intended debit is $120.00, but $1,200.00 was originated.
- Action: send reversing entry for the erroneous debit, then (if needed) originate the correct amount as a new entry under normal authorization controls.
- Checks: reversal only addresses the erroneous item; reconciliation links original trace and reversal trace.
Sample 3: Debit sent earlier than intended date
- Scenario: recurring debit is released before the intended effective date.
- Action: treat as wrong-date erroneous entry and initiate reversal under NACHA-permitted reason.
- Checks: incident log includes intended date vs actual sent date and ODFI approval evidence.
Sample data (illustrative) and highlight points
Batch Header (5 Record)
Company Name: ACME PAYROLL
Company ID: 1234567890
SEC Code: PPD
Company Entry Description: REVERSAL
Effective Entry Date: 260506
Entry Detail (6 Record) - Reversing credit
Transaction Code: 22
RDFI Routing: 021000021
DFI Account Number: 123456789
Amount: 0000015000 (=$150.00)
Individual Name: JANE DOE
Trace Number: 091000019876543
Addenda (7 Record) - optional but recommended operational linkage
Payment Related Information: ORIG TRACE 091000010123456 DUP FILE REVERSAL
Highlight
Company Entry Description = REVERSAL是识别反向分录的第一关键点。Company ID / SEC / Amount需与原始错误分录一致,不能借 reversal 改业务类型。Trace Number必须是新值;原始 trace 建议放在 addenda 里做关联。- 这笔就算按时发出,也不是强制成功,仍可能被对方拒绝/返回。
Operator checklist
- Classify the error reason (duplicate, wrong receiver, wrong amount, wrong date).
- Confirm the 5-banking-day limit has not been exceeded.
- Build reversal entries with
REVERSALin Company Entry Description. - Verify SEC/Company ID(or Originator ID for IAT)/Amount are unchanged.
- Use a new trace number and carry original trace reference in addenda/remittance data for linkage.
- Notify affected customers per policy and monitor for returned improper reversals (e.g., R11/R17 paths).