Autoneum’s Payment Factory Implementation: Lessons Learned
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 standardisation 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.
Getting Started
In July 2012, Autoneum launched a global project to roll out standardised 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 centralising 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 standardised approach. Autoneum’s goals were to:
In short, the target was to create a payments factory. But what is the meaning of such a solution? To Autoneum, it means the centralisation 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, centralising 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 ‘nice to haves’, 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, France and Switzerland. Other countries like Spain and Portugal are also likely to join. Using EBICS doesn’t lead to additional transactional fees (as is the case with 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 Autoneum BIC also hosted by Fides.
Obstacles and Lessons Learned
In the 2013 Swiss entities rollout, the main lessons learned involved 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 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 the 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 freezes and schedules for cheques). 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 cheque.”
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.”
The Future
Autoneum continues to evaluate POBO and COBO. 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.