The Power of Centralisation at Autoneum

by Janko Hahn, Head of Treasury Operations, Autoneum Group

In 2012, global vehicle acoustic and thermal management solution leader Autoneum launched a project to transform its treasury technology infrastructure as a catalyst for enhancing processes, improving cash management efficiency and control, and reducing costs across the group. In this article, Janko Hahn, Head of Treasury Operations, Autoneum discusses some of the considerations when planning and implementing such a complex and far-reaching project.

Project background

When we launched our project in 2012, we had a group treasury function comprising 2.5 FTEs based at our company headquarters in Winterthur, Switzerland, but payments processing was conducted by local business units. We had over 100 bank accounts globally with a variety of banks, with large cash balances in different locations, making it difficult to leverage our liquidity positions globally. Although we had a treasury management system (TMS) it had become outdated and no longer met our operational and reporting requirements. Similarly, the wider ERP environment was no longer appropriate to the company’s needs.

A related challenge was the lack of standardisation in the files we transmitted and received from our banks. This led to fragmented, paper-based processes for both payments and statement reconciliation. Furthermore, as payments were conducted locally, treasury had little visibility or control over processes and controls, and there was no common approach to payment systems or bank connectivity. For example, some business entities were using international electronic banking portals provided by their banks, while others were using solutions developed locally. We also lacked the ability to import electronic statements from systems used by local entities into our ERP, so balance and transaction information had to be recorded and reconciled manually.

A wider transformation project

In July 2012, Autoneum embarked on a group-wide project to re-engineer our business processes based on SAP as a standard platform. The project is being implemented in phases, with two to three business units migrating to the new platform and processes each year. We started first with our Swiss entities, and will roll out the project across the business over the next few years.

From a group treasury standpoint, this project coincided with our decision to evaluate new TMS options and review our treasury processes. To be consistent with group strategy, we therefore selected SAP TRM (treasury and risk management) together with SAP BCM (bank communications manager) for connectivity. We also licensed the SAP In-House Cash module for future use. As our SAP implementation partner did not have the capacity to support the treasury and bank connectivity functionality in SAP, we have formed a relationship with SAP Treasury’s consulting partner, Eprox Consulting (based in Cham, Switzerland).

Technology objectives

Having recognised the limitations of our existing treasury infrastructure and processes, our primary aim was to enhance efficiency and control over treasury and payment processes, and optimise cash and liquidity management.[[[PAGE]]]

We identified a range of specific project deliverables as follows:

• Centralise payments transmission and bank account statement retrieval;
• Establish a single gateway to the banks through SAP TRM;
• Implement the functionality offered by SAP TRM both at a central treasury and business unit level.

By doing so, we would achieve a complete and accurate daily overview of our cash balances across the business, and be able to import balance and transaction information (MT940) into treasury for cash positioning and reconciliation for our major accounts. Furthermore, by making the same functionality available to local accounts receivable operations, we could ensure consistency and transparency across the group.

Standardisation and centralisation

We realised that we would not achieve our cash management objectives through technology alone. One project element was therefore to rationalise our cash management banks and accounts wherever possible, in order to reduce costs as well as operational risk. A related decision was to implement a payment factory. This would involve centralising payments made by both treasury and accounts payable by transmitting payment files from each business unit via the ERP to a central hub. Payments would then be executed in the most cost-efficient and automated way depending on the payment urgency, currency and cut-off time.

A hybrid approach to bank connectivity

Having made the decision to use SAP TRM for cash and treasury management, we needed to determine how best to communicate between SAP and our banks. We were already familiar with FIDES Treasury Services, which is widely used in Switzerland to retrieve MT940 (end of day statements) and MT942 (intraday statements). However, we needed a global solution for both payments and statements, so we decided to review alternative options including SWIFT and EBICS in countries where this is used. A key criterion, however, was that any connectivity channel needed to support standardised XML ISO 20022 formats. We evaluated the solutions offered by a number of leading SWIFT service bureaus, and also considered whether SWIFT’s cloud-based solution, SWIFT AllianceLite2 would provide sufficient functionality and flexibility for our needs.

We recognised that while AllianceLite2 offered straightforward, bank-independent connectivity to SWIFT without the need for substantial IT investment, we felt it was targeted at companies with a smaller number of banking partners and fewer variations of payment file formats. In Autoneum’s case, we needed to connect to a larger number of banks and wanted the flexibility to connect with them not only via SWIFT but also via EBICS or even via host-to-host connections if necessary.

As we were reviewing our bank relationships, we did not yet have a complete picture of what our future banking landscape would look like by the time that our treasury SAP and wider SAP projects were completed. In addition, we wanted the flexibility to connect to other banks in the future. We were also aware that not all of our banks would support XML, so we needed to support other formats too.

