TMS Implementation Timeline and Phases

A TMS implementation moves through a predictable set of phases — initiation and design, configuration, bank connectivity, data migration, testing, training, cutover and hypercare — but how long it takes is driven by your scope, not by the software. A focused single-entity cash implementation is typically a matter of months; a multi-entity, multi-bank, multi-module programme runs considerably longer. The difference is almost never the configuration. It's the banks, the data and the speed at which your organisation decides things.

This article zooms in on the timeline and the phases specifically — what happens in what order, and what genuinely moves the end date. If you want the full end-to-end programme picture — the deliverables of each phase, the team, the go-live checklist — start with the implementation guide; this is the companion that focuses on time. If you're still deciding what a TMS is or whether you need one, the overview sits under all of it.

The phases, in order

Every implementation I've worked on has moved through roughly the same arc, whatever the vendor calls the stages:

1. Initiation and design — mobilise the team, confirm scope and requirements, and design the target processes and configuration decisions before anyone touches the system.
2. Configuration and build — set the system up to the design: entities, accounts, workflows, limits, accounting rules and reports.
3. Bank connectivity onboarding — get statements coming in and payments going out, tested end to end, with every bank in scope.
4. Data migration — clean, load and reconcile master data and open items.
5. Testing — system integration testing (SIT) to prove the plumbing works, then user acceptance testing (UAT) to prove it works for the people who'll run it.
6. Training — get the treasury team fluent on the real configured system, not a generic demo.
7. Cutover and go-live — the controlled, sequenced switch from the old world to the new.
8. Hypercare and stabilisation — intensive support in the weeks after go-live, until the first real month-end and payment cycles have run cleanly.

The trap is reading that list as a strict waterfall. It isn't. The phases with the longest external lead times — bank connectivity and data migration — have to start early and run alongside the build, or they become the thing everyone is waiting on at the end.

Bank connectivity is the long pole

If there's one thing eighteen years in this work has taught me, it's that the software goes "live" in a test environment in weeks, and then you wait months for the banks. Bank connectivity is, on most programmes, the critical path — and it's the part you control the least.

Onboarding each bank channel is its own small project. For every bank you agree the channel (SWIFT, host-to-host, EBICS, API), settle the statement and payment formats (MT940, camt.053, BAI2 in; pain.001 and local formats out), then test statements in and payments out end to end, including the acknowledgements coming back. Every one of those steps runs on the bank's timeline, through the bank's implementation team, in the bank's queue — not yours. Multiply that by the number of banks and regions in scope and you have the single biggest variable in the plan.

"

The software config is on your schedule. The banks are on theirs. Plan the banks first and the configuration second — never the other way around.

This is why connectivity onboarding kicks off in the first weeks, in parallel with design and build, rather than politely queuing behind them. A programme that starts talking to its banks on day ten has options; one that starts three months in has a slipped go-live it hasn't discovered yet.

What actually drives the length

When someone asks me how long "a TMS implementation" takes, my honest first answer is a question: how many banks, how many entities, how many modules? Because those, not the product, set the clock. The real drivers:

• Number of entities, banks and connections. One entity and two banks is a fundamentally different exercise from forty entities and twenty banking relationships across regions. Each bank connection is an independent lead time.
• Number of modules in scope. Cash visibility alone is the fastest path. Add payments, then risk and hedging, then debt and investment, and each brings its own design, configuration, integration and testing.
• Integration complexity. A clean single feed to one ERP is straightforward; multiple source systems, market-data feeds and accounting write-backs each add design and test surface.
• Data quality. If your bank accounts, counterparties and payment details are already clean and owned, migration is quick. If they need remediation first, that work sits on the critical path whether you planned for it or not. This phase deserves its own attention — I've written it up separately in TMS data migration.
• Organisational readiness and decision speed. A single accountable owner who can decide in a day keeps things moving. A committee that meets fortnightly to ratify design choices quietly adds weeks between every phase.

An honest sense of scale

I won't give you a single number, because a single number is how you get a plan that's wrong before it starts. But a range is fair.

A focused, single-entity, few-banks, cash-only implementation is typically a matter of months. A multi-entity, multi-bank, multi-module programme — full scope, several regions, real integration — runs considerably longer, comfortably past a year for the largest rollouts. Where exactly you land inside that span is set by the drivers above, and mostly by connectivity and data.

So treat anyone who quotes you one exact figure without first asking about your bank count, entity count and module scope as guessing. They might be close by luck. They're not close by method.

Docs versus reality: where the time actually goes

The vendor timeline, the one in the sales deck, is a configuration timeline. It's usually accurate about configuration — that part genuinely does move fast. The problem is that configuration is not where implementations slip.

They slip on bank onboarding, because the banks move at their own pace and there are more of them than the plan assumed. They slip on data migration, because the master data turned out dirtier than anyone admitted, and cleaning it wasn't scheduled. And they slip on decision latency — the days and weeks lost waiting for a design decision no single person felt able to make. Notice that none of those three are about the software.

That's also, usefully, the same root behind most programmes that go badly wrong; it's worth reading why TMS implementations fail alongside this, because the failure modes and the timeline risks are the same story told twice.

The practical takeaway is a sequencing rule, not a scheduling trick. Plan the banks first and the configuration second. Start connectivity and data cleaning in the opening weeks, run them in parallel with the build, and protect the testing window at the end — because when earlier phases run long, testing is what gets squeezed, and a squeezed test phase just moves the defects into your first live month-end. Get that sequence right and the timeline stops being a hopeful number in a plan and becomes something you're actually running.

Part of the Treasury Management Systems guide. If you found this useful, the newsletter sends one practical finance-systems pattern every two weeks — real SAP, treasury and delivery notes from 18 years inside enterprise finance.