Map an ACH Exception Workflow

An ACH exception is a small event right up until it becomes an expensive one. A treasury specialist who sits down with a customer to walk through a single exception can expose an entire process gap in ten minutes. The goal is not to sell a product that promises to stop every unauthorized debit. The goal is to trace one incident from the moment it was noticed to the moment it was resolved and find out where the process actually depends on one person remembering to act.

Why This Conversation Goes Wrong

Most companies believe they have an exception process because someone eventually handles every debit that looks wrong. That is not a process. That is a habit that works until the one person who owns it is out sick, on vacation, or has moved to a different role. When a specialist asks a general question like how do you handle ACH exceptions, the customer gives a general answer. They describe the intent of the process, not what actually happened the last time an exception hit their account.

The conversation goes wrong when the specialist accepts that general answer and moves on. It also goes wrong when the specialist turns the meeting into a pitch before understanding the gap. A customer who feels rushed toward a solution will disengage, and a customer who feels judged for having a weak process will get defensive. Neither reaction gets you the information you need, and neither one gets the customer closer to fixing anything.

The stakes are higher than one unauthorized debit. A company that cannot explain its exception handling will keep hitting the same gap every few months, and each time the resolution depends on luck rather than a system. A specialist who only fixes the fee or reverses the one debit leaves the underlying weakness untouched. The real fix is procedural, and procedural fixes only surface when someone asks the right sequence of questions about one specific event.

How To Prepare

Before the meeting, pull one real exception from the customer's account history. Do not use a hypothetical. A hypothetical lets the customer describe the process they wish they had. A real item forces them to describe what actually happened, including the parts that were improvised.

Write out four questions before you walk in. When was the exception identified, and by whom. Who received the alert first. What decision was made, and by whom. Where was that decision written down, if anywhere. These four questions map the entire lifecycle of an exception without asking the customer to defend their whole operation at once.

Check the account agreement and any existing alerting setup before the meeting too, so you know what the bank already offers for alert routing and where responsibility sits with the customer's own team. Also decide in advance what you are not going to do. You are not going to diagnose their internal controls. You are not going to promise that a bank service closes every gap you find. Your job in this meeting is to help the customer see their own process clearly. What they do with that clarity, including which reviewers get involved and which internal controls they add, stays their decision.

What To Say

Start with the specific item, not a general question. Ask the controller to walk you through what happened with the debit that came through last month.

The controller says, "We handled it. It just took a few days because nobody was totally sure who was supposed to respond first."

Ask a follow up question that stays specific. Ask who actually saw the alert first, and what happened between that moment and the final decision.

The controller says, "Our AP lead saw it in her inbox and forwarded it to me, but she was actually out the two days before that, so it sat there a little longer than it should have."

Now ask the question that exposes the real gap. Ask whether the alert goes to a shared inbox or to one person's individual inbox, and who covers that inbox when the usual person is out.

The controller pauses and says, "It goes to her inbox. I don't think anyone else has ever logged into it."

That pause is the moment the customer sees the gap themselves. You did not tell them their process was weak. You asked three specific questions and let the timeline speak for itself.

Mistakes To Avoid

Do not ask questions in the abstract, such as asking whether the customer has an exception policy. Everyone has a policy on paper. Ask about the last time the policy actually got used, and compare the two answers.

Do not fill silence with a product pitch. When the controller pauses after realizing the inbox has no backup, resist the urge to jump in with the exact service or configuration that supposedly fixes inbox coverage. Let the customer state the gap in their own words first. It sticks better when they say it than when you say it for them.

Do not treat this as a compliance audit. You are not there to grade the customer's internal controls or to imply that unresolved gaps are a violation of anything. You are there to help them build a clearer routine. Frame every gap you find as a normal thing to fix, not as a failure that already happened.

Do not close the meeting without a concrete next step. A vague agreement to look into documenting things better evaporates by the following week. Ask for something specific, and get a date attached to it.

How To Practice And Score It

A treasury specialist can rehearse this exact scenario before ever sitting across from a real customer. Pick a past exception, write out how a nervous or defensive controller might answer each of the four core questions, then practice asking the follow up that gets past the general answer to the specific one. Score yourself on three things. Did you get a name attached to who received the alert. Did you get a description of the actual decision, not just the outcome. Did you get an agreement on a documented next step before the meeting ended.

A manager coaching a newer specialist can run the same scenario as a mock conversation and score it against those same three points, then note whether the specialist filled silence with a pitch instead of a question. This is the kind of scenario that benefits from repetition, because the instinct to jump in and solve the problem for the customer is strong and it takes practice to hold back. DealSpeak's Banking practice conversations are built around exactly this kind of rehearsal, letting a specialist run the ACH exception conversation against an AI counterpart multiple times before trying it with an actual customer.

If you want to see this same discovery approach applied to a different treasury risk, Review a Treasury Check Fraud Pattern walks through a comparable conversation about check fraud controls. And if the customer's exposure runs beyond domestic ACH activity, you can also Discover a Treasury Foreign Currency Exposure to see how the same specific, timeline based questioning applies to currency risk.

Close

Ask the controller to bring a written timeline of one real exception to your next meeting. That single artifact does more than any policy document, because it shows the gap in the customer's own words and gives your team something concrete to review. Every exception needs a named owner, a named backup, and a written record of what was decided, and a good treasury conversation is what gets a customer to say that out loud themselves.