FinStackCloud
Return code

ACH reversal

Reversal fundamentals for ACH operators: valid trigger conditions, timing boundaries, and controls to prevent compounding errors.

Last updated May 5, 2026 3 min read Payment Rails

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:

  1. 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.

  2. Formatting requirements
    In the batch header, Company Entry Description must include REVERSAL (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.
  3. 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.

  4. 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 REVERSAL description.
  • 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

  1. Classify the error reason (duplicate, wrong receiver, wrong amount, wrong date).
  2. Confirm the 5-banking-day limit has not been exceeded.
  3. Build reversal entries with REVERSAL in Company Entry Description.
  4. Verify SEC/Company ID(or Originator ID for IAT)/Amount are unchanged.
  5. Use a new trace number and carry original trace reference in addenda/remittance data for linkage.
  6. Notify affected customers per policy and monitor for returned improper reversals (e.g., R11/R17 paths).

Editorial & EEAT

FinStackCloud publishes independent, format-focused explainers for operators and engineers. Pages are reviewed for technical accuracy on a best-effort cadence; always corroborate with your processor and licensed specifications.