For several years, Treasury& Risk has covered the impending Single Euro PaymentsArea (SEPA). We've explained the technical details of how systems need to change toaccommodate SEPA credit transfers and SEPA direct debits. We'vediscussed ways in which some companies are leveraging their compliance efforts toimprove payment processes across Europe and beyond. We coveredfearslast fall that businesses would be unprepared to comply by theFebruary 1, 2014 deadline. And then, of course, we covered theextension of the deadline to August of this year.

Now that we're six weeks past the original SEPA compliancedeadline, we thought it would be a good time to take the pulse onhow large corporates are faring. To what degree are European credittransfers and direct debits SEPA-compliant today? And to whatdegree have organizations taken the extra step of improvingaccounts receivable (A/R) or accounts payable (A/P) processes asthey've revamped their technology infrastructure to meet SEPArequirements? To find out, we sat down with Ad van der Poel, theBank of America Merrill Lynch product executive for payments andreceivables global transaction services for Europe, the MiddleEast, and Africa (EMEA).

T&R: First of all, what is thestatus of SEPA readiness at companies across Europe rightnow?

Ad van der Poel: If you look at themarket numbers from February, at that point 94 percent of credittransfers in the Eurozone were SEPA-compliant, as were 80 percentof direct debits. And my guess is both of those numbers will risesubstantially over the coming months. At Bank of America MerrillLynch, we are almost at full migration for our clients. We don'tserve the SME [small to midsize enterprise] market in Europe—onlylarge corporates—and almost all of our clients are nowSEPA-ready.

The main reason the direct debits number isn't close to 100percent is that some larger corporates shifted their approach toSEPA compliance slightly when the European Commission announced thesix-month transition period. By that time, they were all in themiddle of their projects, which by now most of them have finished.But for companies that have multiple entities across a number ofcountries, the transition period provided a little breathing room.Their original intention was to go live with their SEPA system in abig bang, with all their entities at the same time. But with theannouncement of the transition period, they figured they don't needto take that risk. They decided to roll out their SEPA-compliantsystem entity by entity.

So suppose a multinational went live first in Belgium, where ithas smaller volumes; it is now using the remaining time untilAugust 1 to learn from its experience in Belgium, then it will golive consecutively in the Netherlands, Germany, France,Spain, and so on. A company like this is essentially SEPA-readytoday, but it hasn't migrated all its transaction volumes yet, sothe EC numbers wouldn't reflect it as fullySEPA-compliant.

T&R: OK. It sounds like thetransition is mostly complete.

AP: I would say so. The biggest challengeis in the SME market. Among large corporates, an extremely highpercentage is already SEPA-compliant.

T&R: Have you seen a lot of theselarge corporates leverage the SEPA compliance project as anopportunity to centralize and standardize payments or receivables?Has that been widespread?

AP: No, it hasn't been widespread;however, we are now talking to almost all our clients about it. Wehave some corporate clients that have taken the opportunity tostart centralizing processes and rationalizing bank accounts, butthese are the companies that started their SEPA compliance effortsmore than a year ago. For those that started late in the game, the push has been aboutcompliance.

Consider a corporate that has entities in five countries. Eachof those entities uses one or more domestic banks and has multipleaccounts with those institutions. So across the five countries, thecompany might have 50 bank accounts. A typical company in thissituation has been working so far to make sure all theinfrastructure for those 50 bank accounts is SEPA-compliant. Thenext step is for management to look at how they can centralize andrationalize the number of bank accounts they use. We see a lot ofthose conversations starting now, but only after the company hasbecome compliant.

T&R: Are there still anyobstacles to centralization and standardization once a company isusing SEPA-compliant systems and processes in differentcountries?

AP: Yes. The biggest issue is that SEPAhas variations in different regions. The devil is in the detail,and as we've all come to realize, it's not really a single paymentarea where everything is the same. In the next two to three years,the industry will be fine-tuning SEPA and hopefully will get rid ofmost of the variations.

T&R: What are some examples ofvariations?

AP: Well, there are many. The obvious oneis the use of the XML format for sending and receiving files. TheSEPA XML standard is part of the regulation, but there arecountries that have made slight variations to it. Germany, forexample, has added two data elements, two fields, to the format.Some other countries have done that as well, while others have not.Now, that may sound like a small thing. But if you're a corporateand you're active in multiple countries and you're trying tostandardize across them, then you aren't going to be able to usejust one file format; you're going to need to support multipleformats. That reduces the degree to which you can standardize yourdatabases and automated processes.

