Why TMS Implementations Fail (and How to De-Risk Yours)

TMS implementations rarely fail because of the software. They fail because of the treasury change around it: the project is run as an IT install instead of a treasury programme, bank connectivity is underestimated, dirty master data is migrated as-is, forecasting expectations outrun the data, and — the pattern behind all of it — tasks are owned but the outcome is not.

Having sat inside a few of these, the failure modes are remarkably consistent, and none of them are really about the product you picked. Here's what actually goes wrong, and how to de-risk your programme before it starts.

It's almost never the software

Modern treasury systems are mature. When an implementation goes badly, the post-mortem almost never concludes "the software couldn't do it." It concludes some version of "we configured it to match the demo, not the business," or "we ran out of time on connectivity," or "no one had decided who owned the number." The technology is the part most likely to work. The organization around it is the risk.

"

A TMS doesn't fix your treasury process — it makes whatever process you have faster and more visible, including the broken parts. Which is why the process questions have to be answered first.

The failure patterns

1. Run as an IT project, not a treasury change programme

The single most common root cause. IT owns the plan, the vendor drives configuration, and the people who actually understand the cash flows are consulted occasionally rather than embedded. The system ends up configured to pass the demo, not to run month-end. Treasury has to own this programme — not attend it.

2. Bank connectivity is underestimated

The software is "live" in weeks. Getting every bank onboarded, the right message formats agreed (statements and payments), and every flow tested end to end takes far longer — and depends on banks and third parties you don't control. Connectivity, not configuration, is almost always the critical path. Teams discover this three months in, when it's already the thing holding go-live.

3. The static data is dirty

Bank accounts, counterparties, cost centres, signatories and payment details get migrated as-is, on the assumption they'll be "cleaned later." They aren't. Then every downstream problem — a payment to the wrong account, a position that won't reconcile — traces back to a master-data record no one owned. Data quality is not a workstream you can defer.

4. Forecasting expectations outrun the data

Leadership expects an accurate cash forecast on day one. But a forecast is only as good as the source data and the discipline feeding it, and that maturity is built over quarters, not configured in a sprint. Promising day-one accuracy sets the programme up to be judged a failure on the one thing that was never realistic yet.

5. No one owns the outcome

Every task has an owner. The outcome — "treasury sees group cash without a spreadsheet, with controls that pass audit" — is owned by a steering committee, which is to say no one. Work in the seams between tasks (integration, edge cases, the definition of done) falls through, and the slip is invisible on a status report where every task is green. This is the pattern behind the other four.

6. Scope creep and matching the demo

Without a prioritized, business-anchored requirements list, the implementation drifts toward whatever the vendor showed and whatever each stakeholder asks for in the moment. The result is a system that does many things adequately and the two things you actually needed poorly.

7. Testing gets squeezed

Because connectivity and data ran long, testing — especially proper user acceptance testing with real scenarios — gets compressed into the window before a fixed go-live. Defects surface in production instead, during hypercare, when they're most expensive and most visible.

The pattern behind the patterns

Read those back and the common thread is not technical. It's that the people who understand the cash flows weren't close enough to the decisions, and no one owned the outcome end to end. Every other failure mode is a symptom of those two. (This is exactly the unclear-ownership problem that quietly sinks any complex finance-systems delivery, not just treasury.)

Failure-prevention matrix

Each failure mode has a phase where it takes root and a leading indicator you can catch it by — long before it shows up as a slipped go-live. This is the table I'd pin to the programme wall:

Read the "leading indicator" column on its own: every one of these is visible weeks before it becomes a crisis, if someone's looking for it.

How to de-risk your programme

• Run it as a treasury change programme. Treasury owns it; embed the people who run the cash, don't just consult them.
• Start bank connectivity first. Treat it as the critical path it is, in parallel with configuration, not after.
• Make data quality a real workstream. Clean master data before migration; own it; don't defer.
• Set honest forecasting expectations. Day-one visibility, not day-one accuracy; accuracy is earned over quarters.
• Name one outcome owner. Not a committee — a person accountable for "treasury sees group cash, with controls that pass audit."
• Anchor scope to prioritized requirements. Must/should/could, tied to real needs; resist demo-driven drift.
• Protect testing time. Ring-fence UAT with real scenarios; don't let it be the shock absorber for earlier slips.

What I'd do differently

If I could change one thing on most of these programmes, it wouldn't be the software or even the plan — it would be who's in the room and who owns the outcome. Put treasury in charge, name a single accountable owner, start connectivity and data on day one, and be honest about what a forecast can do in year one. Do that and the implementation stops being a gamble on the vendor and starts being a change you're actually running.

Part of the Treasury Management Systems guide. See also when you need a TMS and the requirements checklist. The newsletter sends one finance-systems pattern, product decision or build lesson every two weeks.