Making Payment Factories Pay
The concept of a payment factory was first introduced in the mid-1990s as a successor to the more cumbersome and complex operation of re-invoicing. The prime objectives included centralisation of bank connectivity, operational efficiency and benefiting from economies-of-scale savings.
The scope implemented by pioneering companies was never entirely comparable with the concept. This caused confusion when the concept was discussed in literature, at conferences and during sales meetings. After going quiet for a few years, the introduction of audit on key controls and a shift in opinion regarding multibank cash management infrastructures, as well as a new thrust in IT standardisation made the payment factory ‘hot’ again.
A payment factory connects an operating company’s payment process with bank back office systems via a central hub. It aims at centralising, standardising and automating payment processes across the enterprise. At the core of each is the transaction or file switch that controls payment file formats and bank connectivity. In addition to the switch, a payment factory can include features and functionality like validation rules, transaction enrichment and, for example, approval workflow. Payment factories become part of a wider, more complex in-house bank (IHB) when they also include the concept of payment on behalf of (POBO). Such transaction routing allows for initiating transactions without specifying the external bank account used. The incorporation of the POBO-concept integrates the payment factory with the IHB because without it tracking and recording the resulting intercompany liabilities and scalability becomes difficult, if not impossible.
Figure 1: Classification of Payment Factories
Source: Zanders
Corporate treasuries should consider implementing a payment factory for a number of reasons, but predominantly the major benefits are:
Most business cases for a payment factory justify it as a way of increasing the efficiency of liquidity management resulting from a better grip on cash flow. The payment factory provides treasury actual cash flow information online from the payment process. This cash flow information enables them to manage cash balances closer to zero.
Many payment factory managers go beyond tapping information. They also try impacting the timing of cash flows. While they typically may not meddle with the execution dates as requested by the business, the vast majority are able to delay files when necessary. They typically exercise their control in more subtle ways. Many will employ internal payment consultants urging affiliates to use more efficient payment methods or – after analysing historic data points flowing through the systems – changing selection parameters for their payment runs. It is not uncommon for affiliates paying prior to due date in an effort to improve local vendor relationships and reduce balances that otherwise should be deposited with the treasury.
Some payment factories offer payment warehousing such that weekly payment runs are released to banks daily. Daily releases reduce fluctuation in actual credit terms taken from suppliers. Warehousing also may reduce volatility in cash balance, unlocking permanently trapped cash in the cash conversion cycle. Daily releases can reduce trapped cash that is equivalent up to three days’ worth of sales.
A few firms go even one step further and implement system controls and automation that take away the from local finance managers control over payment run selections, or even eliminate the need for local payment runs altogether as any approved invoice will be picked up automatically for payment at due date. These corporates have the philosophy that payment execution and timing is an inevitable yet logical consequence of agreed terms and conditions and acceptance of the goods or services. Hence, invoice approval is taken as the trigger for paying at a predefined future date2.
Another method of controlling cash flow is limiting the payment methods available, excluding inefficient and/or exotic ones. The latest trend is going one step further and making only generic payment methods available to affiliates. The payment factory then maps the generic method to efficient payment methods based on business rules and as per agreement with (local) banks. With generic payment methods the central organisation maintains full control over transaction cost and bank float and standardised vendor static data maintenance. Zanders have just implemented a payment factory for a client that has only a generic electronic, cheque and direct debit payment method. The electronic payment method is then replaced centrally by automated clearing house (ACH), single euro payments area (SEPA), real-time gross settlement (RTGS), or Internationally-based business rules. Direct debit (DD) is replaced by SEPA DD (SDD) or, for example, lettre de change releve (LCR) in France, in a similar way. Release dates are recalculated from the requested value date of the transactions.
Exercising influence over how and when invoices are paid does provide control over bank charges and float cost and can improve working capital with a few days without jeopardising the payment terms, as agreed with the vendors.
The payment factory brings payment processes online even for smaller operating companies that otherwise might use flat file or manual interfaces to electronic banking (e-banking) tools managed locally. This not only standardises payment processes across the enterprise, it also creates for each transaction and file a standardised, unbroken and online audit trail in real-time pertaining to who executed what process step. Furthermore, by bringing the payment process online in corporate systems the requirement for electronic banking tools locally reduces too. This along with the workflow tools and increased security technology embedded in the payment factory system has a positive impact on compliance monitoring and fraud detection.
Once a payment factory is operational, external auditors are inclined to auditing payment processes on its control frameworks, rather than procedures and individual transactions.
Centralising and automating payment processing in a payment factory does reduce the effort of human assistance and speeds up the processing cycle. This alone helps process efficiency. In addition, automation and centralisation takes away complexity at a local finance level with implications for job profiles and required skills without compromising on quality of execution. Bringing these financial processes fully online also allows for creating physical or virtual shared service centres (SSCs).
The payment factory itself also creates cost benefits in a different way. Over time it will become an in-house expertise centre with knowledge of all aspects of payment processes and banking. This expertise can be used to further streamline local processes and execute change management projects affecting bank relationships in a more effective and efficient way. As such a payment factory makes corporations better prepared for negotiations and implementation projects with banking partners.
Reduced bank dependency has always be part of the core business case for a payment factory. However, in the past few years bank independency has got a different meaning. Both the 2008 credit crisis and the impending Basel III capital adequacy regulations have changed the partnership between banks and their corporate clients. While companies got an illustration of the true nature of counterparty risk during the crisis (some got reminded of the idea that their house bank actually might go bankrupt), they are also faced with the reality that credit and fee business is now, more than ever before, two sides of the same coin. While banks like to diversify credit risk by participating in syndicates or club deals, participation becomes subject to a ‘fair share’ in cash management fees. Consequently, companies are confronted with a multibank cash management reality and possibly with more frequent rebalancing of business between their banks.
The payment factory is instrumental in managing cash and payments efficiently in an increasingly dynamic banking landscape. Fortunately, payment factory technology has matured and industry-wide initiatives and standards like SWIFT for Corporates and XML ISO 20022 have been embedded in most solutions. Today’s platforms are therefore highly scalable and allow for managing bank connections at declining cost.
When a mature technology platform is used for disentangling local systems for payment processes from bank connectivity by putting a transaction hub in the middle, change management and redirecting flows becomes a central decision rather than a local, complex project. A file switch-only payment factory will not be of much help here. In fact the transaction request as delivered by the local system includes a specified debit account that has to be maintained locally.
Effecting transactions from an internal current account in combination with transaction routing based on business rules is a powerful step in the direction of bank independence. This enables the payment factory to report the transaction for reconciliation on the internal statement, rather than on the external bank statement that has to have its own rules set up in the local system. Changes in business rules for routing have no impact on local processes.
Key to all business cases for a payment factory is getting an effective grip on cash flow, while improving bank independence. The pinnacle of independence can be achieved when the transaction hub is used in combination with an intercompany current account and transaction routing as the only interface between the affiliate’s ledger and the banking infrastructure.
While the business benefit of a payment factory can be substantial, the project cost and effort should not be underestimated. It is a multi-faceted project that needs to focus in parallel on:
The first two bullet points are relatively straight forward to execute. Typically these are fully under the control of a central project team with specialised skills and experience in dealing with professional project management counterparts at implementation consultants and banks. Configuration of the system does not cover payment processes only, but also the cash management and cash flow forecasting processes. Furthermore, the business case document should address how to organise the payment factory. In the 1990s the payment factory would naturally be included in the treasury back office. Today, the daily operational responsibility for the payment factory process is often allocated to a financial SSC, with treasury responsible for bank relationship management and managing the required liquidity.
Depending on the countries in the project scope, the payment factory has to be configured so that local legislative and regulatory requirements are met. Ukraine, for instance, does not accept a standard straight-through processing (STP) payment process. Banks are required to have their clients approve transactions in separate local electronic banking tools. For other countries, local payment methods cannot be avoided or a controlled foreign exchange (FX) process needs to be incorporated. Still other affiliates might not be allowed to participate in an IHB or regional SSC. Even with these local requirements both the affiliate and the enterprise can create benefits by using part of the new infrastructure. The business case and system blueprint needs to be flexible enough to accommodate different local limitations.
The third and fourth bullet points above, covering change management and an SSC, are mentioned as facets of a payment factory project. They are equally as important for the success of any project – strong change management skills and executive sponsorship. Centralising payment processes will change responsibilities and therefore can imply a change in key performance indicators (KPIs) that might impact incentives. Local finance staff responsible for the payment process typically are responsibility for managing liquidity and working capital of the affiliate. Centralising key process steps might trigger many different responses that may or may not surface immediately or transparently. Given the physical distance between the project team and the local staff problems may arise as there will be no daily interaction over the cause of the project, partially because of ignorance, but also because of misunderstandings due to cultural differences and distances, but also sometimes due to malicious intent. A payments factory will reduce headcounts so may not be popular.
Misunderstandings between the project team members and local end users because of distance and cultural differences are common in each payment factory project. Frequent live meetings, conference calls and presenting to (regional) controller meetings iterating the concept and impact of the payment factory can potentially take away some sources of conflict.
Regular briefings will not take away all misunderstanding. There is always a grey area of ‘assumed understanding’ and misinterpretation of information shared. In many projects Zanders has been involved in local end users sometimes do not fully understand the payment factory concept until after they are ready to go live. The risk is that the project team will not get the required local input and feedback early enough in the project when the system is blueprinted. The consequence is late acceptance testing, or even local testing after the official go live, which presents the managerial project team with possibly critical issues that need to be solved quickly.
There are also known cases of local staff understanding the consequences but feeling their job profile is eroded. They might believe the payment factory undermines their autonomy and/or status. Such local staff might sabotage the project directly or indirectly.
One way of mitigating the project risks discussed in this section is to pilot the payment factory with a small group of highly motivated and representative affiliates that will be internal ambassadors and references during roll out. The mitigated project risk often balances the longer project timeline. The central project team can typically be slightly smaller because they will deal with issues sequentially where they would have to be managed in parallel were a ‘big bang’ approach to be taken. The downside of the pilot and subsequent rollout approach is that the system is unstable for longer due to the introduction of new functionality or required modification of existing functionality. Regression testing therefore is necessary. Furthermore, the pilot and rollout variant also implies the need for temporal interfaces and data feeds between legacy and new systems, for example, covering cash management and/or accounting.
A payment factory creates substantial benefit in terms of transparency, process efficiency and quality of information. However, the project cost and impact on current processes and organisations is easily underestimated. Should you consider a payment factory project, therefore, it is necessary to focus not only on the system and the bank communication, but also on the impact on local finance processes.
Although a payment factory aims for standardisation and automation, local requirements might not allow identical standardisation in all locations. The project needs to incorporate flexibility so that the concept can be implemented in different degrees, depending upon local requirements. But most important of all, because payment processes are crucial to business continuity, project execution has to be flawless.
2With the increased focus on vendor financing companies this concept will gain further popularity. The faster and more efficient invoice acceptance and dispute management processes are executed, the more benefit both vendor and supplier will have from discounting invoices. Furthermore, vendor financing will also promote the practice of paying on due date rather than periodically.