In 2012, Autoneum’s treasury department faced several challenges in regards to transparency over liquidity, payment transactions and payment execution. Autoneum, a Swiss automotive industry supplier, has centralised treasury operations. However, it had more than 100 bank accounts globally across the legal units, over 45 bank relationships and large positions of locally based cash with many non-core banks.
In terms of systems/IT landscape, Autoneum had an outdated treasury management system (TMS) and an outdated enterprise resource planning (ERP) system. Most of all it had no standardization in transmission of payment files or banks statements and there were multiple systems in place.
For preparation and release of payment runs, everything was done locally with limited transparency for the company headquarters in Winterthur. Before the start of the project, accounts payable (AP) payments or treasury transfers were paid either through local structured host-to-host connections, disparate e-banking systems, or even by using fax payments in some cases. In short, there was little alignment of payments processes.
In July 2012, Autoneum launched a global project to roll out standardized business processes, using SAP as its new ERP. SAP was rolled out to two to three entities per year, beginning with the Swiss entities.
At the time, treasury was in the process of a TMS evaluation. As a result of the analysis, SAP Treasury and Risk Management (TRM) was selected in September 2012. This was the logical choice, given that Autoneum already had SAP integrated into its ERP landscape.
Autoneum used EPROX Consulting to implement SAP’s treasury modules. The changes needed for the short-term were centralizing transmission of payment runs and bank statements and forming a single gateway to banks. The SAP treasury modules have been made available to the local entities.
Establishing a payment factory
The implementation of a payments factory was a core element of treasury’s SAP project. It was born out of a desire for greater transparency and full daily overview of cash/liquidity and payment outflows through a standardized approach. Autoneum’s goals were to:
- Use MT940—the SWIFT international format for receiving bank account information for processing in financial software applications—for treasury and accounts receivable (AR)
- Gain better visibility into cash globally
- Choose the ‘right’ banks
- Reduce bank account numbers
- Create a more aligned approach to connecting legal entities to their banks, using a single interface and a standardized process.
In short, the target was to create a payments factory. But what is the meaning of such a solution? To Autoneum, it means the centralization of payment flows for treasury and AP payments. Additionally, it includes a process involving the transmission from legal entities’ ERP to a central connectivity solution, centralizing execution of file transfers in a way that is effective and low-cost, and enabling transfers via one central bank connection or interface to the appropriate bank relation and account.
Payments on behalf of (POBO), or collections on behalf of (COBO) are considered a ‘nice to have’, but they do not figure yet in the process. Basically, Autoneum is concerned with the transmission of files from the ERP to the bank partners.
How to connect to the banks?
Autoneum had a history with the Swiss service bureau Fides Treasury Services in regards to daily collection of MT940 and MT942 message protocols. For payment execution, Fides offers connection to the banks either via SWIFT or EBICS (Electronic Banking Internet Communication Standard).
EBICS member countries include Germany and France, Switzerland. Other countries like Spain, Portugal are also likely to join. Using EBICS doesn’t lead to additional transactional fees (as is the case by using SWIFT), has lower (or no) implementation costs for the banks involved, and allows Autoneum to forward payment files to countries outside of EBICS (UK or China). On top of that, Autoneum has found that so far, EBICS projects seem to be by far less complex to get established (testing, setup, etc).
Autoneum looked at where it was possible to use the ISO 20022 standard to its advantage. It evaluated a few service providers and also the possibility of using SWIFT Alliance Lite for the whole process.
Ultimately, Autoneum decided to use Fides as a service bureau. AP and treasury payments go from SAP’s Bank Communication Manager (BCM) to the middleware (a SFTP connection between Autoneum IT and Fides IT) and then out to banks via SWIFT or EBICS.
The payment factory was rolled out in Switzerland in 2013 (three management entities, and one operational entity with one plant). In 2014, the payment factory was rolled out to the US and Canada (two entities with seven plants), followed by France in 2015 (four plants). The remaining Autoneum entities will follow in the next few years.
All entities were connected via FIDES—three Swiss banks and one euro bank via EBICS and one US/Canadian bank via own Autoneum BIC also hosted by FIDES.
Obstacles and lessons learned
In the 2013 Swiss entities rollout, the main lessons learned were the importance of managing both external and internal dependencies. The former included having appropriate testing windows and converter settings with Fides—Autoneum was of course not the bureau’s only client—and also getting the right format definitions with the banks. The latter included managing the accounting team (e.g. getting test files created), the setup of testing and development mandates and the impact on bank connectivity in SAP (middleware configuration). The final lesson was the vital importance of correct and uniform master data for payment execution.
The 2014 rollout in US and Canada presented its own challenges for the company. The chief lessons learned were ensuring enough time for preparation, planning and testing. The project involved four different parties and two time zones, and that increased complexity. The bank’s internal project guidelines added time (several user acceptance testing cycles, testing freeze and schedules for checks). ACH formats were also a challenge (CTX, CCD, PPD, etc). It was very important not to rely purely on local knowledge, particularly in preparation of local US electronic payment formats, as a common reply was “I don’t know, we always paid by check”.
The main challenge overall for both elements of the project was that of change management—the pushback of “we’ve always done it like this and it works.”
Autoneum continues to evaluate POBO and COBO. For sure it is an interesting approach for the entities located in the eurozone, but the tax and legal investigations to be done first (with related costs) have been the main reason to postpone this piece of the project. On top, bank statements’ formats potentially could get amended by moving from MT940/942 and onto CAMT.053/CAMT.052 if the benefits apply for Autoneum.
Another important aspect is to receive the information about acknowledgements or rejections from Fides and the banks (so called ACK/NAK files in SWIFT terminology or PAIN.002 for the SEPA/XML world) back into SAP. A kind of “traffic light structure” (green, yellow, red) in SAP’s BCM module could then provide a fast overview about issues in the payment factory landscape.
Janko Hahn is head treasury operations at Autoneum in Winterthur, Switzerland.