Use a Liquidity Forecast for Treasury Discovery

A request to get better visibility into cash sounds simple until you realize the business already has a forecast, and nobody has looked hard at why it fails. Treat that request as an invitation to study the model that already exists, not a cue to sell a dashboard or a sweep account. The specialist who asks about balances, update frequency, and decision ownership before proposing anything walks away with a real problem to solve instead of a vague ask for more data.

Why this conversation goes wrong

Most treasury specialists hear that a client needs better cash visibility and jump straight to product. They talk about account structures, reporting portals, or automated sweeps before anyone has described what the current forecast actually does. That instinct comes from good intentions, you want to solve the problem fast, but it skips the step that makes the solution correct. A forecast that misses payroll timing by two days is a different problem than one built on stale account balances, and the fix for each looks nothing alike.

The other failure mode is treating the forecast as an obstacle instead of the source of truth. If you ask the client to abandon their spreadsheet and adopt your tool, you lose the details buried inside it, who updates it, what assumptions are baked in, why regional numbers arrive late. Those details tell you whether the gap is technical, operational, or a matter of who owns the number. Skip them and you end up recommending a system change that fixes nothing because the manual process underneath never changed.

How to prepare

Before the meeting, learn what a treasury forecast normally includes at a company of similar size and complexity. Know the standard categories, cash on hand, receivables, payables, debt service, and how often each typically updates. This lets you ask sharper questions instead of generic ones.

Write down three or four questions before you sit down. Which balances feed the forecast. How often the numbers refresh. Who signs off on the number before it goes to leadership. What decision depends on that forecast being right. Have these ready so the meeting stays a discovery, not a pitch.

Also decide in advance what you will not do in this meeting. You will not recommend moving funds. You will not predict what an investment sweep would earn from an incomplete model. You will not promise a system integration exists or works a specific way until it clears a technical and service review. Naming these limits ahead of time keeps you honest when the client, understandably, asks for a quick answer.

What to say

Picture a mid sized hospitality company running a dozen properties. The treasury team builds a cash position every Monday in a spreadsheet, but regional managers send their numbers late, and the CFO keeps getting surprised by transfers that should have been anticipated.

You start with the forecast itself, not the pain point. "Walk me through what goes into the Monday number. Which accounts are included, and who sends you the figures."

The CFO says, "Each property manager reports cash on hand and expected receipts by Friday afternoon, and my team rolls it up over the weekend."

You ask the next question. "What decision rides on that Monday number, and what happens when it is wrong."

The CFO says, "Payroll funding and supplier payments both get scheduled off that forecast. Last month a large supplier payment showed up after the forecast was already locked, and we had to move money the same day with no warning."

You ask where that payment should have entered the process and who was supposed to catch it. The CFO admits nobody owns that check.

You close the loop. "So the gap is not the amount of data you have. It is that one property's late report has no backup path into the forecast. Bring me the layout you use now, the full account list, and that same day transfer as an example, and we will look at where the process should have caught it."

That last exchange does the real work. It turns a fuzzy complaint about visibility into one observable event, a missed update, an unclear owner, and a forecast with no way to absorb either.

Mistakes to avoid

Do not recommend a product before you understand the process. A specialist who suggests a real time dashboard in the first five minutes has skipped the discovery that tells you whether a dashboard even solves the problem.

Do not let the client leave with more data as the diagnosis. That phrase feels like an answer but it names nothing. Push for the specific account, the specific day, the specific person who was supposed to catch the gap.

Do not promise technical outcomes you cannot confirm on the spot. If the CFO asks whether your bank can plug directly into their accounting system, say plainly that any connection needs a technical and service review, and that you will find out rather than guess.

Do not treat this as a one meeting fix. A liquidity forecast breaks in more than one place, and trying to solve ownership, timing, and technology in a single conversation usually solves none of them well. If the account structure itself is part of the confusion, a related conversation on how to Review a Lockbox Remittance Problem shows the same discipline applied to a different intake issue, and it is worth practicing both.

How to practice and score it

Run this scenario with a manager or a peer playing the CFO, and give the client character something to defend, a forecast that looks fine on the surface but hides one gap you decide on ahead of time. Score yourself, or have someone else score you, on four things. Did you ask about balances and update frequency before offering any solution. Did you identify what decision the forecast supports. Did you resist naming a product or predicting an investment result. Did you end with a specific, concrete request instead of a general one.

The best rehearsal partners will not hand you the gap for free. They describe the surface complaint and make you dig for the real cause, the same way the hotel example needed a second question before the late supplier payment surfaced. Banking practice conversations on DealSpeak are built around that kind of scenario, and running a few of them with a manager scoring the transcript catches habits you cannot see in the moment, like reaching for a solution on the third question instead of the eighth. You can start from the Banking practice conversations hub and pick a scenario close to your own client base.

If the forecast conversation goes well and the client wants a next step, a natural sequel is to Build a Treasury Payment Approval Matrixsince a client who cannot explain who approves what usually has the same ownership gaps in their forecast.

Close it out

A liquidity forecast conversation succeeds when you leave with facts, not commitments. You now know which account caused the surprise, who missed the update, and what the CFO needs answered before the next Monday. That is a real problem you can act on, and it is worth far more than a fast answer that turns out to be wrong.