Automating A/R Reconciliation: The RosettaNet Approach
For most companies, accounts receivable reconciliation is still a manual and painful process. It is not unusual for funds to arrive with no useful information on the credit advice. Often the chain of correspondent banks is so long that the original payer of the funds (aka the ordering party) is not shown on the credit advice received by the beneficiary. An accounts receivable clerk has to use a mix of experience and luck to identify from which customer (buyer) the funds came. Then he or she has to try to figure out which invoices the customer intended to pay, sort through partial payments, cash discounts, and so on.
In the meantime the customer (buyer) is being told that their money has not arrived. In addition to the sometimes long delays within the banking systems – usually called float – there are likely to be processing delays at the beneficiary (seller) while the accounts receivable clerk sorts through incoming credit advices as described above. The customer is likely to feel frustrated that their money is not applied sooner and their balance is not reduced accordingly. Often sale must be delayed while the customer’s account is cleared. Delayed sales can often turn into lost sales. Thus in addition to the administrative time and cost wasted on accounts receivable reconciliation, companies face possible lost sales and reduced customer satisfaction.
The traditional solutions, like bank lockbox services, essentially outsource the problem to a bank or other service provider who does the same manual work. It is not evident that banks, with their heavy regulatory burden, have a lower cost base than the corporate customers for whom they undertake this outsourcing. Nor is it clear that banks can perform the manual process any faster than corporates, and if they lack the direct customer experience of corporate accounts receivable clerks they may even be slower.
In a April 2002 study, Killen and Associates estimated that a typical company with sales of USD 1 billion has avoidable working capital expenses of US$27m. That is a lot of saving to fund an XML server and the effort of getting customers online.
RosettaNet’s Payment Milestone Program (PMP) addresses this issue directly by automating the A/R reconciliation process. PMP ensures that costs are minimized (an XML server is definitely much cheaper than either corporate or bank clerks) and that incoming funds are posted as fast as possible to clear the customer’s account (the XML server works in real time). This article explains how the PMP was developed and how it overcomes existing barriers to fast, automated reconciliation of collections.
In late 2002, several members of RosettaNet (RN) – a standards organization that develops process and XML standards for the electronics and high tech industry globally – saw the need to tie its remittance advice format (PIP3C6) to credit advices to enable auto reconciliation of accounts receivable. Cisco, Intel, National SemiConductor, Nokia and Texas Instruments decided to sponsor the Payment Milestone Program (PMP) within RN.
The sponsors have worked intensively with our partner banks – ABN, Bank of America, CitiBank, Deutsche, HSBC, JP Morgan, Nordea, Standard Chartered – and with SWIFT, TWIST, and IFX and solution providers – FormFill, IBM, MicroSoft, Tibco, WebMethods – to develop a practical and globally applicable standard. This effort culminated in a gruelling week of detailed design work hosted by SWIFT in Brussels at the end of June 2003.
The design developed by PMP allows the remittance advice to travel separately from the money flow, so as to work with legacy banking systems. The only requirement made on banks and clearing systems is that they preserve a 18 character Unique Remittance Identifier (URI) through the banking system. According to our studies, this is feasible in most clearing systems.
The PMP process requires (1) that the buyer (or payer) send a remittance advice including the URI directly to the seller (or beneficiary). In the RN context, this will be a RN PIP3C6 sent over RNIF (RosettaNet Internet Framework – the standard transport protocol for sending RN XML messages between parties). At the same time (2) the buyer sends a payment initiation to its bank also including the same URI. The corporate to bank messaging is via SWIFT XML.
The buyer’s bank processes the payment via traditional clearing systems (3), and it is the bank’s responsibility to map the URI into the appropriate field in each clearing system so that the URI is intact when the payment reaches the seller. When the seller’s bank receives the payment, it sends a credit advice including the URI to the seller via SWIFT XML (4).
When the seller receives the remittance advice from the buyer, it queues the message pending receipt of the matching credit advice from its bank. When the seller receives the credit advice from its bank, it matches the credit advice with the queued remittance advice based on the matching URIs contained in each message, and then automatically posts the credit and invoice details to bank and accounts receivable.
This process is designed to be simple to implement with existing XML gateways, ERP packages, and banking systems. This has been validated with the sponsor companies with respect to their ERP systems, with the solution providers with respect to the message handling and matching based on URI, and with the banks with respect to the clearing systems.
The PMP sponsors and their partner banks have all agreed that we want to avoid diversity in banking XML standards. To that end, RosettaNet has agreed with SWIFT, TWIST and IFX (Interactive Financial eXchange) that they will align their XML standards wherever there is commonality of purpose – for instance in the core payment initiation message and the basic advice messages. A study by the Gartner Group found that unambiguous XML standards for ‘plug-and-play’ interfaces can significantly reduce implementation costs.
The PMP sponsors also took great pains to make sure that the process design is totally generic, so that it works for non RN users as well. The process will work just as effectively for other flavours of XML like EBXML (Electronic Business XML) and even for non-XML message formats like EDI or ERP proprietary messaging. The minimal requirements for corporates are simply:
The 18-character URI can be structured in any way that assures uniqueness and which suits the needs of the user community. RN members use D&B’s DUNS numbers (D&B’s system of unique business entity identifiers) to identify parties, so we have chosen to use the 18 characters as nine characters for the DUNS number and nine for a unique sequential number generated by each party.
The PMP process went live amongst the pilots in December 2003 – an amazing achievement in the face of tight budgets and year-end system freezes. Additionally, RosettaNet has introduced XML for corporate-to-bank communications, which allows banks to save huge amounts of money now wasted on proprietary legacy systems. This XML is completely generic and can be used for any type of payments – commercial, FX, payroll, etc. Banks will also benefit from straight-through processing and greater transparency through automated dealing and repairs, as well as query handling. In future, the prevalence of auto-reconciliation and the associated electronic information flows will allow banks to offer working capital and risk management services that are as yet undreamed of. Indeed it provides a platform for taking outsourcing to a whole new dimension.