How the Right TMS Can Protect Corporates from Financial Icebergs

Christof Nelischer and Dean Ibbs share more than a decade of working on TMS selection, implementation, and optimisation projects from different perspectives: treasurer and vendor respectively. Since their first collaboration 10 years ago, they have continued to compare notes on the recurring challenges companies face when evaluating, selecting, and executing treasury technology. Here, they offer a collection of observations, lessons learnt, and explore why TMS selection is fundamentally an organisational, rather than technological, challenge.  They also explain how stakeholder alignment, governance, and disciplined decision-making create the foundations for a successful implementation.

Imagine young Frederick Fleet, lookout of the luxury passenger liner RMS Titanic, being offered night‑vision binoculars on that fateful night of April 14 1912. The binoculars are optional, expensive, and not required under maritime law. The ship already has everything it must have: lighting, signalling equipment, trained crew, manuals, and contingency procedures. All compliant. All tested. All familiar. It has always been this way.

In the short space of time between Fleet becoming aware of the iceberg and the ship colliding with it, everything appears normal. The Titanic is on course for New York and on schedule. Engines humming, passengers asleep, crew at work. Yet, had Fleet been equipped with a pair of night‑vision binoculars (in fact, he didn’t even have ordinary binoculars), the iceberg would have been visible far earlier – early enough to steer clear with ease and avoid the infamous sinking that resulted in the deaths of some 1,500 people.

A TMS sits in the same category.

The ERP is embedded within the business's operating model. Its value is rarely questioned because the organisation cannot function without it. It has become part of the natural landscape of the Finance department and, given its scale, has taken on a life of its own.

The TMS is discretionary –  at least in theory.

Seeing the iceberg daily

Ironically, companies often spend more time justifying the business case for a TMS than they do for an ERP, despite the fact that both are designed to improve visibility, control and decision-making.

Yet the value of a TMS extends beyond transaction processing. It provides early warning and rapid interpretation of risk, enabling Treasury to identify liquidity pressures, funding requirements, counterparty exposures, and operational issues before they become urgent issues .

The purpose of a TMS is not simply to manage transactions. It is to help organisations spot the financial icebergs sooner. To a treasurer, a TMS is simply good business practice. Treasury sees the iceberg every day. The rest of the organisation rarely does.

Across the wider business, a TMS is often viewed as a non-revenue-generating discretionary cost coupled with the prospect of a long, complex implementation. Unlike an ERP, its value is rarely self-evident beyond Treasury. And that is the heart of the matter. Before a selection process begins, before a vendor is evaluated and before an implementation is planned, many businesses have already underestimated the role a TMS can play. That perception influences how the project is viewed long before any technology decision is made. Perception:

Why the TMS Is treated differently

Someone has to champion the TMS, and that responsibility naturally falls to the treasurer.

Now imagine if the same were true for the ERP. The ERP is vast, complex, and all encompassing –  yet paradoxically perceived as being owned by nobody.

It sits at the heart of Finance, and because everyone depends on it, everyone feels a degree of collective responsibility. We are in this together; we make the ERP work because we have no alternative.

Formally, the Group CFO is accountable, but only at a distance. By contrast, the TMS is viewed as Treasury’s personal project rather than a corporate one. Outside the Treasury team, there is little sense of ownership or shared obligation.

When the ERP struggles, the organisation rallies. When the TMS falters, all eyes turn to Treasury.

Nelischer has observed this dynamic repeatedly during TMS projects. “ERP projects are typically viewed as business-wide initiatives from day one. TMS projects often start as Treasury initiatives and become business initiatives only if the treasurer is successful in building support across the organisation.”

That difference in perception has profound implications for how projects are funded, governed, and ultimately judged.

Yet both systems ultimately seek to achieve the same outcome: replacing manual, transaction-based activity with integrated, process-driven, and automated ways of working. STP is the ambition for both –  only in the fast-moving world of financial markets, the need is sharper and the consequences of delay more immediate.

This difference in perceived ownership shapes everything that follows, from stakeholder engagement and vendor selection through to implementation governance and, ultimately, project success.

Selection: Where alignment matters most

Most difficulties encountered during TMS selection arise not from technology but from the need to align stakeholders with different priorities, levels of familiarity, and measures of success.

A strong TMS selection process brings together four core stakeholders:

• Treasury
• Controllers
• IT
• Procurement

The process typically reports into the CFO –  a role that often has limited hands on treasury experience –  making disciplined governance essential from the outset.

A well run steering group can become the project’s most effective decision making and communication forum. Without clear governance, however, it can just as easily drift into ‘paralysis through analysis’ or become a stage for interfunctional friction.

