Typically they turn to their enterprise resource planning (ERP) software. These providers are more actively promoting their treasury management capabilities and clients have already made significant investments integrating the technology and building knowledgeable resources of the product. While there are benefits to be achieved from this approach, it also comes with certain limitations.
The potential benefits include seamless integration with existing functionality with regards to the general ledger, accounts payable and receivable (AP/AR) and cash reconciliation. Additionally, connectivity with third parties – such as market data providers and banks – is often already in place and thus available for treasury’s needs. It is therefore possible to create one source of static data, payment instructions and general ledger accounts, thus reducing time and the risk of maintenance for keeping master data congruent as well as any mappings to translate data between internal systems. Furthermore, most users will have existing knowledge of the application and its reporting tools.
While there are many facets to consider when evaluating the department’s ERP treasury capabilities, there are two primary ones that can be seen as driving the majority of decisions. First is the limitation in functionality available in an ERP system as compared with a specialised treasury workstation. Most ERP systems contain basic treasury capabilities, while some have even made strides in expanding their instrument coverage to more structured products. However, they are often not as robust as traditional treasury workstation systems.
Examples of functionality gaps include the ability to model and account for complex intercompany loan structures, structure derivatives and certain investment products. Functionality gaps force firms to manage certain products and processes offline, thereby losing the benefit of having one fully integrated application. In addition to functionality gaps, many users do not find the ERP treasury modules intuitive to use so the reporting suite and its flexibility is limited without significant customisation. Again, this could force the user to build and manage reporting offline and thus minimise the benefit of having a centralised treasury management solution.
The cost factor
This leads us to the second primary item driving the ultimate decision: cost. The cost of implementing the treasury functionality in an ERP application is typically substantially more than a standalone treasury workstation: indeed these costs are typically three to four times greater. There may also be additional software licensing costs incurred to accommodate the full suite of functionality required – including cash positioning management, forecasting and bank fee analysis, and bank administration management. These potential licensing costs need to be factored into the overall analysis, as well as ensuring that these additional modules are fully integrated into the existing modules being utilised.
In our opinion leveraging your ERP to manage the entire scope of treasury functionality is not ideal in many situations, although in certain scenarios it has worked well enough. One scenario is when treasury’s capability needs are aligned with the strengths of its current ERP provider. This typically translates to a more vanilla portfolio of financial products, with a priority focus on cash management and payments. In this situation, experience has shown that clients are successful in leveraging the ERP to fulfill their holistic treasury needs.
Another scenario that has also proved successful – and the most common in our experience – is a hybrid approach, in which the client will again leverage the strengths of the ERP tool but also leverage a standalone treasury workstation. This is referred to as the “best in breed” approach where treasury selects multiple products providing industry-leading functionality in specific areas and integrates them to provide a complete solution.
One example of this division of responsibility is performing payments, cash reconciliation and cash accounting in the ERP, while the remaining functionality – such as deal management and the associated accounting, cash positioning and forecasting – is performed in the standalone treasury workstation. Various permutations of this model have been used, but it is most often utilised when the ERP application is already being leveraged and a new standalone treasury workstation is being brought in to fill gaps not provided by the ERP. This scenario requires bi-directional integration between the two systems. An example of such integration would entail accounting entries and potentially instrument settlements, where payments are required to be fed from the treasury workstation to the ERP and anticipated AP/AR flows provided from the ERP to the treasury workstation to facilitate forecasting.
To the extent the number of applications can be limited to only a couple, the “best in breed” approach can be very successful in providing a solution to fully meet all the treasurer’s needs. Situations where this approach is less successful are those where there are numerous applications, with each fulfilling only a fragment of the requirements. When numerous tools are involved in the process, a large amount of time and effort is required to integrate data between the applications, and any analysis requiring a comprehensive view of the data can be very arduous, not to mention involve a significant time lag.
While there can be benefits to leveraging ERP applications for some or all of the company’s treasury management needs, a comprehensive analysis of the costs and benefits should be performed to ensure the ultimate solution will fully meet its current and future needs.