Ed Barrie, director of foreign exchange and treasury operations at Itron, a company that sells metering systems and solutions to utilities around the world, just finished bringing Itron subsidiaries in six European countries into compliance with the Single Euro Payments Area. Based on his experience, Barrie said talk about the difficulties involved in implementing SEPA has been somewhat exaggerated.
"The industry has made SEPA compliance and the technical side of it sound more complicated than it really is," said Barrie, pictured at right. "The technology solution is not that big an effort if the system you're using supports it. But there are a lot of things that go into SEPA, like getting your reference data—your vendors' BIC and IBAN numbers—and working with the banks, testing and end-to-end validation."
Itron's SEPA effort was part of a bigger project to shift to a single company-wide instance of Oracle's R12 ERP system, while also moving to an IT2 treasury workstation and implementing SWIFT connectivity to its banks. If the company's SEPA implementation hadn't been tied to the ERP project, "we probably could have gotten the XML payments with SEPA compliance done in three to five months, realistically, since Oracle R12 natively supports the format after installing a specific update patch," Barrie said.
Recommended For You
While IT departments may view SEPA as a big custom integration project, Itron found that "Oracle R12 out of the box supports PAIN.001.001.03," the XML payment initiation message required under SEPA, Barrie said. "We were able to download the appropriate patch and apply it, and within a few hours get a base version of that PAIN XML file generated and send it to the bank for validation."
Once Itron had the basic format for the PAIN payment message, it went to its banks to check what each bank required in terms of fields, in what Barrie calls a "harmonization exercise." Itron also asked banks about optional fields, and whether they would reject a payment message that included optional fields they didn't use, which is referred to as "data over-population."
"We went through that exercise with seven banks and that really helped us think about using Oracle and having a standardized map, instead of having to develop customized maps for banks one on one," Barrie said.
The biggest challenge involved in the SEPA project, he said, was getting the BIC and IBAN numbers for the company's suppliers and configuring the required master data on banks and bank branches in Oracle. Itron dealt with that by purchasing a directory, SWIFTRef, from SWIFT and using it to populate the bank and branch numbers in its customer records. Employing that data "just gives us better assurance that we didn't have any errors," Barrie said. "We had a few typos in manually captured vendor IBAN values, but we corrected those records when we validated against the SWIFTRef IBAN directory."
The effort seems to have paid off. "We've not had one payment rejected or been kicked out or delayed since we went live Aug. 1," Barrie said, adding that Itron has been achieving nearly 100% reconciliation rates on the payments that it has migrated to SEPA.
In Itron's new system, payment files move automatically from Oracle through SWIFT FileAct to the company's banks, with a copy of the payment file also fed into IT2 for real-time updating of the cash position. When the bank statements come back, they are automatically loaded into IT2, then fed in a normalized data feed into Oracle, where "those transactions automatically are reconciled in Oracle on a daily basis," without any human intervention, Barrie said.
As it continues to move subsidiaries around the world onto the new Oracle ERP system, Itron hopes to switch all of them to the PAIN message format. "Our vision is to have the one format and leverage it wherever possible for as many payments as possible to standardize the straight-through processing of reconciliation back into the Oracle system," Barrie said. "The thing to keep in mind is that the PAIN XML format can be leveraged for most payments types, including local ACH, cross-border wires, check issuance and FX payments, and not just SEPA payments."
In the European countries in which Itron has switched to SEPA, the company's treasury has achieved "a level of visibility and transparency we've never had before," Barrie said. "We have real-time visibility into when payments are made, the number of payment, the amount of payments, which accounts are being debited and the value dates. We are anxious to finish migrating our remaining subsidiaries in Europe to Oracle so that they will be SEPA compliant and receive the many benefits of our automated end-to-end process."
When it comes to reconciliation, "if we're getting all the data correctly from the bank and we're mapping correctly into IT2 and Oracle, then those payments get automatically matched off, otherwise the transaction has to be manually matched in Oracle," he said.
"The banking community still has a long way to go in terms of statement reporting," Barrie added. Legacy BAI and MT940 statements provide only limited information, he said, and argued for more use of CAMT XML end-of-day statements.
Barrie predicts that the biggest savings Itron will realize from SEPA will reflect the time staffers no longer need to devote to reconciliation because of the auto-matching. "Where it might have taken a person five hours a month to reconcile bank accounts, now it's taking two hours, so they can devote time to other things," he said. "There is a labor savings and a cost savings associated with that."
At health insurer Aetna, treasury manager Craig Allocca said treasury has been working for a year with the company's Aetna International subsidiary, which has customers in most European countries, to prepare for SEPA. The SEPA project has two components, one related to the payment files Aetna sends to its bank and the second to the manual payments initiated by treasury.
To bring the payment files into compliance, treasury examined the company's data, redesigned its file formats to work with its bank's new global payments platform, and is doing testing. Aetna will go live with the new system in November.
Meanwhile, Aetna's treasury is working to comply with SEPA on the manual payments it initiates by implementing a new treasury workstation that can handle international payments better and by working with its business partners to gather the additional data it needs on the parties it pays, said Allocca, pictured at left.
Aetna is taking the opportunity to gather not only the IBAN and BIC, but other information that it could use to minimize the risk of payments not being applied correctly, Allocca said. "We've been asking for the full beneficiary address, phone numbers, bank address."
"The two biggest challenges were the education of our internal business partners on what the requirements were and what to ask their customers for, what banking information, and then the reprogramming of the internal files to be compliant as they go into the banking system," he said.
Allocca hopes the work treasury has done in preparation for SEPA will result in fewer payment errors and returns. "Our goal is to get the data correct upfront from the beneficiary and just have straight-through processing," he said. "That's the biggest efficiency I can see that we gain."
© 2025 ALM Global, LLC, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to [email protected]. For more information visit Asset & Logo Licensing.
Susan Kelly
Susan Kelly is a business journalist who has written for Treasury & Risk, FierceCFO, Global Finance, Financial Week, Bridge News and The Bond Buyer.
