agent double-submitted the same ACH batch file: bank processed it twice
Fixes double-processed ACH batches. Use when an agent submitted the same batch file twice and the bank processed both, debiting or crediting accounts twice. Not for duplicate batches created deliberately or for single payments that failed.
agent double-submitted the same ACH batch file: bank processed it twice
TL;DR
The same ACH batch file went to the bank twice and both copies were processed, so every entry moved money twice. Stop further submissions, work with the bank to reverse the duplicate batch, and make submission idempotent: track batch control totals and submission state so a retry can never resend a submitted file.
agent double-submitted the same ACH batch file: bank processed it twiceSteps
- Halt the submission job so no third copy goes out. Success check: the job is stopped, not just slowed.
- Confirm with the bank that both batches processed and get the duplicate batch's reference. Success check: the bank acknowledges two processed copies.
- Initiate reversals for the duplicate entries per NACHA rules and your bank's process. Success check: reversal entries are submitted with their own tracking.
- Reconcile every affected account: confirm each entry was reversed exactly once. Success check: account balances match the intended single batch.
- Make submission idempotent: record the batch hash and control totals at submit time, and refuse to resubmit a batch already marked submitted. Success check: a retry after a timeout finds the submitted state instead of sending again.
When this applies
- The same ACH file was submitted twice and processed twice.
- Accounts show duplicate debits or credits from one intended batch.
- You need idempotent batch submission.
When it doesn't
- Two deliberately different batches; those are separate submissions.
- A single ACH payment that failed; that is a payment problem.
- Duplicate detection at the bank; most banks do not dedupe for you.
Tool + version compatibility
ACH batch processing via any bank or processor; NACHA reversal rules.
"ach batch submitted twice"
Halt, confirm with the bank, reverse, then make submission idempotent.
"duplicate ach batch file processed"
Track batch hash and control totals; refuse resubmission.
"ach batch reversal duplicate"
Reversals follow NACHA rules and need their own tracking.
Why it happens
ACH is a batch system with no built-in dedupe: if you send the same file twice, the bank processes it twice. Agents commonly resubmit after a timeout without checking whether the first submission landed, because the timeout looked like a failure. The file has no nonce the bank honors; your submission state is the only dedupe. Without it, every ambiguous timeout becomes a potential double payment.
Edge cases / pitfalls
- Reversal windows are limited; start the reversal process the same day you discover the duplicate.
- A timeout is not a failure; always check submission state before resubmitting.
- Include the batch hash in your logs so a duplicate is recognizable before the bank confirms it.
- Test the idempotency with a simulated timeout; the happy path never exercises this code.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst3jlB4pocQGN_6u-CWGgYw