Case study: Payment Factory - a worthwhile disruption?

Jun 11th 2015 |
Company name Autoneum Group
Industry Automotive
Company headquarters Winterthur, Switzerland
Company turnover (USD) CHF2.053billion ($2.1 billion 2014)
Stock listed at Six Swiss Exchange, Switzerland
Case study geography Global
Person interviewed Janko Hahn, Head Treasury Operations

Summary

This is the story of the rationale behind Autoneum Group setting up a payment factory, its own definition of a payment factory, the centralisation required before the roll out, the use of Swift/EBICS, the importance of the ERP system, the measurement of success and future plans to extend to other countries. Also, it discusses the decision not to use POBO/COBO at this stage. This case study was presented at EuroFinance Miami 2015.

Want to know more about how different companies are approaching payments?
Attend Stream 6 at EuroFinance Copenhagen 2015. Find out more >

Video: Interview with Janko Hahn, Head Treasury Operations, Autoneum Group

Brief description of treasury operation

Technology employed includes SAP and the service bureau FIDES to access SWIFT or EBICS in regards to bank connectivity for payment transmission and execution. In 2012 the company centralised treasury operations (on the HQ in Winterthur) and had two FTEs [full time equivalents] globally for treasury operations based in the HQ.

The company is listed on SIX (Swiss Exchange), EBIT margin in 2014 was 6.9%, around 50 locations worldwide, represented in more than 20 countries and has over 10,000 employees.

EuroFinance commentary

Autoneum’s payment factory is a response to the company’s need to have better visibility and oversight of cash and liquidity and to go for standardized and centralized processes also for payment file transmission & execution. Using its new ERP as a treasury management system has opened the way to integration. Here Hahn outlines how the company leverages EBICS and the SWIFT capabilities offered by a service bureau to connect to its banks, the savings made to date and where the project aims to go next. The project highlights the benefits of successful master data management and change management – key topics for a successful ERP implementation project (which is the basic structure on top of which the treasury management modules are added in SAP).

The case study

Autoneum is an automotive supplier to original equipment manufacturers (OEMs) – it specialises in acoustic and thermal management for vehicles. Autoneum’s products help to reduce not only noise and heat but also a vehicle’s weight, fuel consumption and emission output. It operates in 50 locations globally, spread over 20 countries.

Starting out (2012):

The problem Autoneum treasury faced in 2012 was that although it had centralised treasury operations it had more than 100 bank accounts globally and had more than 45 bank relationships and large positions of local-based cash with many non-core banks. In terms of systems/IT landscape it had an outdated treasury management system, and an outdated ERP (BPCS). Most of all it had no standardisation in transmission of payment files or banks statements and there were multiple systems (for instance Mammut, many different e-banking portals and local flavours).

For preparation and release of payment runs everything was done locally with no transparency for the HQ in Winterthur. There was no MT940 working in the ERP for electronic bank statements and bank statements were paper based and also booked manually.

Before the start of the project AP payments or treasury transfers were paid via local structured host-to-host connections, via disparate e-banking systems, or even by using fax payments in some cases.  In short, there was little alignment of payments processes.

The project

The treasury SAP project had the implementation of a payments factory as a core element. It was born of a desire for greater transparency and full daily overview of cash/liquidity and payment outflows through a standardised approach. It wanted to use MT940 (the SWIFT international format used to receive bank account information for processing in financial software applications) for treasury for major bank accounts and accounts receivable and to have better sight of cash globally (transparency). It also wanted to choose ‘the right’ banks (core bank focus), reduce bank account numbers and create a more aligned approach to connecting legal entities to their banks using a single interface and a standardised process.

In short, the target was to create a payments factory. What does that mean? To Autoneum it means the centralisation of payment flows for treasury and AP payments and 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, or collections on behalf of ‘would be nice’ but they do not figure yet in the process. ‘A payment factory is how I transmit from the ERP in a standardised and centralised way to connect to banks.’

The evolution of the payments factory

The treasury project evolved out of the global project of process re-engineering to rollout standardised business processes globally using SAP as the new ERP. This started in July 2012. The target is two to three rollouts per year and the project started with Swiss entities, which went live in 2013. 

Group treasury was just in the process of a TMS evaluation in mid of 2012 when then decision was made to establish SAP as the new global ERP. As a result of the analysis, SAP TRM (the treasury modules of SAP) was selected in September 2012. The in house cash module was licensed for future use. The decision was made to use SAP given (mainly) the benefits of first, the high integration into the ERP landscape and, secondly, facing a greenfield project where a lot of treasury needs and ideas could be implemented in the global design. The consulting partner EPROX consulting was used for SAP 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. Treasury modules have been made available to the local entities in case they could benefit from those.

Who to use for two-way connection to banks?

