100-Day TMS Implementation: What Happens Before, During, and After Go-Live

The decision for a treasury management system has been made, or is about to be. But it is exactly at this point that the biggest worry often appears: how demanding will the implementation be? How long will it take? What does it mean for our own team, and what happens if something goes wrong?

These questions are valid. Many treasury teams have heard stories of software projects that dragged on for one or two years. The good news: a modern, cloud-based implementation works differently. With a clear structure, a treasury management system can be productive in around 100 days.

This guide takes the uncertainty out of the decision. We show, step by step:

• what happens before the implementation,

• how the rollout unfolds in the first 100 days,

• what follows after go-live,

• what role your team plays and what the provider does,

• how to avoid typical risks.

Why 100 Days Is a Realistic Timeframe

In the past, TMS projects were notorious for long timelines. Local installations, in-house servers, and elaborate customizations often led to projects of a year or more. Cloud-based solutions have changed this.

A realistic timeframe of around 100 days is possible today for several reasons:

• No infrastructure of your own. No servers need to be procured or set up.

• Standardized processes. Proven workflows for rollout and data migration shorten the project time.

• Pre-built interfaces. Connections to banks and ERP systems are usually prepared.

• A phased approach. Instead of everything at once, the rollout happens in clear phases.

  
  

Setting the right expectation matters: 100 days does not mean that every single function for every subsidiary is live on day one hundred. It means the core functions, transparency over accounts, liquidity, and payment transactions, are running productively. Further functions and entities are added gradually afterward.

The Overview: Three Phases, 100 Days

The rollout can be divided into clear phases. The following table gives an overview; we explain the individual steps in detail afterward.

Phase 1: Before the Rollout (Before Day 1)

The success of a project is often decided before the first configuration is made. Clean preparation is the most important foundation. This phase is about creating clarity.

Define Goals and Scope

Before starting, the goals should be clear. Helpful questions:

• Which problems should the system solve specifically, such as missing transparency or manual effort?

• Which functions are indispensable at the start, and which can follow later?

• Which subsidiaries, banks, and accounts are connected in which order?

  
  

A clearly defined initial scope is decisive. Those who try to cover everything from day one risk delays. Those who start with the most important functions are productive faster.

Set Up the Project Team

A TMS project is teamwork. Typically involved are:

• Project leads in treasury who know the requirements,

• IT contacts for connecting systems,

• Decision-makers who release resources and set priorities,

• the provider's implementation team, which steers the process.

  
  

Clear responsibilities prevent friction. Right from the start, it should be settled who takes on which role in the project.

Prepare Requirements and Data

The better the preparation, the smoother the start. It makes sense to compile early:

• an overview of all banks, accounts, and bank connections,

• the relevant ERP and source systems,

• existing processes, such as approvals in payment transactions,

• existing data to be migrated.

  
  

At the end of this phase, there is a shared project plan with goals, scope, responsibilities, and a timeframe. This is the foundation for the next 100 days.

Phase 2: Setup and Configuration (Day 1 to approx. 30)

With the official project start, setup begins. In the first weeks, the system is set up at a basic level and adapted to the company's structure.

Typical steps in this phase:

• Base setup of the system based on the defined requirements,

• Creation of the organizational structure, meaning entities, accounts, and hierarchies,

• Setup of roles and permissions via central permission management,

• First connection to selected banks and source systems,

• Alignment of processes, such as approvals and workflows.

  
  

In this phase, the collaboration between your team and the implementation team is closest. Regular check-ins, often in weekly meetings, keep the project on track and clarify open questions early.

Phase 3: Integration and Data Migration (Day 30 to approx. 70)

The heart of the rollout is integration. Now the data sources are connected and the system is filled with life. This phase largely determines the later data quality.

Bank Connectivity and ERP Integration

The connection to banks and upstream systems creates the central data foundation.

This includes:

• the bank connectivity via established standards in banking,

• the integration of ERP and accounting systems,

