Before You Buy a TMS, Work Out What You Actually Need

The market should answer a defined question

The first error is often timing. Treasury decides that the current system is no longer good enough and moves quickly to demonstrations. The market then starts providing answers before the organisation has fully defined the question.

Treasury guidance points the other way. AFP's 2024 technology sessions put a thorough gap analysis first: understand the current state, define the target state, then identify systems with the required capability. The ACT/AFP Guide to Treasury Technology similarly places requirements definition ahead of demos, RFP and final selection.

Market research is useful. Formal assessment is different. Treasury should learn from peers and vendors and remain open to capabilities it had not considered. But new ideas should be tested consciously against the business case and target model, not quietly become requirements because they looked impressive in a demonstration. By the time vendors are being scored, the basis of comparison should already exist.

Requirements are not an implementation detail

The case for disciplined requirements is broader than treasury, and that distinction matters. General project research cannot prove that weak TMS requirements cause implementation failure in a fixed percentage of cases. It does show that poorly defined requirements and scope are recurring causes of troubled technology projects.

PMI research involving more than 2,000 practitioners and business analysts found that nearly half of unsuccessful projects failed to meet goals in part because of poor requirements management. Earlier PMI work also identified incomplete requirements, unclear expectations and scope creep as common failure factors.

The treasury inference is straightforward: if the requirement is still moving while the system is being configured, cost and complexity are being introduced at the most expensive point in the journey.

A system cannot repair an undefined operating model

A requirements catalogue is not enough on its own. Treasury also needs to understand where the requirement comes from.

PwC's 2025 Global Treasury Survey found that 94% of respondents operated a dedicated TMS. Yet respondents still reported offline or home-grown tools for short-term forecasting, treasury reporting and financial risk management. Having a TMS does not mean the operating problem has disappeared.

The Current Operating Model makes those gaps visible: what happens inside the TMS, what happens outside it, where data originates, who owns each step, where controls sit and where manual work has accumulated. The Target Operating Model then decides what should change before any vendor is asked to configure it.

What disciplined selection looks like in practice

Chalhoub Group started with a target operating model and four business objectives, then built the technology business case. Its RFP went to five vendors, three were shortlisted, and each demonstration used representative actual data and was scored. The selected TMS was judged against the group's business requirements and budget.

New York University provides an equally useful example of disciplined scope. Before the formal RFP, Treasury knew it needed forecasting, core cash management, automated bank communications and bank-account administration. It also knew what it did not need: heavy debt and investment functionality, FX, payments and a general-ledger interface. Clear requirements narrowed the field to five vendors.

At STX Group, Treasurer Konstantin Khorev described pre-implementation scoping and vendor selection as key mitigants against timeline and budget risk. He recommended an internally driven project, proper fit-gap analysis and vendor demonstrations based on the organisation's own business-case scenarios.

Self-managed does not mean unsupported

For a mid-sized corporate Treasury, the choice is not binary: either run the whole transformation alone or hire a consultancy to own it.

A capable internal team can usually own the business case, scope, current-state evidence, requirement priorities, target operating decisions and vendor scoring. Those are business decisions. Keeping them inside the organisation also keeps the knowledge with the people who will live with the result.

External support can still be valuable where there is a genuine capability or capacity gap: specialist architecture, complex integration, project management bandwidth, independent challenge, contract support or implementation resources.

The important distinction is ownership. Buying targeted expertise is different from outsourcing the thinking. STX's experience is useful here: the project should be internally driven even where external resource is used. That is a credible model for a treasury team that knows its business but does not want to start from a blank sheet of paper.

A sensible position for a mid-sized Treasury

Do not start with the question 'Which TMS should we buy?' Start with the drivers for change and the operating model that must support the business over the next several years.

Define the scope. Capture the current model. Build and prioritise the requirements. Agree the target model. Set the success criteria. Then formally approach the market and make every vendor answer the same question.

This does not guarantee a perfect implementation. No methodology can. It does reduce avoidable ambiguity before the project reaches the point where ambiguity becomes expensive.

The objective is not to select the TMS with the longest feature list. It is to select the solution that best fits the Treasury you are trying to build, with a decision trail that can be explained to Finance, IT, Procurement and the Board.