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.

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.

Case study

Anglo American Plc

William Ward-Brew

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:

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).”

Demonstrations

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.