By standardizing bank clearingsystems across Europe, the Single Euro Payments Area (SEPA) has enabled companies tostreamline and standardize their payments processes. Many companies met theSEPA compliance deadline last year, then turned their attention to centralization of cash management andbank account rationalization.

Cash management banks with a big presence in Europe report thatcustomers are frequently asking about virtual accounts and on-behalf-of structures. They also say many companies arealready seeing big efficiency gains in the routine, traditionallylabor-intensive processes around transaction reconciliations.

Treasury & Risk recently sat down withMartin Runow, head of cash management corporate, Americas, forDeutsche Bank, to discuss the impact SEPA is already having oncorporate reconciliations and how that ties in with the strategictreasury initiatives that many multinational businesses areconsidering.

T&R: Has SEPA had an impact onreconciliations for multinational companies?

Martin Runow: SEPA has improvedreconciliations for a number of reasons. One is that all of acompany's payment systems now use the same filestructure—XML—across all the different countries where the companyoperates. This helps reconciliations massively. Before, somepayment formats in Europe were structured and some wereunstructured; whether you could find the information you werelooking for depended on the standards of the country your bank waslocated in. With SEPA XML, the format is the same across allEurozone countries. That helps tremendously in enabling companiesto find the information they're looking for as part of theirreconciliation routines.

Another benefit, which was stressed a bit when SEPA was firstintroduced but has since been overlooked, is that SEPA has ano-truncation rule. Previously, companies that did cross-borderpayments would make a payment that included all the necessaryinformation, but invoice numbers and other details may or may notmake it to the beneficiary of the payment.

T&R: Was that because differentsoftware systems just weren't consistent in how they storedinformation?

MR: Yes, one problem was that there was noconsistency. Another problem was that data would be reformatted.Different clearing systems allowed different lengths for certainfields. For example, some fields would allow 150 characters in somecountries and only 20 characters in other countries. So a companymaking a payment might enter 150 characters of detail, but whetherall that information made it to the payment beneficiary woulddepend on how the payment cleared and the path it took to get tothe beneficiary's bank. In contrast, under SEPA, banks are notallowed to cut or change any data fields as payments flow throughthe end-to-end process. As long as the company making the paymentdoesn't enter more than the maximum number of characters in a givenfield, whatever you enter is guaranteed to be delivered to thebeneficiary bank.

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

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

What the IBAN system adds to this environment is that it enablescompanies to receive payments across Europe with 100 percentautomatic identification of the sender of the money. This greatlyimproves the efficiency of reconciliations, although it doesn'tentirely eliminate reconciliation issues if a company wants toreconcile down to the invoice number.

T&R: Do you currently have anycustomers 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 putmoney into their PayPal accounts, but in some parts of Europe theyusually send a SEPA payment. Suppose that I send a direct credit toPayPal, but I fail to put my email address or account number intothe payments detail. Now PayPal has to figure out that Martin Runowwants to fund his account. You can imagine what a reconciliationchallenge this would be for a company with millions of customers.With the virtual account solution, the problem is already solvedbecause it never existed.

T&R: Because your payment wouldflow directly into your virtual account within the PayPal bankaccount?

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

T&R: To what degree is DeutscheBank seeing companies using virtual accounts acrossEurope?

MR: We have never seen as much interestin virtual accounts as we're seeing right now. Virtual accounts canhave such a big impact on reconciliations that the idea is gainingtremendous traction on the receivables side.

T&R: Are you also seeing anincrease in interest in payments-on-behalf-of (POBO) andcollections-on-behalf-of (COBO) structures? It seems the same dataformatting factors that facilitate virtual account structures wouldalso make it more efficient to set up a POBO or COBO system.

MR: Yes, I completelyagree with that. It all flows together. The XML format we use forSEPA has specific fields for the on-behalf-of companies. That, andthe fact that data flows end-to-end in this environment, makesreconciliation much, much easier. A company can put in a paymentinstruction that says, 'This is Treasury XYZCO, paying on behalf ofELCO,' and the recipient of the payment will see both of thosepieces of information.

Thinking very pragmatically, if a company receives money fromsomeone it doesn't recognize, that creates a reconciliationchallenge. If you expect money from ABC Co., for example, and youreceive money from ABC Bank, that's going to hit yourreconciliation repair queue. Resolving these reconciliation issuestakes human intervention, physically looking at all the additionaldata you have, which isn't efficient.

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

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

MR: Yes, and the time is right to makethat shift. The fact that there is now a pan-European automatedclearinghouse, which uses a pan-European XML format, is drivingcorporate treasury groups to make a strong push for more automationin their payments software systems. SEPA compliance was a projectwith a clear end date, and companies had to get it done if theywanted to continue to make payments. Suspending the payment ofsalaries was obviously not an option, so companies allotted abudget and IT resources to make their SEPA project happen.

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

T&R: Do you think virtualaccounts and POBO/COBO structures will be more common in thefuture?

MR: Yes, I think they will be much morewidespread among companies that have the necessary size andstructure and technology infrastructure. With the growingimportance of 'know your customer' banking regulations, it'sbecoming more and more important for companies and banks to worktogether to maintain transparent information about the originationand destination of payments. If a company uses on-behalf-ofstructures, that information becomes readily available.

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

MR: Connectivity with the bank andsetting up the accounts are relatively simple, but that is one ofthe last steps of the process when building this kind of system.Most of the necessary changes that need to take place are on thecorporate 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 acrossa number of countries, it's important to do extensive due diligencein the legal and tax arenas. Some countries welcome thesestructures, while some do not. A POBO/COBO implementation couldcome to a screeching halt if a company decides to implement them inone or two countries that do not allow them. So the first step isto do your homework.

The next thing to consider is that running a POBO or COBOstructure will require the company to create an entity that acts onbehalf of its other entities. As there will be financing flowingback and forth among the subsidiaries within the group, it'simperative to ensure that the company is adhering to all applicabletax laws. The company needs to be sure it is making the rightdecisions around things like where the central payments orcollections entity sits; how to set up the in-house bankingstructure; how to structure the intercompany relationships, whichneed to be governed by arm's-length principles; how to establishmonitoring among all the different entities; and a number of othertax considerations. These are the types of complexities thatcorporate treasury teams in multinationals manage these days.

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

The intercompany relationships that create complexity are alsowhat make these arrangements so worthwhile. You are using theoverall corporate group to turn financing that you would havepotentially gotten externally into internal financing.

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

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