In Nelischer's experience, the greatest challenge is rarely the software itself. “Treasury, Controllers, IT, and Procurement all approach the project with legitimate but different objectives. The challenge is not deciding what the software can do. It is deciding which outcomes matter most to the organisation.”

These contrasting perspectives can be summarised simply:

 While the concerns from a Treasury perspective have been considered above, how do these other functions relate to a TMS?

Controllers: Supportive – but at a distance

Controllers are typically less familiar with TMSs than treasury practitioners. They want to understand the benefits and mechanics, but several factors can limit their engagement:

• The TMS is viewed as discretionary.
• It is championed by another function.
• Treasury technology sits outside their day-to-day responsibilities.
• Competing priorities often limit the time they can devote to the process.

Their instinct is often to favour large, familiar suppliers, particularly the treasury module of an ERP platform they already trust and understand.

A good controller recognises the value a TMS can bring and is broadly supportive, even if they still view it as treasury's initiative rather than a shared organisational priority.

The best controllers go further. They take a genuine interest in how a TMS works, understand the wider benefits, and become proactive, constructive partners. They develop a grounding in risk management and financial markets, gaining a greater appreciation for treasury's operational challenges and strategic importance.

This curiosity often serves them well. These are the controllers who later become CFOs and excel in the role.

IT: Stability first, familiarity second

IT’s primary concern is the stability and integrity of the overall infrastructure. Unsurprisingly, they gravitate towards:

• Large, established vendors.
• Existing ERP providers.
• Solutions that appear easier to integrate.

In many organisations, IT naturally favours the ERP treasury module, often reinforced by CFOs who trust the ERP vendor they selected and now know well. From an IT perspective, extending an existing platform can appear lower risk than introducing a specialist provider.

For some companies, particularly those with relatively straightforward treasury requirements and a strong commitment to ERP standardisation, the ERP treasury module may be the right choice. The key is understanding the trade-offs rather than assuming one approach is universally superior.

Modern APIs, middleware platforms, and cloud-native architectures have reduced many of the integration challenges that historically favoured ERP-centric approaches.

The assumption that an ERP treasury module will automatically be quicker or easier to implement is not always borne out in practice. If that were consistently true, the specialist TMS market would not have evolved into the mature market that exists today. Instead, vendors continue to thrive because many organisations require treasury-specific functionality, flexibility, and expertise beyond what ERP treasury modules typically provide.

A higher price tag is sometimes assumed to indicate superior capability, when it may simply reflect the economics of platform bundling rather than functional strength.

The strongest IT stakeholders recognise that their role is not to choose the software, but to help the business understand the trade-offs. They bring valuable expertise in security, architecture, and integration while remaining open to the possibility that the best treasury solution may not be the most familiar one.

Procurement: Essential, but only at the right time

Procurement excels at sourcing physical goods and well-defined services –   but a TMS is neither. Selecting a TMS is more akin to choosing auditors, legal advisers, or tax counsel.

In these cases, professional judgment is paramount. Is the vendor fit for purpose? Is there a cultural match? Do we trust their ability to deliver and support us over the long term?

Procurement brings valuable expertise in commercial negotiations, contracting, vendor due diligence, and governance. However, they are often at their most effective once Treasury has narrowed the field and identified a preferred direction.

Nelischer recalls one selection process where the line between Treasury and Procurement became blurred. “Procurement became heavily involved before treasury had aligned on its requirements and preferred vendors. What began as a focused evaluation evolved into a lengthy exercise involving multiple scoring matrices, hundreds of requirements, and several additional rounds of vendor assessments. Months were added to the timeline, yet the final recommendation was ultimately the same solution Treasury had identified much earlier in the process.”

When Procurement enters the process too early, the selection can quickly become crowded, with Procurement, IT, and Treasury all believing they are driving the decision. Treasury should remain accountable for identifying the preferred solution and driving the recommendation, while Procurement provides the commercial and contractual rigour needed to support the final decision.

What good TMS selection looks like

Successful TMS selections are not defined by the length of the process, but by the quality of the decisions it enables. One of the most common mistakes organisations make is assuming that greater detail will automatically lead to a better outcome. In reality, the strongest selections are characterised by clarity, prioritisation, and disciplined decision-making.

Some practical principles include:

Do

• Define the business objectives before evaluating software          
• Prioritise requirements 
• Focus demonstrations on real business scenarios
• Assess implementation capability as well as software functionality
• Establish clear decision-making authority
• Distinguish between ‘must-haves’ and ‘nice-to-haves’      

Don't

• Treat every requirement as equally important
• Allow every stakeholder a veto
• Use generic template RFPs
• Optimise for feature count
• Assume demonstrations reflect implementation reality

