EuroFinance 2012: Q&A with Damian Preisner, Global Treasury, SAP Germany, and Gerd Klevenz, Head of Treasury Operations, SAP Germany
SAP is a global software vendor, headquartered in Germany, with annual turnover of €14bn. The company’s treasury team is made up of 30 employees, is organised centrally and uses a treasury management system (TMS) that is part of the SAP enterprise resource planning (ERP) system.
Question (gtnews): What were the main discussion points during your session entitled ‘Changing Standards: Is Anyone Using Them to Strategic Advantage?’ at EuroFinance 2012?
Answer (Damian Preisner, global treasury, SAP Germany):
The session examined the business case for moving to the ISO 20022 XML payment standard now and the amount of preparation still needed on the banks’ side. The financial industry is being pushed to adopt XML by the single euro payments area (SEPA) end date, but there is much more to it than SEPA Credit Transfers (SCTs) and Direct Debits (SDDs).
The Common Global Implementation (CGI) initiative, which includes banks, software vendors and corporates, is trying to develop a more standardised global approach to payment formats. Its aim is, to quote, for “a corporate to be able to use the same message structure for all their payments with all of their transaction banks reaching any payment system across the globe.” SAP participates as a software vendor, so treasury is not involved directly but we have chats with our colleagues who are.
A standardised global approach will provide a level of bank interoperability that has not been reached before. Previously, there were other so-called global formats, such as MT 101 or Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT), but now XML has begun a new journey. SEPA is a part of that journey, and the CGI and the new version just agreed by banks and software vendors should be another step in that journey to support corporates operating globally.
Question (gtnews): Are banks keen to adopt the ISO 20022 XML standard?
We have worked with two banks, the Royal Bank of Scotland (RBS) and Bank of America Merrill Lynch (BofA Merrill). It requires significant investment from the banks, but it provides them with better transparency and visibility. A few banks truly understand that transparency is an advantage, not a disadvantage. That means that only a few will make that investment; if a bank believes that this is its core business, then it will invest.
Question (gtnews): Are corporates adopting the XML standard?
SAP is an early adopter, and one of the corporates which are ahead of others since we use only one SAP version for all subsidiaries and have set up a payments factory. In the past few months I have discovered other early adopters, each facing specific pain points. Every company has its own organisational history and is confronted by different challenges with regards to master data, processes and shared services. It is difficult to compare, but there are some common experiences.
For example, some corporate treasury departments are solely responsible for treasury payments. They need to cover critical payment types with the XML format on a global scale but they may not have the volume within treasury needed to make this a feasible option. Others are considering XML from a SEPA-compliance perspective – they have to be compliant and instead of tweaking an old format in one country, they see the potential of standardising payment files at a global level. If you go that extra step and cover most of your entities, then it gets progressively easier to support payment files. The end point is when you only need IT knowledge based on XML. Currently if there is a problem with a German payment file, you need someone who knows the structure of a German payment file; or if there is a problem in France, you need to understand the French rules. SEPA is a trigger for many corporates to adopt XML.
This is a great chance for treasury to explain how an XML migration can provide efficiency savings for IT because they do not have to support local formats. At SAP, treasury tries to find benefits for all stakeholders.
Question (gtnews): Did you start the journey from a SEPA-compliance perspective?
The XML project was connected to the integration of a newly acquired corporation for which we had to deliver new payment files out of the ERP system. It was the right time to connect closely the two initiatives and work with banks in the CGI group to deliver the new format.
We took the chance to innovate. It was a strategic decision not to use the old payment file but to innovate instead. We had some early adopter pain points, but we have a holistic approach as a software vendor. We want to reduce the pain for our customers by solving problems in advance so that no one else has to experience them or at least “limit the pain” for the customer.
Question (gtnews): Moving on, Gerd what were the main discussions points during your session entitled ‘Centralising the Treasury Function Can Mean Different Things’?
The panel, which included Irina Bobrysheva, head of group treasury, Severstal, and Rudmer Wedzinga, international treasurer, Coty, discussed what a global infrastructure looks like for treasury. The main discussion points were around how treasury can achieve transparency with regards to cash: where is it, how much is there, what are the different approaches, etc. Everything came back to how important good data is as a basis for sound decisions.
The panel consisted of three corporates – a retailer, a large steel conglomerate and an ERP software provider – with different approaches due mainly to the business model. Severstal, for example, has to focus on commodity risk, which is not a topic for SAP. Foreign exchange (FX) risk is top of mind for all three, but with different flavours.
At SAP, we have a special approach to managing FX risk by securing the balance sheet of each legal entity. The euro is the group’s functional currency as a German company. If a Swiss legal entity has local currency Swiss francs, then it is exposed to risk in case of euro invoicing. From a group perspective, some companies wouldn’t hedge because it gets converted one-to-one to the group balance sheet. However, we will hedge because we want to secure the local profit and loss (P&L). If a company has a large euro exposure in Switzerland and doesn’t hedge, then the local entity will suffer if the market moves in the wrong direction. We try to ensure that the local subsidiary hedges its exposures, not externally with the bank but with SAP AG. Then we look at the exposure from a group perspective and hedge it externally in the market.
The panel also discussed how to centralise liquidity, which raised differing opinions. One treasurer said that their company uses zero balancing with cash pools across different currencies. SAP, on the other hand, focuses on zero balancing in euros and US dollars only. We don’t centralise other currencies daily, but rather on a monthly basis to avoid daily changes in our FX exposure. We also discussed problematic countries for extracting money, such as China, India and South Africa.
For all these risks we depend on our ERP system to get information in real time. We get most of the risk data from the accounting/financial system of SAP. Our TMS, which is part of the ERP system, is then used to enter hedges.
Question (gtnews): What do you think were the hot topics at this year’s EuroFinance?
Executing on the ISO 20022 XML file is a hot topic because having a plan is just a small part of the whole project – execution and going live takes a lot of time.
The SEPA end date is putting a bit of pressure on the industry; however solely focusing on SEPA misses the bigger picture. The journey has started and SEPA is one milestone, but the whole industry could go further. Treasury should take this as a chance for further investments to restructure or rebuild whatever is there, not only in payments but looking at other business processes as well.
We haven’t touched on the transmission channel for the payment files. It is counterproductive in a shared service environment if corporates have to use a variety of electronic banking (e-banking) systems to serve different countries. In the end someone ends up with 10 different tokens to administer these payments. It is also difficult to centrally control a variety of e-banking systems which are partly maintained in Cyrillic, Hindi or Chinese characters, so compliance becomes an issue.
All these multiple channels should be reduced to a minimum or in a best case scenario to one channel – for example in a global payments factory -. SWIFT could be part of the solution because it eliminates proprietary banking connections.
Yes, if treasury deals with several banks, SWIFT might prove to be a good solution. If you have a single banking infrastructure for most of your payments then a host-to-host connection might be acceptable. For us it is SWIFT.
As we said before, every corporate is set up differently. If you have one or two banks, then it doesn’t make sense to invest in one pipeline such as SWIFT; instead it makes sense to invest in proprietary e-banking connections. But that set-up may restrict you – in a crisis you never know whether the bank you are with today will be there tomorrow. You have more flexibility with one channel that is ready for multiple banks. From an end-to-end perspective, if a XML payment file format, which contains all the data needed, is extracted from the source system, accepted by many banks and routed through a multi-banked channel such as SWIFT, then you have the possibility of being more flexible to change bank for any reason.
Question (gtnews): Is there is one thing that would make treasury more efficient?
That is easy: having direct access to IT resources in order to be able to react more quickly. That is an issue even for SAP treasury – we do not have immediate access to developers because they have to focus on developing. Having access to IT resources is critical, no matter if it is internal or external developers or consultants.