As the conduit through which financial data flows both in and out, the treasury management system (TMS) can be the hub to which all other digital solutions connect. The first very basic TMS appeared as far back as the early 1980s and since then the concept has grown in stature. But whilst many treasurers still do not use one, the TMS is starting to gain favour, largely as accessibility increases at the hands of cloud delivery and price comes down. Is the TMS about to hit the big time?
When seeking a powerful workstation, treasurers typically have two options: a treasury management system (TMS) or an enterprise resource planning system (ERP). In the treasury context, both fundamentally seek to achieve the same goal: improving the work of the treasury function. Yet, both have different methods of achieving this, offering their own advantages and disadvantages. Some treasurers have access to both technologies, and, of course, spreadsheets are still also in the mix, so in this section we explore the key differences between TMS and ERP, before taking a practical look at TMS implementation.
A dedicated technology
A TMS is a dedicated treasury technology solution. The vendor market has consolidated considerably in the past decade with many smaller suppliers having been acquired by the few remaining major players (of which Wall Street and SunGard are the mainstays). The surviving mid-ranking players are closing in fast on the market, helped not least by technological changes in the delivery of their systems, from installed to cloud-based. This list includes the likes of Reval and Kyriba, with smaller international players such as BELLIN, Salmon and Trinity also making an impact.
Vendors commonly claim a wide variety of tools that can be applied to many treasury tasks as part of their offering. The TMS platform typically sits at the heart of a treasurer’s operation – collecting data from multiple sources, processing this data and then outputting it where necessary for both the treasury and company as a whole. The sheer range of functions that a TMS is able to deliver as a core system is one of the main selling points. Modern systems may offer well over 100 modules covering a range of treasury activities including cash management, debt and derivatives, forecasting, hedging and risk management. Typically, a corporate would use around 40 to 50 modules, depending on circumstance.
These might include modules for the following: cash, liquidity and forecasting, debt, internal banking, currency, interest and other derivatives, accounts receivables/accounts payables, equity and funds, bonds and treasury bills, settlement/payments, risk management, scheduled imports and exports, accounting.
This list if far from exhaustive, however, flexibility to customise the TMS using such modules has been one of the major developments in the TMS in recent times. Whereas once there was a worry among the corporate community that a TMS was a relatively monolithic tool, the systems can now be customised to fit current and possible future needs. For example, a multinational corporate (MNC) would be able to select all the FX modules that it requires to carry out cross-border activity. A UK domestic company on the other hand with little use for these can turn these modules off (or, more accurately, just not activate them) and focus on the areas that better suit its business requirements.
And because corporates don’t have to buy the entire system, and many TMSs can now be delivered via the cloud rather than installed on premise, there are potentially benefits in terms of cost, the time taken to implement (and maintain) the system, and also the ability to add on modules when business requirements change – instead of having to deploy a new system. The sheer range of functions that a TMS is able to process, and the increasing flexibility of delivery options, are among the main selling points of such a workstation.
Another area that TMS vendors have focused heavily on in recent years is interoperability of TMSs – whether it be integration with internal systems, or communicating with an external party’s software, such as a financial institution’s e-banking platform or an FX trading platform. This integration drive delivers benefits such as real-time cash positions and improved forecasting, as well as reducing the error rate from manual inputs.
For many treasurers, an additional tick in the box for the TMS is that the system ‘belongs’ to the treasury (unlike a company-wide ERP). For the treasury, owning the solution offers a number of advantages. Firstly, the treasury will have control over the system and therefore – in theory – should have more say over when it is optimal to install updates.
Of course, central sign-off will still be required for this, and budget will need to be allocated to the TMS, but this should be less cumbersome than an ERP treasury module update. After all, updates to the ERP treasury module would normally be driven by IT and be bundled into a company-wide package therefore leaving treasury little say in when this happens. The smaller scale of a TMS upgrade is likely to mean it will also be cheaper and quicker to achieve.
TMS functions may include:
Cash management – cash positions, bank account reconciliation and cash-flow forecasting.
Liquidity management – cash pooling, zero-balancing and in-house banking.
Debt management – loan portfolios, mortgages and lease finance.
Transaction management – deal input, settlement and confirmation.
Deal management of specific instruments – money market, securities and derivatives.
Accounts management – transaction reporting, accruals and revaluations (eg for hedging).
Security and control – audit tracking, workflow management and user access definitions.
System interfaces – with bank systems, dealing systems, market feeds and accounting.
ERP: taking the holistic view
Data published in the last couple of years by consultancy firm Zanders has shown that 70% of corporates who employ a treasury workstation use a specialised TMS system. Yet, the data also suggests that there is a slow drive towards companies exploring and implementing a treasury-specific ERP treasury module. In 2006, 19% of companies were using SAP in combination with SAP treasury. In 2014, this number had increased to 40%, says Zanders. Interestingly though, the driver for this change is not necessarily coming from the treasury department but from the boardroom. In the quest for increased oversight, particularly in today’s volatile environment, the ERP’s promise of a holistic company-view seems attractive.
By its very nature, an ERP system (and typically this will either be a product from the modern stables of SAP or Oracle; there has been market consolidation here too) has a wider focus than a specialised TMS, with modules being available and used across the entire business. As such its treasury module can be seen as a branch of the system and not the heart of the system itself.
Whilst this might sound like a significant disadvantage, this can actually offer the business a number of benefits as treasury becomes fully integrated and on the same platform as the rest of the company – helping to facilitate the consistent passage of data. The capabilities that are provided from a treasury perspective complement the story that the data from the wider finance function and beyond provides. An ERP gives a view of core processes that concern treasury from end-to-end, and allows companies to better collaborate, identify risks earlier, obtain real-time data and bring all the pieces together in one place.
In addition, the ability of an ERP treasury module to retrieve information from other modules reduces integration headaches and ensures that the costs associated with non-ERP TMS platforms, are minimised. It also offers executives and internal audit a greater sense of comfort because all the data is being retrieved from a single platform.
The sheer scale and technical complexity of an ERP system affords it the ability, if supported by the right advisory and professional services support (for SAP, for example, beating a path to Hanse Orga is a common tactic for treasury users), to create a best-in-class architecture. This can ultimately offer the treasury functionality above and beyond what a standalone TMS can offer. Indeed, the major ERP vendors (and to this list we must add Microsoft) often work on economies of scales and have an ability to lower cost on the latest technologies a lot faster than TMS vendors, as their TMS platforms are crucial to a wider sales strategy. Concepts that are considered the Holy Grail for most treasurers, such as organisation-wide, real-time cash management views are, to all intents and purposes, only really available on ERP platforms.
The common consensus, however, is that achieving such an integrated architecture comes at a huge cost and one that the majority of organisations are not willing or able to meet. However, an ERP treasury module project can be a cheaper alternative overall in some circumstances. If a company has already invested in an ERP then installing the treasury module is likely to be a cheaper option overall. This is because these types of systems are almost always architected to integrate seamlessly and haven’t in recent years been layered with the latest open interfacing technologies like Enterprise Web Services.
Case study
Overcoming the age barrier
When an ageing TMS could no longer provide the necessary degree of visibility over Mediq’s cash and liquidity management processes, change was necessary. Picking the right system involved much deliberation and patience, but has it paid off?
The transition in 2013 from being publicly listed to private equity ownership revealed its 20-year-old treasury management system (TMS) as the weakest link in the treasury operations of Netherlands-based Mediq.
The 115-year-old company operates in the medical supplies sector with 25 business units spread across 14 countries in North Western Europe and the US. With revenues of around €2bn, it employs a small treasury team consisting of Paul Schreurs, Group Treasurer, a Treasury Assistant, an interim who supports various projects, plus one back office full-time employee (FTE) who reports to the controller’s office.
Under its new private ownership regime, cash visibility topped the agenda. Treasury implemented a new cash flow forecasting tool but whilst this afforded the necessary cash view, integration with the existing TMS was difficult. This meant treasury was still relying on spreadsheets for much of its output, raking up the inevitable problem of version control. As Schreurs admits, it was very cumbersome to get a consistent picture of the truth around all sorts of treasury transactions. “This just increased the need for us to look for a new integrated system.”
The selection process
Seeking the assistance of Dutch finance and treasury consultancy, Orchard Finance, Schreurs and his team embarked on a four-part selection process. The first phase was to closely consider Mediq’s current treasury processes, redefining some to meet current best practice. A major internal meeting was then held to define the requirements for the TMS. Based on this document, a long-list of potential suppliers was drafted, this subsequently being distilled into a short-list of four. The four were invited to respond to Mediq’s formal RFP in which each would provide company and system details, reference clients and responses to specific business cases (notably around cash operations). And, having just rolled out the new cash flow forecasting tool, the incoming TMS had to operate at least along similar lines.
An implementation plan had to be provided and, of course, the price had to be right; with reference to the latter, one of the four immediately ruled itself out of contention recalls Schreurs. The remaining three – Trinity, BELLIN and Integrity – all demonstrated a very close fit to Mediq’s requirements. Each was invited to give practical demonstrations – using real bank account and hedging data, for example – having first been given an extensive list of elements to address. “We didn’t want to spring surprises on them,” comments Schreurs. In the actual implementation, all parties would be working together to set things up and look for further improvements, so he was keen to keep the demonstration realistic for the vendors, not catch them out.
The selection process revealed the solution of Frankfurt-based vendor, Trinity, as the best ‘out-of-the-box’ fit. Working with Trinity’s regional sales partner, Wieltec, Schreurs could see that the system “already had a very good basic set up which would make it quick and easy to implement”. In contrast, one of the other systems would require a full understanding of how Mediq’s treasury operates before being fully configured. “It means you must already have very good practices. Trinity’s standard set-up allowed us to fit in our existing ways of working but we were also very open to adopting the best practices found within Trinity.” This flexibility paid off. The full implementation took only 19 working days to complete, says Schreurs, adding that project brevity afforded a significant saving on the cost component.
Implementation
Orchard Finance had been brought in initially just for the selection but Mediq decided to retain it for the project too. Schreurs points out that it was necessary to externally appoint a dedicated project manager as the Mediq treasury team was too small to free-up any personnel. An Orchard consultant was joined by project leads from Mediq’s own IT department and from Trinity “ensuring we realised the project within budget and on time”. Whilst “further opportunities” were realised on the way to completion (additional reporting, for example) the project came in within scope too, he confirms.
The roll-out started with central treasury in January 2014. By March, the incumbent TMS, which had been run in parallel for a short period during testing, had been decommissioned. The timing of the switch-off was pressured by the imminent licence renewal of the old system. With the old system out of the way, the project commenced rolling out to the business units in 14 countries. Once everything had been fully tested, Mediq was also able to switch off the cash flow forecasting tool it had recently deployed as this function was now fully enabled in Trinity.
Benefits
Technology has been consolidated and, states Schreurs, “our reporting is much more automated”. But whilst most content for treasury’s monthly report now comes directly from Trinity, he admits that (like most treasurers) “you always need some spreadsheets”, in his case mostly to tackle residual data that, for now, lives beyond the TMS.
Nonetheless, the Trinity TMS has contributed to a major increase in Mediq’s efficiency. It has given Schreurs considerably more visibility over cash, enabling him to log in and check balances and provisions which he can easily filter. “If a certain business unit has cash outside of the pool, obviously it is something I don’t like. Now it is easy to see that cash and where it comes from so I can contact the business unit directly to seek an explanation and to take action,” he says. “Where previously I had little or no visibility at the level of the bank account in certain countries, now I have full insight – and everyone is looking at the same data.”
Having seen some “big improvements” delivered by the new system, the Mediq team pressed ahead with another automation project to drive yet more efficiency. To access MT940s from its main banks it had to log into the relevant bank portal and manually download them. Today, Schreurs confirms that automatic importing of MT940s is now possible and that the system “works perfectly”. Indeed, “every morning all transactions and cash balances of the previous day are available in Trinity”. The group’s cash, it seems, has never had so much clarity.
System selection and implementation
Having explored the differences between the two systems we will now look at what treasurers need to consider before selecting and implementing a treasury workstation. We focus on the TMS since this will fall more squarely under the treasurer’s remit – the choice of ERP is likely to be a broader business decision, as explained above.
Implementing a TMS can, at one extreme, be an exercise in business process reengineering (BPR) or at the other extreme it can be an exercise in software customisation. The BPR scenario is that the buyer adapts its processes to the functionality of the TMS. The epitome of this school of thought is the view that SAP reflects process best practice, so it is better to adapt treasury processes to SAP rather than vice-versa.
The customise scenario on the other hand is when the buyer pays to have the software customised to fit exactly to existing processes. Although this may sound attractive the initial customisation is always expensive and can be disappointing, leaving the treasury with a longer-term maintenance challenge.
Most treasurers will have something in between these two scenarios. So how does treasury decide which processes can be reengineered and which are immutable? One rule of thumb is to map the requirements in terms of external processes in the business. The logic here is that treasury can easily change internal processes within the department but may struggle to change wider order-to cash (O2C) and procure to pay (P2P) processes across the company. This does depend of course on the remit of treasury, and whether the TMS is pure treasury or a CFO level decision.
For this analysis, external financial and market interfaces are also open to reengineering. For example, if the TMS has SWIFT connectivity built in, treasury can choose to go multi-bank without disrupting the rest of the company, likewise for e-FX and confirmation platforms and market data feeds. Regulatory constraints may create exceptions, however – for example, Chinese multinationals will require regulatory compliance and appropriate market practice from their TMS.
Setting the treasury path
Mapping treasury processes is the first task in any exploration of new technology – it is essential to know where you are before you start plotting a new direction. The simplest way to describe immutable treasury processes is to start with the inputs and outputs and then add the actions that have to happen within treasury, in minimal terms. When seeking to describe in this manner, do not forget to include internal control requirements – if the company likes to have ‘eight eyes’ reviewing FX exposures before hedging, then a TMS that only handles ‘four eyes’ will not work. An example description might look like this:
Inputs
FX exposure data from subsidiary (input.csv).
Actions
Review input and explain variances.
Model hedge alternatives and agree strategy.
Execute hedges (forwards, NDFs, options).
Outputs
Hedge report to subsidiary (report.csv).
FX risk consolidation to executive committee on dashboard.
IFRS compliant journal entries to ERP.
IFRS compliant revaluations to ERP.
Pay attention to what is not covered in this description. New technology should effect change and as such the following may apply:
We do not describe processes within treasury (because we are willing and able to change them).
We do not provide samples of the Excel sheets we currently use (because we want to free ourselves from ‘Excel Hell’).
We do not describe our current method of calling banks by phone to ask prices (because we are open to eFX as an escape from operational risk and phone pricing).
We do not provide samples of the FX confirmations that we currently type up manually in Word and fax to banks (because we are open to electronic confirmation).
Proof of concept
Once you have described the immutable processes, it is best to select the ones that are the least ordinary and ask vendors to demonstrate how they will cover these needs in their TMS. Since a live demonstration of an unusual process may be a lot of work for the vendor to set up, select only the processes that are most critical for treasury. The demonstration is not about tripping up vendors but a journey of discovery.
The demonstration process can really set vendors apart. Do not accept a demonstration by PowerPoint; this is not a demonstration at all – it is more like promises which may or may not be fulfilled, and at what cost. An effective demonstration should prove the functionality live on the vendor’s TMS. This should highlight any gaps and allow for a realistic assessment of the TMS’ suitability to the organisation.
There will be differentiation between the live demonstrations. Some vendor’s may stick to the minimal requested functionality. This has the merit of keeping the demonstration simple. Others may try to share what they observe as best practice. This can be a benefit, especially for treasury organisations moving from Excel to TMS. The key is to be in control of the process, not be led by professional sales people who have one overriding objective.
Finding the best fit
The techniques described here are not used in isolation. What works well is a two-phase approach. Start with an RFI (request for information) exercise based on a high-level requirements list. Invite the vendors who seem to meet your requirements (and this may be a list of ten or more) to give a generic demo which gives you a chance to see the system, ask follow up questions and assess each vendor’s fit in terms of personalities and business approach. This phase allows you to scan an extensive part of the TMS market but not waste your own, nor the vendors’ time.
On the basis of the RFI results, you will be able to shortlist the vendors who appear to best meet your basic requirements. This list may contain around half a dozen names to whom you may issue a formal request for proposal (RFP).
With the shortlisted vendors, you will share the immutable process descriptions described above and ask them to demonstrate in more detail, using real-world scenarios, how they can cover your needs with their TMS. You can evaluate whether they cover your needs and also how much added-value their TMS brings to the process for you.
Finally…
TMS systems vary, from offering basic cash management and transaction management functions to tools dealing with complex risk management and more sophisticated investment instruments. Vendors range from the domestic provider who will have a detailed knowledge of local processes, to the international operation with the means of keeping in touch with a broader range of regulatory and compliance matters and, arguably, the financial wherewithal to sustain development.
With a clearly defined list of requirements produced from a thorough assessment process, treasurers will be better equipped to evaluate the various systems available in the marketplace – and can have greater confidence in selecting the most appropriate TMS to suit their business and treasury needs.
Checklist: evaluating a TMS
Executive management support
At the outset of the project, it is essential that treasurers should garner the support of executive management and at least secure their willingness to consider investing in a new treasury system. Funds allocated to a treasury project may be channelled from investment destined for core business areas.This may be difficult to justify, especially if treasury is not a profit centre, but the results of the TMS assessment process will help to develop a strong business case, particularly from a compliance and control perspective.Although the final investment decision may await completion of this business case, executive management’s awareness and interest in the project will do much to persuade other business areas of its importance.
Corporate strategy
Corporate plans for the future should be ascertained and the implications of any merger and acquisition (M&A) activity or divestment plans should be considered. Are more branches to be opened or additional subsidiaries likely to join the group? How will these impact treasury operations? The TMS system must be flexible enough to cope with changes and expansion/contraction, whether through M&A or organic growth, and accordingly must be easy to upgrade and replace.However, it isn’t just about the future and other questions should be asked. What is the current situation? Are there any corporate projects already in progress that may prevent treasury from achieving its goals or will it be possible to factor in such changes within the scope of the TMS project?
IT department
It is important to seek IT participation from the start and invite a designated representative to join any TMS project discussions. IT will be closely involved in the installation and ongoing support of a new system (depending on the solution chosen) but faces competing demands from all areas of the business.Their early involvement promotes their understanding of treasury requirements whilst giving them the opportunity to provide expert guidance on the technological details of the TMS project, eg on integration issues with other business systems and the type of solution to choose (such as outright purchase, license, application service providers (ASPs) and hosted options).
Other departments
Open communication channels should be maintained with all the stakeholders. How will the implementation or upgrade impact on other departments, such as accounting, legal, audit and sales? Will their systems be affected? In addition, if those departments are planning their own internal changes or installing new systems, how will this impact on the TMS project?
External relationships
Treasurers should be aware of any issues that may surround the integration of bank reporting mechanisms, payment systems or other external feeds with a new TMS. It can be helpful to discuss the TMS project with bank relationship managers as they may be able to provide useful insight into TMS technology and how it can help specific clients’ needs.A TMS project also provides an excellent opportunity to review the use of banking technology across the organisation to ensure optimum configuration of all treasury technology. Existing treasury system vendors will, of course, need to be handled sensitively if there is a possibility they will lose business.
Treasury structure
It is important to consider which areas within treasury operations will be impacted by system changes. This will depend on a treasury’s structure – decentralised, centralised and/or in-house bank – and on whether payment/collection factories or shared service centres are used. In a large global operation, it may be necessary for numerous treasury employees to have web portal access to the TMS.The project presents a good opportunity to review interaction between head office and business units. The TMS should provide benefits to the business units through ease of reporting cash flows, treasury tools and centralised dealing facilities, and head office will receive more regular and reliable information flows from the business units.In addition, external influences on treasury should be taken into account. For example, how will the European Market Infrastructure Regulation (EMIR) impact on treasury?
Treasury employees
Any employees who are likely to be affected by the project should be informed. Where appropriate, it can be useful to involve them in the assessment process related to their particular activities (eg helping with workflow analysis). They can provide useful insight into the jobs they perform. This includes treasury staff at branches and subsidiaries.A major exercise of this nature puts strain on day-to-day activities. The treasurer should be clear about the staffing levels and other resources necessary to achieve the project’s objectives and how this can be delivered without impacting adversely on daily operations. The employment of temporary staff and perhaps an interim treasury manager as cover should be considered carefully as it is important that knowledge acquired about the new TMS should remain with the treasury team.
Treasury operations
The systems and procedures currently in use should be assessed in detail and relevant documents such as the treasury policy, treasury mission statement, job descriptions and user manuals should be consulted. Workflow analysis can be undertaken to identify current inefficiencies, weaknesses and control and security issues that may expose treasury to greater risk.Areas of strength should also be noted as these efficiencies must continue (or even be improved further) under the new system. The treasury’s future plans should also be taken into account.
System integration
The flow of information into and out of the TMS should be assessed. Company expansion results in a complex mix of systems and technology. Automated links or integration between the TMS and other systems will be necessary with market feeds (eg Reuters and Bloomberg), bank systems, dealing systems and accounts payable/receivable. The TMS can also interface into confirmation matching systems and other software so these options should be considered.
Defining TMS requirements
Finally, a definitive list of requirements should be drawn up using the information collated. These requirements can then be divided into areas of activity or sections within the treasury department, eg dealing, confirmation, settlement, cash-flow forecasting, treasury control and risk management, differentiating between the essentials and the ‘nice-to-have’s. The requirements definition should also include known or likely future requirements.
