Benchmarking Accounts Receivables

Accounts receivable/payable (AR/AP) are crucial modules of any well-designed information system. Sadly, though, they are poorly designed. The reason is that both developers and end-users are confused about what AR/AP should do.

The function of an AR system is to track the money due to an organization from its customers. A simple AR system records bills issued to, and payments received from customers. The amount due from the customer is simply billing minus receipts. A slightly more sophisticated form tracks not only bills and payments, but also debit and credit documents, including invoices, goods return, debit notes, credit notes, payments and cheque reversals. Such a system does not require any specialized software and can be implemented by using the general ledger module of any financial accounting system. 

This method of tracking receivables works on a balance basis–at any instant you know the balance that is due from a particular party. Unfortunately, systems that work on a balance basis are too simple to offer any real utility. They are unable to perform simple tasks such as finding out the status of a particular bill or determining what bill a particular payment was against. 

An alternative is to design systems that work on what is called a bill-by-bill basis. These systems are able to link individual documents. For example, suppose the company sells goods worth Rs 100,000 to a particular party. The first document to be input to the system is an invoice for Rs 100,000 debiting the party. Assuming that this is a sale on credit with the party being given 15 days to make the payment.

Now suppose goods worth Rs 2,000 were found to be defective and returned. Consequently, a goods-return note for Rs 2,000, crediting the party, enters the system. Five days pass and the sales department calculates that the party can avail of a cash incentive of Rs 4,000 on account of a volume discount scheme for sales in the previous month. A credit note of Rs 4,000 enters the system. A balance of Rs 94,000 is now due from the party. Fifteen days later a cheque for Rs 150,000 arrives from the party. This cheque is a composite payment for both the Rs 94,000 due and a payment for Rs 56,000 for the next order.

A well-designed AR system should be able to capture the adjustments between all these documents. It should contain query screens that allow you to pick up any document and trace the links to all other documents. Thus one should be able to start at the payment of Rs 150,000 and work up backwards to the original invoice. Real life situations are more complicated. For example, the cheque of Rs 150,000 might bounce. Or a bill-discountingmechanism could be used whereby the seller is paid by a finance company. This would mean adjusting the debit to the buyer, with a credit from a third party.

AR systems should be able to clearly distinguish between dues and overdues. If 15 days’ credit was granted to the buyer, then for the first 15 days, the amount should be treated as a due and after 15 days as an overdue. 

On the reporting side the AR system should be able to generate statements of amounts due, amounts overdue, aging analysis (where outstandings are classified by the number of days overdue) and reminder letters to parties for amounts overdue. Interest calculation on a bill-by-bill basis is also a desirable feature. Finally, the reporting structure should be able to handle unclassified payments, that is, on account payments from parties the status of which is not clear.

The bottom line. AR/AP systems require work to implement but the results are worth it.

Gautama Ahuja

runs a turnkey software development company, AHC Infotek