The 5 biggest mistakes that companies will make during SEPA migration
As Europe inches ever closer to the SEPA migration deadline and companies progress further in their SEPA preparation efforts, there still appear to be a number of obstacles that are tripping up organisations in their migration projects. We have outlined below what we believe to be the 5 key mistakes that companies make in preparation for SEPA along with some advice on how your organisation can avoid them.
1. Don’t forget about payroll
This may sound obvious at first but it is surprising how many companies do just this. Even large corporates with access to boundless project support, teams of people at their disposal and comprehensive SEPA migration plans in place seem to overlook this simple step.
Such was the case for British American Tobacco, a tobacco company based in London making electronic payments all over the Eurozone, who had to completely overhaul an early draft of their SEPA migration plan because of the omission of one crucial element: the payment of staff.
Fortunately the company was able to address the problem and quickly get their migration plan back on track. The lesson here of course is – don’t overlook the obvious things.
2. Don’t leave XML testing until Q4 2013
The new format required for the submission of electronic payment files (XML ISO 20022) is not easily comprehended and its complexity will mean that there will be both human and machine errors made on the road to its universal implementation. The fact of the matter is that the transfer of money is too important an operation to allow for even the smallest margin of error.
The best way to guard against this is to test the validity of the data produced by your accounting or ERP system against your bank’s systems by performing penny payment i.e. electronic transfers that amount to no more than a few cents. This is the approach that the majority of European businesses are taking in preparation for SEPA. The problem is that they are all planning to do it at the same time.
A situation like this will probably mean that the banks will be inundated with test payments come Q4 2013. It is probable that the majority of banks will lack the capacity to provide comprehensive testing for all their clients. For those considering using an online verification app, be advised that different banks will be using different version of the XML pa.in schema. So before placing all your faith in an online validation service be sure to confirm that the files are being validated against your bank’s version of the schema.
In order to avoid a situation like this, European companies should start XML testing sooner rather than later.
3. Data quality – check it, then check it again
A number of companies will have customer and supplier account information on record that they will need to convert to BIC and IBAN format before they can effect any post 1st February 2014 payments. A further sub-set of these companies will be considering compiling this data into a spread sheet and ploughing it into a conversion app in the hope of completing their database enrichment in one fell swoop.
We strongly advise against taking this route. The attractions of the process are obvious: speed and simplicity. However what the company could be putting at risk is far more important: the quality of its data. Aside from the obvious errors that could be made in the process of compiling data from a number of sources, one should also bear in mind the real risk that what is being submitted for conversion may not in fact be actionable banking data.
When one is using an online conversion service it would be advisable to bear in mind that although such applications may provide you with the mathematically correct IBAN, it may not necessarily be the real account number. Our advice in this case is simple even if its implications may not be: the only way to acquire actionable SEPA account information from customers and suppliers is to ask them for it.
4. Prepare to start managing your mandates
With regards to direct debits, in a number of European countries it has traditionally been the responsibility of the debtor’s bank to store hard and/or soft copies of mandates that the debtor uses to make payments to payees. However with the mandatory transition to SEPA, the onus will now be on the creditor to manage the mandates of its payers.
Although a number of companies have configured their payments software and online banking systems to allow for the processing of SEPA direct debit instructions, very few have considered the importance of making storage space (both physical and electronic) for customer mandates.
It should be remembered that under SEPA legislation companies will be required to store mandates for a full two years after they have expired to allow for the performance of refunds, returns and other legislative obligations. Our advice is to introduce a comprehensive filing system and free up substantial space on the company’s server for the future storage of SEPA direct debit information.
5. Direct Debit scheme: B2B or B2C?
There has been some confusion of late as to what SEPA direct debit scheme companies should be subscribing to. For a lot of companies there won’t necessarily be a choice as many banks are only signing up to one scheme or the other. However there are a number of banks who will be operating both schemes in tandem.
While it may be a little unfair to label a company’s decision to follow one path or the other as a ‘mistake’, it is nonetheless practical to consider the repercussions that could stem from the subscription to a scheme that doesn’t fit with the organisation’s payments profile.
The most glaringly obvious difference between the two schemes is the enhancement of customer rights under the SEPA B2C (Core1) scheme. Direct debit payers will be entitled to a ‘no-questions-asked’ refund up to eight weeks after the completion of the payment. Of course this could have serious repercussions for any business collecting a high volume of direct debits and if the company wishes to avoid this potential credit risk then they would do well to avoid this scheme entirely.
The B2B scheme on the other hand negates these refund rights by swapping them for a system founded on the preauthorisation of payments by the debtor company subject to an agreement with their bank. This means that while payments will be processed with a minimal threat of reversal, the process of preauthorisation could greatly slow down the collection of payments.
Ultimately the company may need to weigh up the tradeoffs between security and speed and make a decision based on the cost-benefits to the company.
