Emerging Trends in Straight-Through Reconciliation
Many companies reaching this enviable position have turned their attention to other costly operational activities, such as statements reconciliation. Anecdotally, it appears that companies reporting auto-reconciliation rates of 20% or 30% of bank statement entries are struggling with largely manual processes to complete the task. Their new target is achieving high rates of straight-through reconciliation (STR), built on the greater automation of the statement-matching process, and significantly reducing the entries left to manual reconciliation.
Improving STR rates not only yields further process efficiencies and savings, but also helps best-in-class SSCs to achieve greater effectiveness by delivering real value-added outcomes to their businesses. For example, better STR rates help drive quicker cash application, reducing days sales outstanding (DSO) and freeing up customer credit lines for more business.
Recognising the new focus on STR several years ago, the bank responded with a package of statement enhancements and specialised reconciliation tools to help customers realise their goals in this area. This is now an opportune moment to reflect on recent experiences and pick out the trends that point to future development.
Reconciliation Best Practices
Spend any time speaking to companies about their specific statement processing and reconciliation needs, and you soon appreciate how these can vary by department – treasury, accounts payable (AP) and accounts receivable (AR) – by local in-country practices and even by system (for example treasury management systems (TMSs) versus enterprise resource planning systems (ERPs)).
There are several ways of looking at these contrasting needs, each of which brings a different understanding of how to approach the issue.
Figure 1: Developing understanding of reconciliation needs:
Financial versus Operational Reconciliation
A key part of the morning ritual in any TMS is the updating and reconciling of cash positions across company bank accounts via a daily upload of electronic bank statements. From here, treasurers build an accurate picture of liquidity and working capital, investment opportunities and funding requirements for the day. This financial reconciliation focuses on balances and net credit and debit movements across the accounts.
By contrast, ERP systems need to operationally reconcile payments and collections generated by the respective purchase-to-pay (P2P) and order-to-cash (O2C) cycles of the business. This level of reconciliation is more detailed and information-hungry, requiring transaction references, remitter identification and remittance information delivered via the payment networks and banks.
Proclaimed rates of statement reconciliation are generally very high for a TMS, but much less so for an ERP tasked with operational reconciliation. Companies looking to raise STR rates are typically those that recognise the underperformance of their operational reconciliation, and so they seek improvements in statement content for their ERPs.
Payables versus Receivables
The operational reconciliation of payments and receivables is traditionally conducted separately, applying different reconciliation logic to the debits versus the credits on a statement. Payments reconciliation recognises that a payment run is a controlled activity, against which there is a clear record in the ERP of what debit amount should appear on the statement and on which date. Finding a match for a statement debit entry should therefore be relatively straightforward.
Conversely, statement credits, representing receivables from incoming payments and cheques, present a tougher challenge. Additional remittance information might arrive by separate means, in different formats and even at different times than the bank statement. Achieving a three-way match between statement credit entries, remittance information and open invoices in the ERP/sales-order system will require sophisticated techniques with effective automation, relying heavily on accurate and complete remittance information.
Payments reconciliation is clearly the low-hanging fruit, and companies have invariably focused on improving STR for payables first. Receivables reconciliation requires more complex processing, spawning several specialist vendor products in the market that employ powerful rules-based matching engines to improve automated reconciliation.
Outgoing versus Incoming Transactions
With the increasing popularity of direct debits as a method of collection, companies can initiate receivables as they do payments, meaning that receivables can also be reconciled on statements as payments are. By initiating a collection run as a controlled activity on the ERP, there will again be a clear record on the system – this time for a known credit – that should appear on an account statement on a given date. Reconciling a direct debit can then be as straightforward as reconciling a payment.
Reconciliation best practices can therefore be seen in terms of outgoing transactions, initiated by the company versus incoming transactions initiated by its counterparty.
Figure 2: STR Best Practice:
STR and Enriched Statements
Conventionally, companies receive and load the same daily electronic bank statement into both their TMS and ERP systems. Yet for companies striving to improve STR rates on their ERPs, there is a growing acceptance that different types of statements, maybe even formats, are needed to better address the different information needs of TMS and ERP systems.
Some banks have responded to this by offering separately generated enriched statement files for ERPs alongside their standard SWIFT-delivered MT940 and MT942 reports for TMS consumption. The enriched statements offer better support of itemised transactions, detailed remittance information and customer end-to-end references. As banks develop greater sophistication in their file-based ERP-oriented statements, the gulf between these and standard TMS-oriented statements grows, giving companies a real choice to match their reconciliation needs.
A typical ‘differentiated’ statement solution would feature:
Figure 3: Differentiated reporting for TMS versus ERPs:
STR and SEPA
Given that the key parts of what companies look for in account statements depend largely on what information can be transported through the payment clearing systems, one might ask if there are payment methods that support STR particularly well.
The single euro payments area (SEPA) is an excellent example of a payment scheme that has incorporated many of the information requirements needed for efficient reconciliation, such as:
Some communities, notably the Finns, have implemented a SEPA additional optional service (AOS) to further enhance the amount of remittance information that can be passed with payment, eschewing the standard provision of 140 characters as inadequate.
Well, if ‘information is king’, could we now expect STR-friendly SEPA to help European companies achieve better reconciliation efficiencies and cost savings than companies operating with less STR-friendly payment schemes? Could Finland, benefiting from an even more STR-friendly AOS, enjoy a competitive advantage over the rest of Europe? And where does that leave UK corporates, tied to an older clearing system that caters for only 18 characters of remittance information?
Levity aside, there is no doubt from recent experience in Europe that the migration to SEPA is leading many companies operating in the region to adopt STR best practices, such as using end-to-end IDs to automate reconciliation.
STR and ISO 20022 XML
If SEPA is having a beneficial impact in helping companies achieve better STR rates, can the same be said of the format that is most closely associated with it: ISO 20022 XML?
In recent years ISO 20022 XML has been very much in vogue, with banks across the globe helping customers re-engineer their payment and direct debit files into this format. In Europe, SEPA has helped drive greater corporate adoption of ISO 20022 XML, yet the camt.053 account statement message has been somewhat lagging behind, despite it being a structurally better format for presenting statement information compared to older formats, such as MT940, BAI2 and Electronic Data Interchange for Administration, Commerce and Transport financial statement of an account message, aka EDIFACT FINSTA.
As a universal financial messaging format, ISO 20022 XML has enabled many companies to streamline and standardise their use of payment formats globally, replacing many of the local file formats that corporates previously to deal with.
However, for electronic bank statements, there has not been the same proliferation of local formats to tackle, and most multinationals have already standardised their reporting on current widely-supported formats, such as MT940. Some banks have also upgraded their more established statements to report the richer data content of newer payment schemes, such as SEPA, just as well as the camt.053.
Ultimately, system support also becomes a major factor, with out-of-the-box availability of ISO 20022 XML still developing, even among some of the more popular TMS and ERP systems.
What can we take away from all this?
Corporate interest in STR rates and statement content in general has never been higher. There is both a growing recognition that statements reconciliation is multi-faceted and a growing understanding of the differentiated needs between financial and operational reconciliation, TMS and ERP requirements, and the different logic needed to reconcile outgoing transactions and that of incoming transactions.
SEPA will have a beneficial impact on STR. While ISO 20022 XML promises the same, it has some way to go to rival the popularity of older formats. Both developments confirm the rising importance of information content as a prime driver of achieving better STR rates.
Those banks and system vendors that recognised this trend in recent years have responded through various product enhancements that today present customers with a richer, more sophisticated set of statement capabilities than ever before.