• the consolidation of accounts and payment data on one platform.

  
  

This creates the central, consolidated view that modern treasury management makes possible in the first place.

Data Migration and Configuration

In parallel, existing data is taken over and the processes are fully configured:

• migration of relevant master and transaction data,

• configuration of workflows, approvals, and rules,

• setup of reports and dashboards,

• first plausibility checks of the data.

Data quality in particular deserves special attention here. Clean, consistent data is the prerequisite for reliable liquidity planning and correct analyses. It pays to be thorough in this phase.

Phase 4: Testing and Go-Live (Day 70 to approx. 100)

Before the system goes live, it is tested thoroughly. This phase ensures that everything works as expected at go-live.

Test and Verify

In structured tests, the system is put through its paces:

• checking whether accounts, balances, and payments are mapped correctly,

• testing the workflows and approval processes,

• reviewing the reports and dashboards,

• checking permissions and access.

  
  

Anomalies are resolved before the system goes live. This step builds trust: the team sees that the numbers are correct.

Train the Team

A system is only as good as its use. That is why user training is a fixed part of this phase:

• a practical introduction to daily workflows,

• training on the most important functions and workflows,

• contacts and support for the start.

  
  

Go-Live

The productive start is ideally controlled and well prepared. Instead of a risky big bang, a phased start is often advisable: first the core functions and most important entities, then the expansion. This keeps the risk low and lets the team gain confidence.

Phase 5: After Go-Live (From Day 100)

With go-live, the project is not finished but transitions into ongoing operation. This is where the investment pays off, and the optimization phase begins.

Typical activities after go-live:

• Fine-tuning of processes and reports based on the first practical experience,

• Connecting further entities, banks, or subsidiaries,

• Expanding additional functions deliberately deferred at the start,

• Ongoing support and regular updates from the provider.

  
  

With a cloud-based solution in particular, new functions are added continuously through automatic updates, without elaborate in-house upgrade projects. The system grows with the company.

Typical Worries and How to Avoid Risks

A rollout comes with expectations and worries. The most common ones can be addressed directly:

• "It ties up too many resources." With clear responsibilities and a defined initial scope, the effort for your own team stays manageable. The provider steers the process.

• "Our data isn't clean enough." The integration phase is exactly the time to consolidate and clean data. The system creates structure here.

• "The migration is too risky." A phased go-live instead of a big bang keeps the risk low. Core functions start first, the rest follows in a controlled way.

• "The team won't cope with the new system." Practical training and fixed contacts ensure that users work confidently from day one.

• "It will take much longer anyway." A realistic project plan with clear phases and regular check-ins keeps the project on schedule.

  
  

The common denominator: clarity, structure, and close collaboration take the uncertainty out of the project.

The Success Factors at a Glance

For a rollout to succeed in around 100 days, a few factors matter most:

• a clearly defined initial scope instead of "everything at once",

• a committed project team with clear roles,

• good data preparation before the start,

• close alignment between company and provider,

• a phased go-live instead of a risky complete switch,

• training and support for the users.

  
  

Those who take these points to heart turn a supposedly risky major project into a plannable, manageable process.

Conclusion: The Rollout Is More Manageable Than Many Think

The fear of a long, risky rollout keeps some companies from taking the step to a modern treasury management system. Yet this very fear is usually unfounded. With a structured approach, a system is productive in around 100 days:

• Preparation: clarify goals, team, and requirements.

• Setup: set up the system and create the first connections.

• Integration: connect banks, ERP, and data.

• Testing and go-live: verify, train, start in a controlled way.

• After go-live: optimize, expand, grow along.

  
  

The decisive factor is a partner who guides the process in a structured way and provides the necessary transparency. Financial Navigator centralizes accounts, banks, and financial data on one platform and thus creates the basis for a fast, secure rollout and reliable treasury management.

Would you like to know what a rollout would concretely look like for your company? Request a demo now.

FAQ: TMS Implementation