Why TMS Implementations Really Fail and What Support Has to Do With It

No treasury management system has ever failed a demo. Every platform on the market can show a polished dashboard, a forecast module, and a payments workflow in a 45-minute call. Yet ask treasurers about their last implementation and a different picture emerges: projects that ran past a year, bank connections that never went live, and modules that were paid for but never used.

The gap between the demo and the reality is rarely about features. It’s more about who does the connectivity work, who trains the team, and who picks up the phone in month eleven when a bank changes its file format. In other words, support. Treated as a line item in most evaluations, it is closer to the whole ballgame.

This piece looks at why implementations stall, why adoption is a relationship rather than a transaction, and what to actually ask vendors before you sign.

Where TMS implementations actually stall

A treasury management system (TMS) implementation is the process of connecting a company's banks, configuring its workflows, migrating its data, and training its team on a new platform. On paper it is a project plan. In practice, one phase dominates the risk: bank connectivity.

Legacy implementations put most of that burden on the customer. The company requests connections through its banks, manages host-to-host setup, tests file formats, and coordinates between its own IT team, the bank's implementation team, and the vendor's project manager. Each bank moves at its own pace. Each format has its own quirks. A company with 15 banking relationships is effectively running 15 small integration projects at once, and the slowest one sets the timeline.

The vendor's incentive structure makes it worse. Once the license is sold, a professional-services team billing by the hour has no urgency to compress the schedule. The customer carries the delay; the vendor bills through it.

Owning software is not the same as using it

Here is the statistic that should worry anyone budgeting for treasury technology: 52% of companies with $1 billion to $10 billion in revenue still collect and consolidate cash data manually, according to the PwC 2025 Global Treasury Survey. Many of those companies own systems that were supposed to automate exactly that work.

That is the adoption gap, and it is where weak support does its quietest damage. A platform that is hard to extend goes stale. The team stops adding new accounts because onboarding them is painful. New hires learn workarounds instead of workflows. Within a few years, the expensive system is a system of record for a shrinking slice of the company's cash, and the spreadsheets are back.

Strong support programs prevent that decay by treating go-live as the start of the relationship. Regular check-ins, proactive monitoring of bank connections, training for new team members, and a roadmap conversation that runs both ways — customers shaping what gets built next.

Turnover is the stress test. Treasury teams are small, and the average one loses its platform expert every few years. When that happens, a vendor with a real customer success program re-trains the team and keeps adoption intact. A vendor without one watches usage drop with the departing employee, then hears about it at renewal. Ask any vendor how many of their customers' original project champions are still in seat; the honest answer is "fewer than half," and their support model should be built for exactly that reality.

Support is an architecture decision before it is a staffing decision

It is tempting to evaluate support by counting things: named account managers, response-time SLAs, support tiers. Those matter, but they measure how a vendor handles problems. The deeper question is how many problems the platform generates in the first place, and that is decided by architecture.

A system where every customer runs a separate, customized installation produces support tickets by design. Each version drifts. Each upgrade breaks something specific to one customer. Each bank format change must be patched dozens of times across dozens of installs. The vendor's support organization grows large because it has to, and customers wait in the queue that structure creates.

A platform delivered as one continuously updated version inverts the economics. A bank format change gets fixed once, for everyone, usually before most customers notice. Security patches deploy universally. The support conversation shifts from "please fix what broke" to "help us do more with what works" — a different relationship, produced by a different architecture.

This is why the strongest support references and the strongest product architectures tend to belong to the same vendors. It is not a coincidence of culture. Vendors that carry less structural maintenance burden can spend their customer-facing time on adoption instead of triage.

The questions that separate vendors

Feature checklists make vendors look interchangeable. Support questions do not. Before signing, ask:

• Who owns bank connectivity, end to end? If the answer involves your IT team coordinating with each bank, the timeline risk is yours.

• What happens when a bank changes its API or file format? Someone absorbs that maintenance forever. Find out who, and whether it costs extra.

• Is support staffed by the vendor's own product experts or outsourced? Ask to meet the people, not the org chart.

• What does the customer success program look like in year two? A vendor with nothing to say about year two is selling licenses, not outcomes.

• Can you talk to a customer who went live more than 18 months ago? Recent references tell you about sales. Older ones tell you about support.

The pattern behind every question is the same: find out where the ongoing work lives, because it lives somewhere.

How Trovata approaches the partnership

Trovata removes the largest implementation risk by taking ownership of connectivity itself. Trovata Data is a fully managed service. Trovata builds and maintains the API connections to a company's banks, normalizes the data, and keeps the pipes working as banks evolve. The customer's team spends its time on treasury, not integration testing. On top of that foundation, Trovata TMS delivers cash management, forecasting, and payments without the infrastructure burden of a legacy deployment.

Proof point: Park Place Technologies

Park Place Technologies spent eight months attempting a legacy TMS implementation that never reached go-live. The team walked away, moved to Trovata, and connected 100 accounts across 15 banks and 25 countries in three months — at 77% lower annual cost than the abandoned project. Before that, treasury had been working from monthly ERP balances; afterward, it had current data across its entire banking footprint. The details are in the Park Place Technologies case study.

Where to go from here

Treasury software is a decade-long relationship purchased in a 90-day evaluation. The vendors that deserve the decade are the ones whose support model survives scrutiny who own the hard parts, staff the relationship, and keep earning the renewal.

If you are evaluating platforms, or living with one that stalled, it is worth seeing what a managed-connectivity model changes. Request a demo and ask the support questions above. The answers are the evaluation.

FAQs

Why do TMS implementations fail?

TMS implementations most often stall on bank connectivity, because legacy models push the integration work onto the customer, who ends up coordinating separate projects with every bank while the slowest one sets the timeline. Vendor incentives compound the delay when professional services bill by the hour.

How long does a TMS implementation take?

Implementation time depends on scope, meaning the number of banks, integrations, and workflows involved, so credible vendors talk about scope rather than quoting a universal number. As a historical reference point, Park Place Technologies connected 100 accounts across 15 banks and 25 countries with Trovata in three months after abandoning an eight-month legacy attempt.

What is a managed connectivity model?

A managed connectivity model means the vendor builds and maintains the API connections to a company's banks, normalizes the data, and absorbs ongoing maintenance as banks change formats. The customer's team works on treasury instead of integration testing.

What should I ask a TMS vendor about support before buying?

Ask who owns bank connectivity end to end, who absorbs bank format changes and at what cost, whether support is staffed in-house, and what the customer success program looks like in year two. Then ask to speak with a customer who went live more than 18 months ago — older references reveal support quality, recent ones reveal sales quality.

What happens when a bank changes its file format or API?

Someone must absorb that maintenance for the life of the system, so the question is who — the customer's IT team, a billable services engagement, or the vendor as part of a managed service. On a managed, single-version platform the fix is made once and reaches every customer at the same time.