Although treasury management systems are not necessarily part of the new breed of digital solutions discussed in this Handbook, their importance cannot be downplayed. Sitting at the heart of the treasury office, the treasury workstation can be viewed as the conduit through which data flows in and out, acting as a single source of truth and hubs for all other digital systems to connect to.
Treasury Management Systems (TMSs) and Enterprise Resource Planning systems (ERPs) have been competing to be the treasurer’s workstation of choice for well over a decade. Both systems 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. Making matters worse, there is the possibility to use both technologies, with spreadsheets also in the mix.
In this Section, we will begin by exploring the differences between a TMS and ERP and then offer some practical advice for treasurers looking to implement a new treasury workstation.
Built to fit
A TMS is a dedicated treasury technology solution that vendors claim offers a wide variety of tools that can be applied to many treasury tasks. “The TMS sits at the heart of a treasurer’s operation – collecting data from a plethora of different sources, processing this data and then outputting it where necessary for both the treasury and company as a whole,” says John Byrne, Managing Director at TMS provider Salmon Software.
The sheer range of functions that a TMS is able to process is one of the main selling points. Salmon Software’s offering, for example, has around 120 modules that cover a range of treasury activities including: cash management, debt and derivatives, forecasting, hedging and risk management. “Typically a corporate would use around 40 or 50 of these modules, depending on their circumstances,” explains Byrne.
This flexibility to customise the TMS using modules has been one of the major developments in the TMS space of late. 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. For example, a multinational corporate would be able to select all the FX modules that they require to carry out cross-border activity. A UK domestic company on the other hand, with little use for these, can turn these modules off and focus on the area that better suit its business requirements.
And because corporates don’t have to buy the system lock stock and barrel, 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 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. This integration drive should help deliver 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: the holistic view
Data from consultancy firm Zanders shows that currently 70% of corporates who employ a treasury workstation use a specialised TMS system. Yet, the data also suggests that there is a drive towards companies exploring and implementing an 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.
By its very nature, an ERP system 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. While this might sound like a significant disadvantage, this can actually offer the business a number of benefits as treasury is 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,” says Christian Mnich, Director of Solution Management for Treasury Application at SAP SE. “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,” says James Bateman, TMS Architect at SLG Treasury. “It also offers executives and internal audit a greater sense of satisfaction because all the data is being retrieved from a single platform.”
The sheer scale and technical complexity of an ERP system means that it has the ability, if supported by the right advisory and professional services support, to create a best-in-class architecture that can offer the treasury above and beyond what a standalone TMS can offer. “ERP vendors often work on economies of scale and have an ability to lower cost on the latest technologies a lot faster than non-ERP TMS vendors, as their TMS platforms are crucial to a wider sales strategy,” says Bateman. “Concepts that are considered the Holy Grail for most treasurers such as organisation-wide, real-time cash management views, are only available on ERP platforms,” he notes.
The common consensus, however, is that achieving such an integrated architecture comes at a large cost and one that the majority of organisations are not able to invest in. SLG Treasury’s Bateman contests this perception and argues that an ERP treasury module project may actually be a cheaper alternative overall. “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.”
For Bateman, the cost of integration post-2008 is an excessively underestimated concept within most TMS rollouts and often accounts for large over-expenditure, future rework and is something that can potentially be avoided by leveraging an ERP treasury module crafted on standardised business and integration processes.
Anglo American Plc
Head of Treasury Operations
UK based multinational mining company, Anglo American Plc, installed SunGard’s AvantGard Quantum TMS in 2001 to manage its treasury operations, integrating this into SAP – the company’s ERP system. The TMS is upgraded regularly every 18 months to two years.
“We selected this system for a number of reasons,” says William Ward-Brew, Head of Treasury Operations at Anglo American. “Aside from it having the functionality we required, the reputation of the company was a big factor and we wanted to use a vendor with knowledge of the different markets we worked in and also with other blue chip companies on their books. The financial status of the vendor was also important due to the consolidation in the TMS industry over the years and we wanted to ensure our system was committed to and would be developed in the future.”
Anglo American did investigate the SAP treasury module after being pointed in that direction by IT, however, a specialised TMS seemed to be a better fit. “There was a lot of reluctance to use the ERP module because of the experience that some of the team members had had with it before and this carried a lot of weight towards not selecting it,” says Ward-Brew. “The project was treasury-led and we wanted a system that was suitable for treasury needs.”
Being suitable for treasury needs extends beyond functionality and also touches on its ability to be flexible. “If you work in a treasury environment where you need to adapt quickly then an ERP upgrade can take a number of months and will have to incorporate other functions that use it as well. With a TMS, you can dictate when things get changed,” he says. The support offered by the vendors was another selling point, “we wanted our teams across the globe that use the TMS to be able to obtain regional helpdesk support quickly should they need it and we didn’t believe that this was cost effective with the ERP solution.”
For Ward-Brew, there is a place for both systems in the current marketplace. “The integration between the two is getting better and better and now areas such as accounting are seamless,” he says. “I still believe that TMS vendors are closer to the treasury market in terms of development focus and they have built modules to meet the evolving needs of the treasury. Also, for real-time data, the TMS is a better solution because treasury can determine the flow of information, unlike an ERP which may be updated periodically based on competing workflow processes across the business. If the enhanced data flows from the ERP can be integrated into the TMS and vice versa, then that is a great solution.”
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.
According to David Blair, former corporate treasurer and now Managing Director of Acarate treasury consultancy, 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 maintenance nightmare),” says Blair.
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, Blair notes, 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,” notes Blair.
Mapping treasury boundaries
The simplest way to describe immutable processes is to start with the inputs and outputs and then add the actions that have to happen within treasury in minimal terms, says Blair. “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:
FX exposure data from subsidiary (input.csv).
Review input and explain variances.
Model hedge alternatives and agree strategy.
Execute hedges (forwards, NDFs, options).
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.
Notice what is not covered in this description, says Blair:
“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 spreadsheet purgatory).
We do not describe our current insanity 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).”
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 unusual and critical for the treasury.
According to Blair, “the demonstration can really set vendors apart. The worst ones will try to get away with demonstration by PowerPoint, which is not a demonstration at all – it is more like promises which may or may not be fulfilled, and at what cost. The better ones will demonstrate the functionality live on their TMS. This should highlight any gaps and allow for a realistic assessment of the TMS’ suitability to the organisation.
“There will also be differentiation between the live demonstrations. Some 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.”
Putting it all together
The techniques Blair has described are not used in isolation. What works well, he says, is a two-phase approach. Start with an RFI (request for information) exercise based on requirements lists. Invite the vendors who seem to meet your requirements to give a generic demo which gives you a chance to see the system and ask follow up questions.
On the basis of the RFI results, you will be able to shortlist the vendors who appear to best meet your basic requirements. ‘Scanning’ an extensive part of the TMS market; but to not waste your own, nor the vendors’ time.
“With the shortlisted vendors, you share the immutable process descriptions described above and ask them to demonstrate 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,” Blair concludes.
Checklist: ten steps that treasurers should take when evaluating their 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 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?
Information Technology department (IT)
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).
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?
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.
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?
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 necessary to achieve the project’s objectives and how this can be delivered without impacting adversely on daily operations. The employment of temporary staff as cover should be considered carefully as it is important that knowledge acquired about the new TMS should remain with the treasury team.
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.
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.
TMS systems vary from offering basic cash management and transaction management functions to tools dealing with complex risk management and more sophisticated investment instruments. With a clearly defined list of requirements produced from a thorough assessment process, treasurers are 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.