Building the Business Case for a Treasury Management System

The business case for a TMS rests on quantifiable benefits — optimized cash, efficiency, error and fraud reduction, and better risk decisions — set against the full cost of ownership, plus the control and resilience value that's real but harder to put a number on. "It'll pay for itself" is not a business case. A credible one ties every benefit to a specific problem the system solves, measures it against today's baseline, and uses numbers conservative enough to survive CFO scrutiny.

Here's how to build one that stands up.

Why "it'll pay for itself" isn't a business case

Treasury teams often justify a TMS on intuition — everyone can see the spreadsheets are painful. But a CFO approving spend wants to know how much pain, worth how much, against what cost, versus what alternative. If you can't put defensible numbers on it, the project competes badly against ones that can. The discipline of quantifying also sharpens your own thinking about what the system must actually deliver.

The benefit categories

Build the case from these, quantifying each against a measured baseline of how things work today.

• Optimized cash. The headline lever. Accurate, timely visibility of group cash lets you reduce idle balances, cut short-term borrowing, and put surplus to work. Even a modest reduction in average idle cash or borrowing, applied to real balances and rates, is often the single biggest number in the case.
• Efficiency. Automating position-building, statement reconciliation and payments frees skilled people from manual work. Quantify it as time saved on specific tasks (hours per day building the position, per month on reconciliation), valued at loaded cost.
• Error and fraud reduction. Fewer manual touch-points and enforced payment controls reduce costly errors and fraud exposure. Harder to quantify precisely; base it on your own incident history and the cost of a single serious event avoided.
• Better FX and risk decisions. Seeing exposures clearly and in time supports better hedging and fewer surprises. Value it against the cost of exposures currently managed late or in a spreadsheet.
• Control, audit and resilience. A clean audit trail, enforced segregation of duties, and not depending on one analyst's workbook. Genuinely valuable, legitimately hard to quantify — present it as risk reduction, not a hard saving.

The cost side: total cost of ownership

Cost is more than the licence — understating it is the fastest way to lose credibility later.

• Licence / subscription — the recurring software cost.
• Implementation — vendor/partner fees, and often the larger line: your own people's time, bank onboarding, data migration and testing.
• Run — ongoing support, connectivity, upgrades, admin.
• Internal effort — the team's time during and after the project, which the licence quote never includes.

State cost over the same multi-year horizon as the benefits, so the comparison is fair.

A simple business-case framework

Keep it transparent:

1. Baseline — quantify today's cost and risk (idle cash, borrowing, hours spent, incidents).
2. Benefits — by category, hard numbers, conservative assumptions, tied to the baseline.
3. Cost — total cost of ownership over the horizon.
4. Net benefit & payback — benefits minus cost per year; when it turns positive.
5. Non-financial — control, audit, resilience, as risk reduction.
6. Cost of doing nothing — what the risk and inefficiency compound to if you don't act.

The output isn't a single ROI number; it's a defensible story: here's the problem, here's what it costs us today, here's what fixing it is worth, here's what it costs to fix, and here's why waiting is expensive.

What usually goes wrong

• Overstated soft benefits. Leaning on "better decisions" and "efficiency" without a baseline. One challenged assumption and the whole case wobbles.
• Understated cost. Quoting the licence and forgetting implementation, connectivity, data and internal effort. Credibility evaporates when the real bill lands.
• No baseline. Claiming savings with nothing to measure against. If you can't say what it costs today, you can't prove what you'll save.
• Ignoring the alternative. Not comparing against the cheaper option — your ERP's treasury module, or a better spreadsheet process — so the case looks like advocacy, not analysis. (See TMS vs ERP vs spreadsheets.)

Making it credible to the CFO

Lead with the problem and the baseline, not the solution. Use conservative, traceable numbers and show your assumptions. Build the financial case on hard benefits alone. Present control and resilience as risk reduction. And frame the cost of doing nothing honestly — because the strongest treasury business cases are as much about the risk you're carrying today as the efficiency you'd gain.

Part of the Treasury Management Systems guide. See also when you need a TMS and the implementation guide. The newsletter sends one finance-systems pattern every two weeks.