Selecting a Treasury Management System

Define the decision before approaching the market

A selection begins with the problem, not the product. It must also establish whether a treasury management system (TMS) is justified. Some organisations can reach an effective steady state without one. Buying a system should not become the objective simply because a selection project has started.

Map the Current Operating Model (COM) before designing the future one. Document how work is actually performed—not only what the policy says. Spreadsheet bridges, informal workarounds, undocumented approvals, system dependencies and control points form the factual baseline for scope and requirements.

Scope should make the complexity visible: legal entities, countries, currencies, banks, payment types, core finance systems, connections, financial instruments, accounting, security and controls. It should also state what remains outside the TMS. For example, collection instructions may remain owned by the core finance system while the TMS acts as the controlled gateway to the bank.

Write requirements that can be tested

A requirement should describe an outcome or control in language that can be demonstrated. Avoid broad statements such as ‘supports forecasting’ or ‘uses AI’. Ask how data is sourced, how the workflow operates, which exceptions are controlled and what evidence will prove the answer.

Scope defines the boundary. Requirements define what must be delivered. Do not blur them, and do not commit to a credible project timeline before the scope and requirements are sufficiently complete.

Priority also needs discipline. Essential, Important, Desirable, Not Required and Not Sure are more useful than declaring everything mandatory. ‘Not Sure’ is not indecision; it identifies where discovery or design work is still required.

• Separate scope characteristics from functional requirements.
• Keep security, resilience, service and implementation requirements visible.
• Treat current payment-format and data obligations as explicit requirements.
• Record the evidence expected for every material claim.

Use the request for proposal to collect comparable evidence

The RFP should give vendors a consistent response structure and make gaps obvious. It should cover the product, technology, implementation, support, security, pricing and checks on the vendor organisation. Free-form marketing responses are difficult to compare and easy to over-score.

Demonstrations should follow client scenarios and data, not the vendor’s standard script. A credible answer shows the complete process, who performs each step, the controls, exceptions, audit trail and impact on other systems. If a material requirement cannot be demonstrated or evidenced, it should remain open.

Professional guidance recommends specific questions, weighted requirements and a clear record of vendor commitments. Treasury Management International makes the same point more directly: use real business scenarios, assess implementation capability and do not optimise the decision for feature count.

Treat implementation as part of selection

The proposed product is only part of the answer. Assess the delivery team, implementation method, data migration, connections, testing, training, support and the client resources required. A capable product with an unconvincing delivery plan remains a delivery risk.

Treat data cleansing as a defined workstream with an owner, milestones and measurable completion criteria. A new system does not repair weak data. It embeds the inconsistency into automated workflows and reporting.

The RFP response, demonstration evidence and agreed clarifications should follow into the statement of work, implementation plan and contract. Otherwise, an apparently successful selection can lose its evidence as soon as implementation begins.

Academic studies of Enterprise Resource Planning (ERP) systems are not studies of treasury management systems. TRC uses them by inference only where the issue is common to complex enterprise software: organisational fit, supplier service, project governance, data and implementation capability.

Govern the project before contract signature

Ownership cannot be left until implementation. The sponsor owns strategic intent, funding and key decisions. The project manager owns delivery. Treasury owns scope, requirements, the operating model and control integrity. Vendors, banks and consultants support delivery; they do not own the outcome.

Decision rights must be explicit. Steering meetings should be decision forums, not reporting ceremonies. Delayed decisions, softened status reporting and uncontrolled scope changes drain time and budget long before a project is described as failing.

Use a proof of concept where it provides useful evidence. Test the process, data, controls and usability before scaling. Configuration should follow validated process design. The system enables the operating model; it does not define it.

• Give named decision-makers sufficient authority.
• Keep risks, assumptions, issues and dependencies live and owned.
• Match any expansion in scope with authority, resources and budget.
• Prove capability before wider rollout.

Do not hide risk inside one score

Product capability, client fit, vendor risk, implementation confidence and cost are different conclusions. Combining them too early can allow a strong feature score to conceal weak delivery evidence or a critical control gap.

Use pass/fail gates for genuinely essential requirements. Weight the remaining requirements to reflect the client’s priorities. Record evidence confidence alongside the score. The final recommendation should explain not only which option leads, but why, under what conditions and with which risks still to be resolved.

The TRC selection method combines treasury requirements, product evidence, delivery risk, cost and decision governance. External research supports the method. It does not replace independent judgement.