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

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

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

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

T&R: Have you seen a lot of these large corporates leverage the SEPA compliance project as an opportunity 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. We have some corporate clients that have taken the opportunity to start centralizing processes and rationalizing bank accounts, but these are the companies that started their SEPA compliance efforts more than a year ago. For those that started late in the game, the push has been about compliance.

Consider a corporate that has entities in five countries. Each of those entities uses one or more domestic banks and has multiple accounts with those institutions. So across the five countries, the company might have 50 bank accounts. A typical company in this situation has been working so far to make sure all the infrastructure for those 50 bank accounts is SEPA-compliant. The next step is for management to look at how they can centralize and rationalize the number of bank accounts they use. We see a lot of those conversations starting now, but only after the company has become compliant.

T&R: Are there still any obstacles to centralization and standardization once a company is using SEPA-compliant systems and processes in different countries?

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

T&R: What are some examples of variations?

AP: Well, there are many. The obvious one is the use of the XML format for sending and receiving files. The SEPA XML standard is part of the regulation, but there are countries that have made slight variations to it. Germany, for example, 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 corporate and you're active in multiple countries and you're trying to standardize across them, then you aren't going to be able to use just one file format; you're going to need to support multiple formats. That reduces the degree to which you can standardize your databases and automated processes.

Another example of a variation that can cause problems are SEPA rejection codes. A certain number of direct debit collections are rejected, for one reason or another. When that happens, the customer's bank sends back a rejection code that comes 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 monthly direct 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 'reason unknown.' The company might have a policy of dealing with rejection code 1 by giving the individual two more days. So rather than informing customers that they don't have enough funds in their account, the company might wait two days and try again. That will work in some countries, but in others, for privacy reasons, banks don't tell vendors when a payment rejection is caused by insufficient funds. A problem that would receive rejection code 1 in some countries will receive code 2, 'reason unknown,' in others. So if the mobile-phone company were to merge all its direct debits into a single system, this discrepancy would seriously complicate its automated handling of rejection notices.

T&R: Do these variations generally stem from national regulations, or from differences between banks?

AP: Some are caused by privacy concerns that are triggered by national regulation. But there are also implementations on the bank side that differ just because of choices the banks have made themselves.

T&R: Do you anticipate that governments and banks will get these variations sorted out in a few years, so they will all handle rejection codes in the same way and will use the same XML fields—and so companies will be able to centralize and more fully automate their A/R and A/P processes?

AP: Yes. I should make clear that they can automate these processes now. We're helping our clients with that. But they have to understand that rejection code 1 might mean something different in the Netherlands than it means in Germany. As long as they understand what it means in each country, they can automate it.

T&R: Well, but some banks handle things differently, even within the same country, right? So would a company have to build into its automated system the knowledge of how each customer's bank handles rejection codes?

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

T&R: And you think companies will start to reap the benefits of standardization in the near future?

AP: Absolutely. We are starting to have discussions with our clients around all the things that have been put forward as the benefits of SEPA. Companies are looking into automation and standardization, not only of file formats, but of processes as well. As a result of that, they have the opportunity to centralize their processes and their receivables organization. And they can also rationalize their bank accounts and their number of 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 receivables factories. Receivables always used to be very localized, but now with SEPA direct debit, collections activities are the same in all the Eurozone countries. On-behalf-of is a big deal as well. If you centralize receivables or payables, then a centralized location will be acting on behalf of the local entity, and technically SEPA can capture this information in an 'on-behalf-of' XML field. That option supports setting up a payments or receivables factory. Legal and tax analyses are needed to determine whether a company can do on-behalf-of in a different country, so we always advise our clients to work with their legal and tax advisers as well as with us when considering such arrangements.

T&R: So, what do you expect to be the long-term ramifications of SEPA for large companies operating in Europe?

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

Companies are also going to have the opportunity to dramatically improve efficiency throughout their value chain. This will be driven by the XML file format, and SEPA is really the first application of that. Think about the value chain of a corporate that orders raw materials and then uses those materials to produce a product. They sell the product, they send an invoice, and only then does actual payment take place. SEPA covers the payment portion, so that piece of the chain now has an XML standard. But imagine 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 becoming XML—a company could have the exact same data from purchase order to collections. It could automate a lot more, and its processes could be far more integrated.

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