Written by Renea Mahadeo, Treasury Masterminds Board Member
If you are planning a TMS implementation, your ERP is not just a data source. It is the foundation the integration will be built on. The cleaner and clearer that foundation is before day one, the faster and smoother the build goes. This article walks through five areas worth getting right before the project formally begins.
Understand what is actually flowing across the integration
Before any preparation can happen, it helps to be clear on what the integration carries. Data moves in both directions. From your ERP to the TMS: bank account master data, company codes, chart of accounts, counterparty records, and FX rates. From the TMS back to the ERP: bank statements, cash positions, payment instructions, GL postings, and hedge accounting entries.
Each of these flows has three things that need to be defined before the build starts: the frequency (real-time, intraday, or end-of-day), the format, and the owner. Getting alignment on these early shapes every design decision that follows.
1. Audit your master data before the design starts
ERP systems accumulate years of data. Company codes that were added and never decommissioned. Bank accounts that were closed but never removed from the system. Cost centres that no longer reflect the current organisational structure. None of this is unusual, and none of it is a problem. The challenge arrives when the integration requires two systems to agree on the same data for the first time.
The most valuable thing you can do before your implementation begins is to pull your bank account master data, review your company code structure, and identify anything that does not reflect current operations. A data cleanse workstream running alongside integration design is far less disruptive than one running during UAT.
2. Bring your financial controller into the conversation early
GL posting requirements are easy to defer. They feel like a finance detail rather than a treasury detail, and there is usually enough to discuss in the early design sessions without them. The challenge is that the answers require alignment between treasury, finance, and sometimes tax. That alignment takes time.
Questions like: how should bank charges post, what is the accounting treatment for short-term investments, and how does FX revaluation flow through the ERP are not quick to resolve. Getting your financial controller into the conversation in the first month means these decisions are made as part of the design, not as a blocker to go-live.
3. Agree on cash position source of truth
Your ERP runs batch processes at fixed intervals. Your TMS will show cash positions in near real-time. At any given point in the day, the two systems will show different numbers. Both will be technically correct, based on different data cut-off points.
Before the integration goes live, treasury and finance need to agree on a documented answer to two questions: which system is the source of truth for cash positioning, and at what point in the day does that apply. This is a design decision, not an operational one. Making it before go-live, with formal sign-off, removes a significant source of confusion for the operations team once the system is live.
4. Design your reconciliation process upfront
Reconciliation is the operational heartbeat of a TMS-ERP integration. Every payment that leaves the TMS, posts in the ERP, clears at the bank, and returns on a bank statement needs to match at every step. The reconciliation design determines how exceptions are handled, how month-end closes, and how the treasury operations team works day to day.
Treating reconciliation as a formal design deliverable, with the same level of documentation and sign-off as any other design document, means the operations team goes live with a clear process rather than building one under pressure. It is one of the highest-value investments in the preparation phase.
5. Protect integration testing time from the start
Integration testing between the TMS and ERP consistently surfaces things that unit testing and transaction flow testing do not. Timing mismatches, data format differences, and edge cases in GL posting logic all appear when the two systems are running together, not before.
Building your project timeline from the go-live date backwards, with integration testing as a fixed and protected window, gives the team enough time to resolve what surfaces properly. The preparation work in the areas above directly reduces what surfaces during testing. Investing time before the build starts pays back in the testing phase.
The earlier the conversations, the smoother the integration
None of these preparation steps require significant budget or external resource. They require the right internal conversations to happen before the implementation begins rather than during it. Treasury, finance, and operations all have a stake in how the integration is designed. Getting them aligned early is the most practical thing a treasury team can do to set the project up for success.
Aso Read
- Physical vs. Virtual Bank Accounts: What You Need to Know
- Understanding Bank Treasury: Managing Liquidity, Risk, and Regulatory Compliance