Autoneum had a history with the Swiss service bureau FIDES with a history of daily collection of MT940 and MT942 message protocols. Now for payment execution FIDES offers a hybrid approach: either connection to the banks via SWIFT or via EBICS (Electronic Banking Internet Communication Standard).

EBICS member countries include Germany and France, Switzerland and other countries (Spain, Portugal) most likely will 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 lets Autoneum get payment files forwarded within the banks to other 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 format ISO20022/XML to best advantage. It evaluated a few service providers and also the possibility of using SWIFT Alliance Lite for the whole process.  It offers easy cloud-based linkages to SWIFT, no expensive and complex IT investments are needed and it allows independence from third party providers.

Although Alliance Lite as a plug-in was an interesting option, Autoneum decided that it worked best if the company was only connected to a few banks and by using a few payment instruments only (eg MT101) – both did not apply. The uncertainty in regard to the number of banks to be connected, the uncertainty around consulting costs and the fact that internal IT capacity to cover format definitions internally was missing finally spoke against this solution.

Ultimately, Autoneum decided to use FIDES as a hybrid service bureau solution. That means AP and treasury payments go via SAP’s Bank Communication Manager (BCM) to the middleware and from there via FIDES out to (and bank statements/payment confirmations back from) banks via SWIFT or EBICS. 

Want to know more about how different companies are approaching payments?
Attend Stream 6 at EuroFinance Copenhagen 2015. Find out more >

The state of play now

The payment factory was rolled out in Switzerland in 2013 (three HQ and management entities, one operational entity with one plant). In 2014 the payment factory was rolled out to the US and Canada (two entities with seven plants) and in 2015 the payment factory was rolled out in France (four plants). Spain and Portugal will also follow in 2015.

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 roll-out the chief lessons learned were the importance of managing both external and internal dependencies. The former included having appropriate testing windows and converter settings with FIDES (the company was of course not the only client of the bureau) and also getting the right format definitions with the banks. The latter included managing the accounting team (eg getting test files created) and the setup of testing and development mandates and the impact on bank connectivity in SAP (middleware configuration). The third lesson was the vital importance for payment execution of correct and uniform master data (elementary questions were raised such as ‘how many digits does SWIFT have?’ and ‘what is an IBAN?’.)

The 2014 roll-out in US and Canada presented its own challenges for the European 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 UAT cycles, testing freeze and schedules for cheques). The definition of ACH formats was 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 importance of the hyper-care phase must not be underestimated, also the time it took to continuously reduce the cheque volume and move to standardised electronic payments.

The main challenge overall for both elements of the project was that of change management, the pushback that ‘we’ve always done it like this and it works.’ Training is at least part of the answer.

Achievements (thus far)

The project has achieved bank connectivity with one single gateway to the banks and from and to SAP TMS in a straight through process setup. There is a stable SWIFT connection for the US/Canadian bank. Local payment formats have been avoided (ie bills of exchange in France). The number of cheques issued in US and Canada has gone down from 1,000 a month to roughly 200. The process is considerably more transparent with the lack of manual entry of bank statement data and direct upload of bank statements to the TMS and ERP. There is now a uniform approach to approve and release payment runs. In terms of bank relationships there is a focus on core banks with respect of business such as payment execution and once all rollouts are complete there is a target for seven to eight core banks (not including local banks). Local bank relationships have been cut – ie in the US and Canada there is one remaining bank by June 2015 from five in 2013. 

Transactions costs have come down (fewer banks get more volume and give better pricing) and avoiding or reducing local instruments such as cheques has cut bank fees. How much has been saved? Hahn is working on the metrics but some quick wins are obvious: the cost per cheque in the US (including workload, IT infrastructure, etc) is easily five times as high compared to ACH payments. With a reduction of the cheque volume by 80% the savings are enormous.

The future

Autoneum continues to evaluate payment on behalf (“POBO”) and collections on behalf (“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.”

Bank statements should be moving from MT940/942 and onto CAMT.053/CAMT.052 if the benefits apply for Autoneum. However, not all banks are ready yet and some banks also charge more for using those formats. 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 (Bank Communication Manager module) could then provide a fast overview about issues in the payment factory landscape.

SAP Treasury enhancements should also lead to further benefits. These include automated confirmation of FX deals with banks (MT300), a treasury cockpit which will mainly assist the local end users to find their way through the various relevant treasury transactions in SAP easier. On top of this, requirements to comply with several new local regulations should be implemented, covering mainly compliance aspects of EMIR, FinfraG and potentially Dodd-Frank. “Currently the look and feel of SAP Treasury reports isn’t ideal, but it should improve.”  Microsoft BI use should improve reporting and data analysis by graphs. Finally, Autoneum now plans to implement the SAP in house cash module in 2015. 

Want to know more about how different companies are approaching payments?
Attend Stream 6 at EuroFinance Copenhagen 2015. Find out more >

MENU