Review a Lockbox Remittance Problem

A lockbox exception report looks simple until you sit across from the person who has to explain it. A treasury specialist who walks into that conversation with only the bank's side of the story will miss the real problem, which usually sits inside the customer's own remittance data. Your job is to find out what actually breaks before you talk about what the bank can fix.

Why this conversation goes wrong

Most specialists open with the service angle. They describe imaging speed, exception handling tiers, or a new capture template, before they know how the customer's team actually works the exceptions today. That order gets the meeting backwards. The customer hears a sales pitch when what they need is someone to listen to their morning routine of matching checks to invoices by hand.

The other common failure is treating a remittance problem as a payment problem. A missing invoice reference is not a missing payment. The check cleared. The information that ties it to an open receivable did not arrive with it, or arrived in a format the lockbox cannot parse. If you frame this as payments being lost, the customer will spend the whole meeting arguing that point instead of describing the actual gap.

A third failure shows up when the specialist starts offering fixes for the customer's internal allocation policy. How a company decides which invoice a partial payment applies to, or how it handles a disputed short pay, is not a bank decision. Wander into that territory and you turn a discovery meeting into free consulting you cannot actually deliver on, and you set an expectation the bank will not meet later.

How to prepare

Before you sit down with the customer, pull the exception log for the past two or three months, not just last week. One bad week tells you nothing about a pattern. Look at exception rate as a share of total items, not just raw count, since a company that mails five thousand checks a month will always show a bigger number than one that mails five hundred.

Note who currently does the matching work and how long it takes them, if that information exists anywhere in your account notes. If it does not, that is your first question in the meeting, not something to guess at. Write down two or three specific remittance formats you have seen cause trouble for similar accounts, so you have concrete examples to compare against rather than a general question like any issues.

Also decide ahead of time where the line sits between what your service can show or configure and what belongs to the customer's own process. You will hold that line better in the room if you have already thought through it at your desk. Reading Build a Treasury Payment Approval Matrix is a good way to sharpen that same instinct for a related conversation, since approval authority runs into the same kind of boundary question.

What to say

Open with a question, not a description of your service. Ask the accounts receivable lead to walk you through what happens the morning a check arrives with no invoice number on it.

"Every morning I get a stack of checks with a company name and a dollar amount, nothing else," the lead says. "I match them against open balances by hand, and if two invoices are close in amount, I have to call the customer to confirm which one it is."

You respond by asking for scale rather than jumping to a fix. "How many of your checks come in each month, and roughly what share of those need this kind of manual match?"

"We get about two thousand checks a month, and I'd guess close to fifteen percent need me to dig," the lead says. "On a bad week that's most of my morning, every morning."

Now you can name what you actually found, plainly. "So the payment side is working fine. The problem is that close to three hundred remittances a month arrive without enough information to post them automatically, and someone on your team is closing that gap by hand." Ask what would help most, since the answer changes what you recommend. "If you had to pick one, would faster posting matter more to you, fewer manual touches each morning, or clearer identification of who actually sent the payment?"

"Fewer manual touches, honestly," the lead says. "The posting speed is fine once I've matched it. It's the digging that eats my morning."

End the meeting by naming what you can look into and what you cannot. "I can pull what remittance data our capture service is able to read today and check whether a different format on your end would give us more to work with. I can't tell you how your team should handle a disputed match, that's your call, but I can bring back options on the capture side." That sentence does two things. It commits you to something real, and it keeps you out of a decision that is not yours.

Mistakes to avoid

Do not promise that any single feature will end manual matching. Some remittance formats cannot be captured cleanly no matter what the bank offers, and a promise like that comes back to bite you the first time an exception still slips through.

Do not let the meeting end without a number. It happens sometimes is not something you can act on. Push gently for monthly volume, exception rate, and at least a rough estimate of hours spent on manual research, even if the customer has to guess.

Do not skip the sample remittances. A description of the problem is not the same as seeing three actual examples of the notices that caused trouble. Ask the lead to send a few, or pull them together on the spot if the system allows it.

Do not confuse a discovery meeting with a sales close. If you spend the whole conversation describing features, you never learn enough to know which feature, if any, matters here.

How to practice and score it

A manager coaching a treasury specialist on this conversation should score three things separately. First, did the specialist ask about volume, format, and current process before describing any bank capability. Second, did the specialist keep the conversation on the bank's remittance handling and stay out of the customer's allocation policy. Third, did the meeting end with a specific set of facts a follow up review can actually use, not a vague sense that something should improve.

Rehearsing this with a live customer carries real risk, since a specialist who fumbles the boundary question in front of a client can create a promise the bank cannot keep. That is where a practice tool like DealSpeak helps, since it lets a specialist run through a difficult lockbox conversation with an AI counterpart playing the accounts receivable lead, get scored against exactly these criteria, and try it again with a different remittance scenario before ever sitting down with a real account. You can find more Banking practice conversations built around scenarios like this one, including the payment file testing scenario in Prepare a Treasury Payment File Testwhich shares the same discipline of separating what the bank controls from what the customer controls.

Closing

A lockbox exception review works when you resist the urge to describe your service before you understand the customer's actual workflow. Ask for numbers, ask for samples, and hold the line between what the bank can fix and what belongs to the customer's own process. Do that consistently and the follow up conversation writes itself.