SEPA, SAP and Winshuttle

By Clinton Jones on February 8, 2013

One euro coin on the financial pages of a newpaper. Narrow focus on the area around the word euroCompanies in the Euro zone will soon be hitting the EU regulatory D-Day of the Single Euro Payments Area (SEPA). If you’re an existing SAP and possibly Winshuttle customer, you are likely wondering how you’ll meet the deadline in time.

Where do you start with your effort and what can you do about making payments after 01 February 2014 if your SEPA initiative is incomplete?

First off, you’ll need to understand that SEPA is not an IT project. It has much deeper ramifications for your finance department, cash flow and relations with your business partners. From a pure banking perspective SEPA splits EU banks into three types – those big enough to do it, those small enough not to, and those in between who have no clue what to do. Perceptions largely indicate that there is no real consumer need for this ability, but there is a need for businesses with cross-border or multi location European operations.

So again, depending on a company’s particular circumstances there may be few or many issues with the implementation.

Some background to the initiative

In January 2008, the Single Euro Payments Area (SEPA) came into effect. SEPA is the result of actions taken by the banking industry in 2002, when the industry created the European Payments Council (EPC) to define the standards, frameworks, and rules for euro payments.

SEPA enables citizens, companies and institutions to make and receive payments in Euros within Europe, whether between or within national boundaries, under the same basic conditions, rights, and obligations, regardless of their location.

The political driver behind SEPA is the European Commission, along with the European Central Bank. The EPC, acting as the banking industry’s coordination and decision-making body of this self-regulatory initiative, refers to SEPA as Europe’s largest payments initiative.

SEPA will apply to all EU and cross-border euro payments within and between the 27 member states of the European Union (EU), the three European Economic Area Countries, and Switzerland. All of these countries will gradually harmonize their payment systems and procedures. This goal is that this will mean establishing European standards for processing payments, reducing barriers to market entry, increasing efficiency, and lowering transfer costs. Account Code Formats SEPA began as mentioned, as a unified cross border and universal format for funds settlement in the European banking arena.

A number of deviations from the original plan have resulted in the original specifications being changed for Germany and Austria for example. Here they differ from the European Payments Council requirements. Accordingly, special handling is required in SAP for these as they don’t follow the standard EPC format.

Existing national payment formats are proposed for retirement from February 2014 in favour of the new formats. The EU regulation says that from February 2014 onwards, these payments need to be delivered to the bank in ISO 20022 format. These could pure ISO 20022 format, which is only accepted by a small number of banks or as an alternative, the CGI format supported by SWIFT which has been in use for some time. Again, this format is supported only by a few large banks.

Payment Method Configuration

From an SAP perspective, you can customize two different payment methods in your SAP system – one for ‘classic’ international payments (USA, Australia etc.) and a second one for international payments to IBAN compliant countries.

In the vendor master data you can then specify, which payment method(s) can be used for this particular vendor. If you want to use a generic payment method for all international payments, the flag ‘IBAN mandatory’ has of course to be deactivated; as such a payment method is also relevant for countries not using the IBAN at all.

In such a case you need to carry out the following two actions:

  1. The IBAN has to be setup as mandatory in the vendor- / customer- master-data maintenance for particular countries (not included in the standard functionality, but possible with application of note 1477691)
  2. The DME program has to handle the IBAN with higher priority than the account number, when both values are available (depends on DME format). The recommended approach is still to use two different payment methods (for example T for non-IBAN-payments and S for IBAN-payments).

Companies will need to update their systems to support both international bank account number (IBAN) and bank identifier code (BIC).

SAP ERP Financials supports IBAN functionality that includes new options to support the initiative. One option is there is no longer a need to specify a national account number before an IBAN. In addition, one has an IBAN that is more visible and has the value presented next to other bank details from the master record.

IBAN is more than just Accounts Payable

Additional factors to consider are that IBAN data updates for SEPA are not exclusively the domain of the Accounts Payable for suppliers department, there are also actions that need to be performed to ensure that other business partners like employees, have the correct bank account information reflected in the HCM system. This is particularly important for reimbursements and payroll.

All indications are that if you use an LSMW approach to achieve the changes and the IBAN number for HCM PA30 changes is dependent on ALE and possibly DOC processing, you may not be able to use a batch input method to generate the IBAN information. Accordingly you may want to consider using GUI Scripting if you find that Batch or NON BATCH methods do not work. Although slower, GUI Scripting does give you the advantage of still being able to automate the process.

Useful SAP notes and SCN articles to look at on IBAN and SEPA:

**Please read the entire article in particular the piece about note 971175

Questions or comments about this article?

Tweet @uploadsap to continue the conversation!