Drawing on his experience of advising firms through TMS selection processes, Ibbs notes: “Overly generic or excessively detailed RFPs rarely improve the quality of a selection. More often, they make it harder to distinguish between vendors and distract attention from the requirements that genuinely matter.”

Vendors can usually identify within minutes whether an RFP reflects a well-structured selection process or a document assembled by committee. The latter often contains hundreds of requirements with little indication of what actually matters to the client.

Paralysis through analysis

The challenge is that these differing stakeholder perspectives do not simply shape the selection process. They can begin to dominate it. Because a TMS is discretionary and unfamiliar to many stakeholders, the selection process is uniquely vulnerable to behaviours that slow progress and dilute decision making. Typical symptoms include:

• Endless questions.
• Demands for bespoke or hypothetical solutions.
• Pursuit of perfection.
• Fear of making the wrong decision.
• Reluctance to endorse something not fully understood.

Underneath these behaviours sits a deeper, often unspoken dynamic: a general unease about Treasury itself.

For many stakeholders, Treasury remains one of the least understood functions in the organisation.

For many outside the function, Treasury feels like a high stakes black box. They know large amounts of cash move through the department  every day and understand the consequences of mistakes, but lack the context and specialist judgment that treasury professionals develop over time. As a result, they often imagine that a single wrong mouse click could trigger disaster. This anxiety is rarely voiced directly. Instead, it manifests as calls for more detail, more documentation, more scenarios, and more assurance. What looks like thoroughness is often fear in disguise.

In this environment, perfection quickly becomes the enemy of good. Decisions slow. Momentum fades. Confidence erodes.

One of the earliest warning signs is when decision-making begins to slow. Questions that should clarify the path forward instead create new avenues for analysis. Requirements expand, additional stakeholders become involved, and the process gradually shifts from evaluating options to avoiding decisions.

When too many stakeholders hold effective veto rights, the dynamic becomes that of a large committee: compromise dominates, ambition shrinks, and the outcome is often the lowest common denominator choice.

Everyone's third-best option becomes the ‘safe’ selection.

A TMS selection is not a hunt for a unicorn. It is a strategic decision that requires clarity, prioritisation, and informed judgment.

The goal is not to find the perfect solution. The goal is to identify the right solution and have the confidence to move forward.

The market is changing

Historically, the TMS market has had some of the highest barriers to entry in enterprise software. A relatively small number of established vendors dominated the market for decades because entering the space required significant investment in bank connectivity, payments infrastructure, market data, risk management functionality, accounting capabilities, regulatory compliance, and implementation expertise.

The market is now becoming more accessible as cloud-native technology, banking APIs, modern integration platforms, and AI reduce the cost and complexity of building treasury software and connecting to banks.

This has enabled newer vendors such as Palm, Nilus, Embat, and Bond to launch focused cash management and treasury automation solutions with faster implementations and a more modern user experience than traditional enterprise TMS platforms.

Having worked with both established providers and newer market entrants, Ibbs believes the market looks very different from the one that existed even a few years ago,

“The most significant change in the TMS market is not simply the emergence of new vendors, but the fact that companies now have genuine choice. The challenge for buyers is no longer finding a credible solution. It is identifying the solution, implementation approach, and operating model that best fit the organisation.”

For buyers, this means there are now more options than ever before. The challenge is no longer simply selecting a vendor. It is selecting the vendor and implementation approach that best aligns with the organisation’s objectives, complexity, and future ambitions.

In search of visibility, control and insight

The irony is that most companies only fully appreciate the value of a TMS after it has been implemented.

Like the night-vision binoculars on the Titanic, the benefit is not in owning another piece of technology. The benefit is seeing risks, opportunities, and decisions sooner than would otherwise be possible. Visibility, control and insight are easy to underestimate until they are absent.

Yet many of the decisions that determine the success of a TMS are made long before implementation begins. They are shaped by how the project is perceived, how stakeholders are aligned, how governance is established and how clearly the organisation defines what it is trying to achieve.

Successful TMS selections are not characterised by the longest RFPs, the most exhaustive demonstrations, or the largest steering committees. They are characterised by clarity, prioritisation and the confidence to make informed decisions.

A TMS may be discretionary on paper. In practice, it has become essential infrastructure for organisations seeking to manage liquidity, risk, and financial operations effectively.

Selecting the right technology is only the beginning. The decisions made during selection create the conditions for everything that follows.

The challenge is not deciding whether a TMS is valuable. The challenge is recognising its value before the iceberg appears.

In the second article in this series, we explore why implementation – not software selection – is the stage that ultimately determines whether a TMS delivers on its promise.