The Single Euro Payments Area (SEPA) was conceived by the EU to simplify financial transactions between countries trading in Euros. SEPA will introduce a standard payment format (XML based) which will cover 3 transaction types:
- SCT – SEPA Credit Transfer
- SDD – SEPA Direct Debit
- SEPA Cards Framework – Credit/Debit card transactions
In order that payments to and from banks and bank accounts in different European countries are made more efficiently (the aim of SEPA being that intra-country payments/receipts should be as easy as domestic ones) SEPA uses two codes which are effectively equivalents to the account number and sort code that we know and love:
- BIC – Bank Identifier Code (aka SWIFT codes) – uniquely identify financial institutions across the globe
- IBAN – International Bank Account Number – an internationally recognised format of a bank account number which actually includes the national formatted account number(aka BBAN or Basic Bank Account Number) as well as ISO country code and check digits
Using these codes and a standardised XML payment format SEPA will simplify the way in which Euros and used across the EU, but what does this all mean for the average E-Business Suite user in the EU?
Firstly, and not specifically related to Oracle users, to pay/receive funds in Euros you need to be using the SEPA format by February 2014.
These are the other main areas you need to consider:
- Your customer/supplier data. Your customer and supplier bank accounts need an IBAN and your bank branches need a BIC in order to use SEPA. If your volume of distinct bank accounts is relatively low then you simply ask your suppliers and customers to provide the BICs and IBANs. For larger customers you can ask your own bank to do it for you. For very large customers you can engage the services of a 3rd party like APRO who will use their own software to convert your existing national format banking data into the SEPA standards. Once you have this data you need to update your bank branches and bank accounts. Fortunately in R12 there are some handy PL/SQL APIs which will do the job for you. Claremont is working with a variety of different sized organizations faced with this task at the moment. From the technical perspective the solution is one-size-fits-all, its really just a question of how long it takes to get hold of the right data.
- Patching. There are patches which implement the different bits of SEPA (credit transfers and direct debits) and then there are, in some cases, other patches required to fix the changes made by the SEPA patches. Get your patch list together earlier and carry out your own internal testing before your payment files get anywhere near your bank.
- Testing. You need to engage your own bank to test the SEPA XML files you will generate from E-Business Suite. In some cases this proves to be more of a challenge than it sounds as the resources at your bank to carry out this testing are probably getting busy testing the files of other clients. One of Claremont’s clients has already come under some pressure from their bank to start implementing SEPA so that the bank can guarantee the availability of test resources.
- Usage. If you have a large number of customers and suppliers how are you going to operate your pay groups? You may want to consider a specific SEPA pay group bearing in mind that SEPA operates across 31 countries, the BIC & IBAN are required for these payments and SEPA uses a new payment format. There are also a few smaller changes in the way payments are made e.g. a restricted list of characters which can be used in SEPA batch names – including no spaces.
Claremont is already working with SMEs and a multi-national corporation on SEPA implementations, both in R11i and R12 and are happy to talk to you about any requirements your company may have.