Martin Runow: SEPA has improved reconciliations for a number of reasons. One is that all of a company's payment systems now use the same file structure—XML—across all the different countries where the company operates. This helps reconciliations massively. Before, some payment formats in Europe were structured and some were unstructured; whether you could find the information you were looking for depended on the standards of the country your bank was located in. With SEPA XML, the format is the same across all Eurozone countries. That helps tremendously in enabling companies to find the information they're looking for as part of their reconciliation routines.

Another benefit, which was stressed a bit when SEPA was first introduced but has since been overlooked, is that SEPA has a no-truncation rule. Previously, companies that did cross-border payments would make a payment that included all the necessary information, but invoice numbers and other details may or may not make it to the beneficiary of the payment.

T&R: Was that because different software systems just weren't consistent in how they stored information?

MR: Yes, one problem was that there was no consistency. Another problem was that data would be reformatted. Different clearing systems allowed different lengths for certain fields. For example, some fields would allow 150 characters in some countries and only 20 characters in other countries. So a company making a payment might enter 150 characters of detail, but whether all that information made it to the payment beneficiary would depend on how the payment cleared and the path it took to get to the beneficiary's bank. In contrast, under SEPA, banks are not allowed to cut or change any data fields as payments flow through the end-to-end process. As long as the company making the payment doesn't enter more than the maximum number of characters in a given field, whatever you enter is guaranteed to be delivered to the beneficiary bank.

And the third benefit that we've seen SEPA helping drive in terms of reconciliation is the rise of virtual account structures, through which a company can assign each individual customer to pay to a unique account identifier. Banks now issue account numbers in the IBAN [International Bank Account Number] format, which is a pan-European format. So a company can potentially assign a different IBAN to each of its customers. Customers who pay with SEPA credits will send their electronic payments to the account number that is specific to them. From the customers' perspective, they're just paying to the bank account number that their supplier provided, but the payment flows automatically into a virtual account within the supplier's bank account, and each virtual account is specific to a given customer.

This is the classic way in which a virtual account functions. There's only one actual ledger, and the liquidity is sitting in only one bank account, but funds can be segregated into different virtual accounts as they come in. Whoever does reconciliation gets statements by whatever structure the company has set up. Virtual accounts can be divided by customer name, by the company's internal business divisions, or any other identifier that suits the company.

What the IBAN system adds to this environment is that it enables companies to receive payments across Europe with 100 percent automatic identification of the sender of the money. This greatly improves the efficiency of reconciliations, although it doesn't entirely eliminate reconciliation issues if a company wants to reconcile down to the invoice number.

T&R: Do you currently have any customers using virtual accounts in this way?

MR: We have several. One example is PayPal. In the United States, people typically use a credit card to put money into their PayPal accounts, but in some parts of Europe they usually send a SEPA payment. Suppose that I send a direct credit to PayPal, but I fail to put my email address or account number into the payments detail. Now PayPal has to figure out that Martin Runow wants to fund his account. You can imagine what a reconciliation challenge this would be for a company with millions of customers. With the virtual account solution, the problem is already solved because it never existed.

T&R: Because your payment would flow directly into your virtual account within the PayPal bank account?

MR: Exactly. And it not only improves the efficiency of reconciliation for PayPal, but it also speeds up the time it takes to credit that money to the customer's PayPal account, which keeps their customers very happy.

T&R: To what degree is Deutsche Bank seeing companies using virtual accounts across Europe?

MR: We have never seen as much interest in virtual accounts as we're seeing right now. Virtual accounts can have such a big impact on reconciliations that the idea is gaining tremendous traction on the receivables side.

T&R: Are you also seeing an increase in interest in payments-on-behalf-of (POBO) and collections-on-behalf-of (COBO) structures? It seems the same data formatting factors that facilitate virtual account structures would also make it more efficient to set up a POBO or COBO system.

