In this article
Classify the return reason, protect the authorization boundary and account for a returned payment without creating a duplicate collection.
A deposit appeared, the order was marked paid, and then an ACH return notice arrives. The right response begins with linking the notice to the original payment. It does not begin with charging the same account again. A return changes the payment story, and the return reason determines which questions need an answer before any further collection attempt.
Read the reason before choosing a response
Helcim’s ACH return guide says return emails include a code and explanation. If a returned payment was already funded, the principal can be withdrawn from the linked merchant bank account; return fees may also apply. The guide distinguishes funding problems from closed accounts and authorization disputes. It specifically warns against simply retrying revoked, stopped or disputed debits. Check the actual notice and current rules for the case.
For an internal queue, create separate fields for the original payment reference, return reference, principal, observed bank movement, return reason, owner and next permitted step. Keep the customer’s sensitive banking information out of a broadly shared task list. The operational purpose is to coordinate the exception, not to make another repository of payment credentials.
Trace a return after deposit
Consider a fictional $640 service invoice. The original ACH payment was recorded and matched to a deposit. Later, a return record identifies the same $640 principal. The reviewer should be able to follow both movements. Deleting the original receipt from the history would make the first deposit inexplicable; ignoring the return would leave the customer balance and cash movement inconsistent.
For this teaching example, record the principal reversal separately from any documented return charge. If the bank shows a different amount, do not assume the difference is a fee without finding the supporting record. Several adjustments may share a posting date. Reconciliation requires an explanation for each component, not just a plausible subtraction.
Helcim’s ACH transaction and batch guide distinguishes the status of an individual payment from the status of its batch. Review the returned transaction itself. A batch that previously settled does not establish that every member payment remains unreversed forever.
Use reason-based branches
Imagine three fictional queue entries. One concerns insufficient funds, another a closed account and a third a customer who says no authorization existed. The first needs a discussion of the payment problem and whatever retry conditions currently apply. The second needs a valid alternative payment arrangement. The third requires the authorization issue to be addressed before considering further debits. Those are different work items even if all three balances are $640.
Do not treat these branches as permission to retry. An employee must still follow the merchant’s authority, the customer’s valid authorization and current processor and network requirements. A promise to pay an invoice and authorization to debit a specific account are related facts, but they are not interchangeable.
Prevent two people from collecting at once
- Assign one owner for the unresolved payment.
- Check whether a scheduled retry or another collection request already exists.
- Log customer contact without copying account numbers into ordinary notes.
- Record any replacement payment against the same business obligation.
- Verify the original return and replacement payment separately before closing the exception.
A final invented exercise illustrates the risk: the bookkeeper sends a new payment request while a colleague manually retries the original debit. Both succeed. The team has solved the unpaid-balance problem twice and created an overpayment. A shared exception owner and a check for pending actions would have exposed the collision.
Close the queue item only when the financial movements and the business balance have an explained outcome. “Customer contacted” is a milestone, not resolution. If the next step depends on new authorization or processor guidance, make that dependency explicit and leave the item open for the responsible person.