Another example of a variation that cancause problems are SEPA rejection codes. A certain number of directdebit collections are rejected, for one reason or another. Whenthat happens, the customer's bank sends back a rejection code thatcomes into the corporate's systems. Based on that rejection code,the company knows what its next step should be.

Think about a large mobile telephone company that does monthlydirect debits in several countries. It might like to centralize,but it has automated processes for dealing with payment rejections.Hypothetically, let's say rejection code 1 corresponds to'insufficient funds' and rejection code 2 corresponds to 'reasonunknown.' The company might have a policy of dealing with rejectioncode 1 by giving the individual two more days. So rather thaninforming customers that they don't have enough funds in theiraccount, the company might wait two days and try again. That willwork in some countries, but in others, for privacy reasons, banksdon't tell vendors when a payment rejection is caused byinsufficient funds. A problem that would receive rejection code 1in some countries will receive code 2, 'reason unknown,' in others.So if the mobile-phone company were to merge all its direct debitsinto a single system, this discrepancy would seriously complicateits automated handling of rejection notices.

T&R: Do these variationsgenerally stem from national regulations, or from differencesbetween banks?

AP: Some are caused by privacy concernsthat are triggered by national regulation. But there are alsoimplementations on the bank side that differ just because ofchoices the banks have made themselves.

T&R: Do you anticipate thatgovernments and banks will get these variations sorted out in a fewyears, so they will all handle rejection codes in the same way andwill use the same XML fields—and so companies will be able tocentralize and more fully automate their A/R and A/Pprocesses?

AP: Yes. I should make clear that theycan automate these processes now. We're helping our clients withthat. But they have to understand that rejection code 1 might meansomething different in the Netherlands than it means in Germany. Aslong as they understand what it means in each country, they canautomate it.

T&R: Well, but some banks handlethings differently, even within the same country, right? So would acompany have to build into its automated system the knowledge ofhow each customer's bank handles rejection codes?

AP: Exactly. It gets more and morecomplex as you start reasoning through this. I do expect thefinancial services industry to get together and start addressingthese variations. Whether we'll be able to resolve them 100percent, I don't know. But they are becoming a priority, even forthe European Central Bank and the European Commission, because theywant to make doing business in Europe as easy as possible.

T&R: And you think companies willstart to reap the benefits of standardization in the nearfuture?

AP: Absolutely. We are starting to havediscussions with our clients around all the things that have beenput forward as the benefits of SEPA. Companies are looking intoautomation and standardization, not only of file formats, but ofprocesses as well. As a result of that, they have the opportunityto centralize their processes and their receivables organization.And they can also rationalize their bank accounts and their numberof banks. When we start talking about these types of initiatives,we're really getting into the benefits of SEPA.

There's also a lot of talk right now about receivablesfactories. Receivables always used to be very localized, but nowwith SEPA direct debit, collections activities are the same in allthe Eurozone countries. On-behalf-of is a big deal as well. If you centralizereceivables or payables, then a centralized location will be actingon behalf of the local entity, and technically SEPA can capturethis information in an 'on-behalf-of' XML field. That optionsupports setting up a payments or receivables factory. Legal andtax analyses are needed to determine whether a company can doon-behalf-of in a different country, so we always advise ourclients to work with their legal and tax advisers as well as withus when considering such arrangements.

T&R: So, what do you expect to bethe long-term ramifications of SEPA for large companies operatingin Europe?

AP: For corporates that work in multiplecountries, it's enormous. Long-term, we'll see increasedcentralization, maybe even for midsize corporates that are activein multiple countries.

Companies are also going to have the opportunity to dramaticallyimprove efficiency throughout their value chain. This will bedriven by the XML file format, and SEPA is really the firstapplication of that. Think about the value chain of a corporatethat orders raw materials and then uses those materials to producea product. They sell the product, they send an invoice, and onlythen does actual payment take place. SEPA covers the paymentportion, so that piece of the chain now has an XML standard. Butimagine that the invoice was sent out in the same XML standard.Those two steps of the value chain could be much more integrated.And then think about how the whole value chain could start becomingXML—a company could have the exact same data from purchase order tocollections. It could automate a lot more, and its processes couldbe far more integrated.

This type of transformation would have an enormous impact ontimelines and efficiency, and as a result on accounts receivableand accounts payable—and that means working capital. That's muchmore XML than SEPA, but SEPA is the start of that XMLimplementation. This will be a 10-year, maybe even a 20-year,process. But that is where I think we're heading.