Blog article
See all stories »

Centralised payments, enterprise-wide value

During this ‘countdown’ year to the SEPA migration end date, certain things have become apparent. Firstly, the inertia that has dominated the industry for some years about SEPA now needs to end, as we have discussed in previous instalments in this series. Secondly, there is significant help available today to facilitate migration, particularly the technical elements such as supplementing account details with IBAN and BIC, reformatting file formats to XML and converting direct debit mandates. Leveraging this type of assistance can make an enormous difference in reducing project risk and also enables resources to be directed towards process enhancement rather than technical tasks that ensure compliance but may not deliver wider value.

One of the most significant areas where our customers have taken advantage of SEPA is to centralise payments into a payment factory or shared service centre (SSC), or to optimise an existing centralised payments function. SEPA migration is a project involving a variety of stakeholders across purchase-to-pay processes. It is therefore an ideal opportunity to seek closer alignment across these business functions, such as accounts payable and treasury.

Payment factories are typically most efficient when processes, formats and technology platforms are as consistent as possible, in order to take advantage of economies of scale. This has not always been easy to achieve in the past, not least due to the variety of payment instruments across Europe, and the diversity of file formats that has existed. Consequently, while many companies have implemented payment factories and financial shared service centres (SSCs), the efficiency of these functions is often compromised, or the technical complexity can be considerable. SEPA sweeps away much of the inconsistency between payment types and formats, enabling more standardised processes and a simpler technology infrastructure as fewer file formats and less complex data mapping is required.

A second important reason why SEPA is a catalyst for payment centralisation is the legal framework which underpins it, the Payment Services Directive (PSD). Depending on the legal and tax structure of the enterprise, it is easier for companies to set up payment factories on a ‘payments-on-behalf-of’ (POBO) model. This is particularly the case where an organisation is also moving to a more centralised procurement model as part of a wider purchase-to-pay transformation. Under a POBO model, the supplier liability remains on a business unit’s balance sheet, but the amount is paid from a central account on behalf of the business unit. The intercompany flows can then be dealt with through an in-house bank.

Using a POBO model means that not only can formats and payment instruments be standardised and rationalised, but account structures can also be simplified as only one Euro payments account is required for supplier payments. This ensures that treasury has maximum access to and control over liquidity, with less reliance on complex liquidity management structures.

SEPA is not only a catalyst for payment factories in the Eurozone, it also offers the potential to extend the benefits across regions or even globally. The broader the scope of the payment factory, the greater the benefits: for example, not only can payment processes be rationalised, and account structures simplified, but FX exposures can also be managed more effectively. Key to the expansion of a payment factory is the use of XML-based ISO 20022 formats, which are now becoming a global standard in the Corporate to Bank space. Supported with the right in-house technology and bank connectivity, the opportunities for centralising payments are far greater than ever before.

 Have you implemented a POBO model? If so, what results have you seen?

2260

Comments: (1)

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 04 April, 2013, 16:41Be the first to give this comment the thumbs up 0 likes

Maybe as a part of fiscal control or whatever, POBO for AP is used by default in India and Middle East, if not in many other countries. POBO for AR - centralized follow up for invoices raised by multiple SBUs and depositing all collections into a single treasury account - has also been around for a long time in the Middle East. There's an interesting Q&A on this subject here.