Managing mismatches

If a company has mismatched intercompany transactions, how can it trust its financial statements? This article, by KEITH HARRIS, explores some discussion points for the treasurer, finance director and, ultimately, the chief financial officer

Consider a company whose “goods” are physical products or services that are bought and sold. One party is the producer and the other – the counterparty – is the consumer. The producer will know what was purchased, shipped, to whom, how much it cost and the currency billed. The consumer also knows what was ordered and how much it should have cost, when payment is due and in what currency. Each party and counterparty keeps a record of those transactions.

Much of this buy-and-sell activity can occur between subsidiaries of the same company and hence a great deal of time and effort is spent invoicing, settling and accounting within the group. Where group companies have intercompany loans or deposits, this leads to more transactions and records. These transactions have a financial impact on the subsidiary and, as they are rolled up to group level, the consolidated profit and loss (P&L) and balance sheet. Auditors, management and the subsidiaries will want to be assured that the numbers are correct, so at some point these two versions of records needs to be reconciled.

Mismatches on A/P and A/R

Below are some examples illustrating the use of invoices on accounts payable (A/P) and accounts receivable (A/R), as these ledgers are likely to have many transactions and give rise to most of the mismatches. There is potentially considerable activity in A/P and A/R for a manufacturing company, for example, but many financial companies and those involved in intellectual property (IP) will face similar issues with fees and royalties.

Treasury bookings, such as intercompany interest, which may be rolled forward and have market interest rates applied, can be quite cumbersome to reconcile. Loans and deposits are not likely to change as frequently and are hence easier to reconcile, but the same considerations apply.

Some A/P and A/R mismatches will be because the receivable is booked in the A/R of the supplier, but not in the A/P of the counterparty, simply because it hasn’t yet reached the A/P. Other mismatches will be due to errors in the booking of the details mentioned above: party, counterparty, currency, amount, references, etc. The challenge is to identify and track mismatches due to timing and make sure they are reconciled in the next period.

Resolving mismatched items

Solution one

Simply ignore mismatched items and enforce the rule that the receiver is always correct. To reconcile the books at close, the A/P probably books a dummy invoice (eg, work in progress versus A/P). After the closing, they make the opposite booking and mismatched items go forward to the next period. The problem is that old outstanding disputes never get cleared. By the time it gets to year-end, a lot of time is wasted working out what was wrong way back when the item was booked.

Surely most companies would rather have a process that removes and identifies mismatches rather than let them remain disputed and, if so, how can they achieve this?

Solution two

Some companies use spreadsheets and email these to each other to agree items, or, perhaps, headquarters (whether treasury or finance) has to take on the consolidation. This is a long and tedious task to complete at a detailed level, such as an invoice, so, unsurprisingly, this process happens infrequently, perhaps every six months.

Solution three

A better solution would be to agree within the enterprise resource planning (ERP) system, except many companies have multiple ERPs, or within the treasury management system (TMS), but the TMS may not handle dialoguing and disputes or large invoice volumes particularly well.

Another way

What many companies would value, therefore, is a method of automating the process using a platform that provides visibility for both party and counterparty at the detailed level, whether an invoice, balance or transaction. It would provide a mechanism to discuss these items and reach a consensus, or at least make mismatches visible, identify outstanding invoices yet to be booked and mark items as disputed if there cannot be agreement. The number of such items would be small and, in the case of invoices, could be tracked through the monthly settlement periods with possibility of resolution in the month after closing or at the next management meeting.

One possible dispute process is shown in Figure 1. It is possible to use the same process of dispute flagging in a netting system, whereby settlement takes place at the end of the process and for month-end reconciliation in which discrepancy flagging is used to tell the counterparty about the disagreement and the reason for it.

In order to provide a flexible, uniform platform available to all, as perhaps agents would like to be involved in this process, the system would be made available via the internet and accessed by a browser. Data could be secured by 128-bit encryption and strong passwords, which is the level of security appropriate for data of this sensitivity, yet consistent with maintaining usability.

The system would give a real-time picture of matched and mismatched items, as well as provide tools such as a high level, or summary, ledger difference analysis on a consolidated group-wide basis, plus each subsidiary, displayed by business unit and currency to quickly identify where attention is needed. This tool would allow drill-down to the underlying detail to allow a simple way of identifying and flagging items for discussion (see Figure 2).

For companies with business units with a high volume of transactions, automation could be best achieved by bulk uploading from the A/R and the counterparty uploading from their A/P. The items would be automatically matched based on specific criteria – five fields might be sufficient, such as invoice number, payer, payee, currency, amount, document number, reference, etc, as appropriate for the company’s business.

Such a platform could clearly show which items are matched, mismatched (four of the five items agree, but, perhaps, the currency is incorrect either on the A/P or the A/R), or one side is missing, possibly because the counterparty is yet to upload the information or because of genuine problems receiving invoices or supporting documentation (see Figure 3).

Perhaps as an added feature, where the item is missing, a link to the image of the invoice or transaction could appear alongside the items. The system would provide dialoguing and dispute resolution features that tie into the normal business workflow. Flagging an item in the system will send an email containing a reference and reason directly to the owner of the queried item, which can be used to find the item quickly. Items would then be reconciled at a particular date. A company-defined dispute cut-off date would be enforced within the agreed calendar that drives the process.

Figure 4 shows a schematic diagram of the matching process with optional netting process (in red) and subsequent activities that are optional but desirable.

Conclusion

An automated process such as this could feasibly be run on a monthly basis with little overhead, and could also be combined with settlement of matched items via a netting system for items due. Then reconciliation is complete. The parties have updated their systems automatically by exporting matched and unmatched items, which allow the intercompany accountants to generate reports of mismatched items and track how many periods these have been outstanding. Otherwise the data is archived and the system is ready for the following period.

If this process is combined with receivable- driven netting, companies will benefit from improved liquidity, a more responsive intercompany performance and, with reconciliation, better numbers reported to auditors and management.

Keith Harris graduated with a joint honours degree in computer science and economics, and was briefly a programmer with the Imperial Cancer Research Fund before joining Chase Manhattan, now JP Morgan Chase, in 1985. He spent 17 years in the cash management division of JP Morgan, 10 of them providing electronic banking products to international clients, the remainder in product management, responsible for development and profit and loss of the bank’s multilateral netting and other client access systems. He then spent nearly seven years working as European agent for EuroNetting before joining Coprocess in January 2010. He looks after sales, marketing and support requirements for clients based in the US, the UK, Ireland and Benelux.

Cash&Trade is pleased to acknowledge that this article first appeared in gtnews.