TMS Implementation: What to Expect at Each Stage

Most treasury management system implementations follow a recognisable pattern — the same six stages, in roughly the same order, with the same points of difficulty. What surprises organisations is rarely the existence of that pattern. It is where the complexity actually sits within it. The stages that look straightforward in a vendor presentation are often the ones that consume the most time and resource. The stages that look complex are sometimes the smoothest. Understanding the reality before a programme starts is one of the most useful things a treasury team can do.

Stage 1: Requirements and Scoping

The requirements phase is where the scope of the implementation is defined: which modules, which entities, which bank relationships, which payment types, which reporting outputs. Getting this right at the start determines whether the rest of the programme is manageable. The most common failure at this stage is scope that is either too vague — leaving configuration decisions to be made under pressure later — or too ambitious, committing to functionality that won't be needed at go-live but will consume implementation resource throughout.

A well-run requirements phase produces a configuration workbook that the implementation team can work from directly. It should take two to four weeks for a mid-size implementation and should involve the people who will actually use the system, not just their managers. Typical duration: two to four weeks.

Stage 2: System Configuration

Configuration is the core technical work of a TMS implementation: building the system to match the organisation's treasury operations. This covers entity structure, counterparty setup, instrument types, workflow rules, approval hierarchies, and reporting templates. For a complex treasury — multiple legal entities, multiple currencies, a range of financial instruments — this is detailed, time-consuming work.

Configuration is also where the quality of the implementation team shows most clearly. Experienced consultants configure to the organisation's actual workflows. Less experienced ones configure to default templates and adjust later, which creates technical debt that surfaces during UAT. Typical duration: six to twelve weeks depending on complexity.

Stage 3: Integration and Bank Connectivity

Integration — connecting the TMS to the organisation's ERP, its banking partners, and its payment infrastructure — is consistently the most underestimated stage of a TMS implementation. It is also where programmes most often fall behind schedule.

Bank connectivity alone involves onboarding each banking partner to the TMS's connectivity framework, configuring the relevant message types, testing statement delivery and payment initiation, and resolving the inevitable bank-specific issues that arise during testing. A mid-size organisation with ten banking relationships might expect this process to take eight to twelve weeks, not the two to four that often appears in project plans. ERP integration adds further complexity, particularly where the ERP is also being upgraded or migrated concurrently. Typical duration: four to twelve weeks.

Stage 4: Data Migration

Data migration — moving deal data, counterparty records, position history, and static data from the legacy system into the new TMS — typically runs in parallel with configuration and integration. The volume of work depends on the complexity of the existing data and its quality. Legacy treasury systems that have been in place for a decade often contain data that has never been formally validated; cleaning it before migration takes time that is rarely fully budgeted for.

The critical discipline at this stage is defining what needs to be migrated and what can be left in the legacy system for reference purposes. Migrating everything is almost never the right answer. Typical duration: four to eight weeks, running alongside configuration.

Stage 5: User Acceptance Testing

UAT is where more TMS implementations run into serious trouble than at any other stage. The reasons are consistent: insufficient test scenarios, the wrong people doing the testing, time pressure that leads to defects being deferred rather than resolved, and inadequate defect management that makes it impossible to track what has been fixed and what remains open.

Properly designed UAT covers end-to-end business processes — a money market deal from trade entry through to settlement and accounting — not just individual system functions. It should be run by the people who will use the system in production, with clearly defined pass and fail criteria and a formal sign-off process. Organisations that compress UAT to meet a go-live date invariably pay for it in hypercare. Typical duration: four to eight weeks.

Stage 6: Go-Live and Hypercare

Go-live is a milestone, not a completion. The hypercare period — typically four to eight weeks following go-live — is when the system is in production but the implementation team remains available to resolve issues, support the treasury team through their first end-of-month and end-of-quarter processes, and address configuration adjustments that only surface under real operating conditions.

The most common mistake at go-live is withdrawing senior implementation resource too quickly. Issues that appear minor in the first week frequently become significant if left unaddressed into the first month-end close. Retaining experienced resource through hypercare is not a cost; it is risk management. Typical duration: four to eight weeks post go-live.

Where RG Treasury Fits

RG Treasury provides senior treasury implementation consultants for every stage of this process — from requirements through to post-go-live optimisation. Our consultants have delivered TMS programmes of varying complexity and know where the difficulty actually sits. If your programme is in progress and running into difficulty, we also provide project rescue resource at short notice. Contact Sales@rgtreasury.com to discuss your implementation.