Based on this analysis, we decided to implement the hybrid service bureau approach offered by FIDES. This would give us the global reach we required across our banking portfolio as it evolved, and enable us to leverage XML ISO 20022 formats. This involved using a middleware application to connect SAP with FIDES. FIDES would then route payments and statements to/from the relevant bank via the most appropriate method, such as SWIFT or EBICS, without the need for intervention from Autoneum. This effectively outsourced many of the bank communication tasks without the need to manage specific connections or formats.

Payment factory rollout

In 2013, we embarked on the payment factory element of the project. We implemented four Swiss entities as a pilot project, and have since rolled it out more widely, including USA and Canada during 2014. In Switzerland, we connect to our banks via EBICS, and via SWIFT in USA and Canada using Autoneum’s BIC code. Soon we will roll this out to France, Spain and Portugal, with the remaining entities in Europe, China and South America to follow.

Banking strategy

In addition to the technology and process elements of our project, we have also made progress in rationalising our cash management banks. We have appointed one bank for the SEPA area, therefore covering all of our euro-based countries. The same bank will also be able to cover Poland and Czech Republic. As yet, we have not appointed partner banks for Brazil, Argentina and China, but we are engaged in preliminary discussions.

Sharing experiences

Based on our experiences so far, there are a number of key issues that we would emphasise to other treasurers to ensure the success of a complex project aimed at optimising infrastructure and processes, and reducing costs.

• Managing external dependencies. The relationship with FIDES was very important, such as securing testing windows and ensuring that the relevant format conversions had taken place. We also needed to work closely with our banks to ensure that formats were clearly defined, and communicate our requirements fully to the consultants supporting the project. Each bank that we connected to had its own internal project guidelines to which it needed to adhere, and time needed to be built into the project plan to accommodate these requirements, such as user acceptance cycles, testing freeze periods, and go-live schedules.
• Internal project dependencies. Internal co-ordination with the accounting team was important to create and process test files to assess the impact on bank connectivity and set up the middleware application. This required careful co-ordination and resource planning to avoid delays.
• Master file data. Correct and consistent master file data was essential to minimise payment failures and rejections.
• Training and documentation. We took the time to train all those involved in the project, across a wide range of disciplines including treasury, IT, accounting and accounts payable. This included documenting processes and dependencies clearly and comprehensively. This provided transparency over the activities that take place in treasury, which is often considered as a ‘black box’ by those without regular treasury involvement.
• Planning and preparation. When planning the project, we allowed sufficient time for activities such as project preparation, process definition and testing. This was essential to maintain project momentum whilst ensuring realistic project timescales. When rolling out to the USA and Canada, we also needed to take into account multiple time zones as well as internal and external project participants in remote locations, which added to the time and complexity of each project task.
• Managing regional formats. We needed to manage the various payment requirements in each country, for which different formats were required. We found that we could not only rely on local knowledge of domestic formats within the group, simply because people did not have sufficient relevant experience: for example, when setting up ACH or WIRE payments in the United States, we needed to rely on our banks for format definition as our local business unit had been accustomed to using cheques in the past. In addition, significant change, such as migrating from manual to electronic payments, is a major cultural shift, so it takes time to deal with the issues that arise as a result.

The treasury SAP project is still under way, but we have already achieved significant benefits by rationalising our technology infrastructure, which underpins efficient processes, connectivity and banking relationships. We have also achieved a reduction in the number of bank relationships, and we continue to make progress in this area.[[[PAGE]]]

Looking ahead

Having established the basic technology framework, we plan to migrate from MT940 and MT942 to ISO 20022 formats CAMT.053 (Bank-to-Customer Statement) and CAMT.052 (Bank-to-Customer Account Report) in the future, as the potential benefits of these new formats become a reality relative to our needs. At present, it is too early to do so, as not all of our banks support these formats, and the pricing is higher than the current MT940 and MT942 messages that we use. For payments, we are considering migrating to ISO 20022 CGI (Common Global Implementation) formats, but once again, this will depend on our banks’ ability to accept them.

We currently receive ACK/NAKS (pain.002) formats i.e., payment status notifications. Currently, we receive these from FIDES via email, but we intend to implement this in SAP BCM. In addition, over the next six to nine months, we are looking to implement various enhancements to SAP TRM, including automated confirmation of FX deals through MT300 messages, a treasury ‘cockpit’ for easier navigation through treasury-related transactions recorded in SAP, EMIR, FinfraG (and potentially Dodd-Frank) compliance. We also intend to enhance our graphical reporting capabilities using SAP LUMIRA, part of the BI Suite offered by SAP.

We are also considering further developing our payment factory to include payment-on-behalf (‘POBO’) and potentially also expand to collection-on-behalf (‘COBO’) leveraging the SAP In-House Cash module. In particular, as a number of banks now offer ‘virtual account’ solutions, we would be able to reduce the cost and administrative burden of centralised collections and COBO within a limited budget.