MR: Yes, I completely agree with that. It all flows together. The XML format we use for SEPA has specific fields for the on-behalf-of companies. That, and the fact that data flows end-to-end in this environment, makes reconciliation much, much easier. A company can put in a payment instruction that says, 'This is Treasury XYZCO, paying on behalf of ELCO,' and the recipient of the payment will see both of those pieces of information.

Thinking very pragmatically, if a company receives money from someone it doesn't recognize, that creates a reconciliation challenge. If you expect money from ABC Co., for example, and you receive money from ABC Bank, that's going to hit your reconciliation repair queue. Resolving these reconciliation issues takes human intervention, physically looking at all the additional data you have, which isn't efficient.

Before SEPA came around, companies operating POBO structures would make payments, putting information about who they were paying on behalf of into the payments details field. But this is the same field where you would enter invoice numbers and other information, which is quite restricted in length. Having to put on-behalf-of information in that field is very inefficient.

T&R: So SEPA has made on-behalf-of structures more feasible to implement?

MR: Yes, and the time is right to make that shift. The fact that there is now a pan-European automated clearinghouse, which uses a pan-European XML format, is driving corporate treasury groups to make a strong push for more automation in their payments software systems. SEPA compliance was a project with a clear end date, and companies had to get it done if they wanted to continue to make payments. Suspending the payment of salaries was obviously not an option, so companies allotted a budget and IT resources to make their SEPA project happen.

Now we're advising many large companies to take advantage of the compliance resources and budget that they may still have, and to look to the future. If they're implementing XML-based payment systems in Europe, maybe they should look at taking those global. Perhaps this is the time to use excess budget to create an in-house bank or an on-behalf-of structure. SEPA and XML can deliver a lot of the efficiencies that corporate treasurers have always wanted, and if a treasury function has the money and resources to make that happen on a global scale, they should seriously consider doing so.

T&R: Do you think virtual accounts and POBO/COBO structures will be more common in the future?

MR: Yes, I think they will be much more widespread among companies that have the necessary size and structure and technology infrastructure. With the growing importance of 'know your customer' banking regulations, it's becoming more and more important for companies and banks to work together to maintain transparent information about the origination and destination of payments. If a company uses on-behalf-of structures, that information becomes readily available.

T&R: What are the biggest challenges to implementing a POBO/COBO structure?

MR: Connectivity with the bank and setting up the accounts are relatively simple, but that is one of the last steps of the process when building this kind of system. Most of the necessary changes that need to take place are on the corporate side, with setting up the technology, the files, formats, and building the internal structures.

To start, if a company wants set up POBO/COBO structures across a number of countries, it's important to do extensive due diligence in the legal and tax arenas. Some countries welcome these structures, while some do not. A POBO/COBO implementation could come to a screeching halt if a company decides to implement them in one or two countries that do not allow them. So the first step is to do your homework.

The next thing to consider is that running a POBO or COBO structure will require the company to create an entity that acts on behalf of its other entities. As there will be financing flowing back and forth among the subsidiaries within the group, it's imperative to ensure that the company is adhering to all applicable tax laws. The company needs to be sure it is making the right decisions around things like where the central payments or collections entity sits; how to set up the in-house banking structure; how to structure the intercompany relationships, which need to be governed by arm's-length principles; how to establish monitoring among all the different entities; and a number of other tax considerations. These are the types of complexities that corporate treasury teams in multinationals manage these days.

T&R: But companies are finding these projects to be worth the effort?

The intercompany relationships that create complexity are also what make these arrangements so worthwhile. You are using the overall corporate group to turn financing that you would have potentially gotten externally into internal financing.

Once you have a POBO/COBO structure set up, cash concentration and cash pooling are simple. With a decentralized group of companies, you might have 50 entities, all of which are making their own payments and doing their own collections, and then you have to set up a cash pool on top of that. But with the on-behalf-of structure, you may have one account for everybody. All cash flows in or out of that account, and all of the normal issues around cash concentration, physical, notional, etc., they don't exist because you already turned them in-house.

This is the best efficiency play a company can do—but it's anything but simple.