Concept Note: Flexible accounting for transactions in MIS, with Molly

by krishnan.mani@intellecap.com, 14th September 2011

Introduction
============

The catalogue of common transactions in microfinance is a familiar one: disbursements and repayments for loans, deposits and withdrawals for savings, and several kinds of fees. Also, premia payments for insurance.

The peculiar challenges that microfinance pose to accounting is a large number of transactions of relatively smaller value. The same kinds of transactions may be accounted for in different ways as organisations scale across a number of locations. With scale, multiple locations must also record and report common expenses incurred in operations. It may be futile to expect the majority of staff at microfinance organisations to understand and practise accurate accounting

Due to the flexibility inherent in double-entry accounting, a wide range of choices are open to the accountant to treat similar transactions. These choices are likely to vary with scale and with local custom. Furthermore, the requirements for reporting, compliance, taxation, etc. vary widely and the specialisation needed has resulted in the evolution of diverse accounting packages that now serve local needs of users across the world. It is unlikely that an MIS application  can keep pace with these diverse demands in every part of the world

It is possible for the MIS "proper" to delegate the responsibility to account for transactions to an independent component or application. Such component or application then effectively encapsulates the accounting treatment by exposing simple interfaces to the MIS for this purpose; and in turn, can be designed to provide an arbitrarily complex and flexible system for the express needs of accountants and accounting

Concepts and design
===================

The following concepts are used to construct a framework that is capable of:
Part A) Customizing charts of accounts as desired, to account for transactions
Part B) Generating vouchers for transactions in predictable ways, according to some pre-configured "scripts"

A "script" is the logical evolution of the "financial action" in Mifos. The accountant can configure scripts to both "match" particular types of transactions, and to prescribe the particular accounting treatment for such transactions. 

An example of a script is: 'For receipts that are principal repayments: record a receipt voucher to debit “Cash” 100% of the amount, and credit “Loans made” by the same amount'

This speaks to Part B above.

Charts of accounts may also be "customized" by specifying a number of account "levels". An account (such as "Cash") can be "specialized" by an account level (such as "branch"), such that the "Cash" account has multiple accounts underneath it that correspond to "Cash- Branch A", "Cash- Branch B", etc.

The cash account may have multiple accounts underneath, one per branch. A "Loans made" asset account may have "child" accounts by each loan product, or by funder; or even by funder, then by loan product. A "Fee income" account may have child accounts for each kind of fee. The "Deposit Liabilities" account may have child accounts for each deposit account maintained for customers with savings. Another more cumbersome approach may be to use independent charts of accounts at each branch, but this is unlikely unless the scale merits it.

Indeed, the cash account can now respond to "events" such as the commencement of operations at a new branch, by creating a corresponding "Cash- Branch X" underneath it, etc. Account levels can also accomodate a hierarchy (such as Loans made -> Loan product A -> Branch B)

This speaks to Part A above.

Taken together, scripts and account levels form a potent combination. Scripts decide how transactions must be accounted for, and account levels (re)configure charts of accounts in the desired hierarchy. A few other concepts add versatility and power in the processing of transactions and events.

The earlier script can also now be configured as: “For receipts that are principal repayments: debit [“Cash” specialised by branch] 100% of the amount, and credit [“Loans made” specialised by loan product] by the same amount, for *the branch* and *the loan product* in the transaction”

Any form of transaction, accounting treatment, and corresponding configuration of the chart of accounts can be catered to, using some simple contracts between MIS and accounting

An implementation of these concepts called Molly demonstrates integration with any MIS that can periodically communicate information about "events" and "transactions" in a simple and flexible format

Integration with the MIS
========================

As the MIS captures transactions and handles typical "CRUD" life-cycles for instances of branches, clients, loans, funders, etc., it is possible to generate logs of transactions and events in a simple format. These logs can be communicated to Molly in more ways than one. Molly crunches away and reports back on the outcomes of processing.

Other needs
===========

Molly provides basic functionality for accounting including common financial statements. It is easier for Molly to be enhanced so it can exchange accounting information with a wide range of third-party accounting packages. The primary user in Molly is the accountant. It is also possible for Molly to handle accounting for multiple organisations and transactions received from diverse MIS systems, such that these are all reported together ultimately

--NOTE ENDS--

Suggestions from collaborators:

Thanks to Binny Gopinath:

a) Record vouchers for expenses at branches, etc.
(thought: By abstracting vouchers from transactions, MIS can provide simple recording of expenses, and communicate the same as further classes of transactions for corresponding vouchers to be recorded in Molly)

b) Record interest accruals
(thought: The MIS may calculate and communicate specific accruals that be recorded in Molly)

c) Cash reconciliation, cash management, cash projection, etc.
(thought: Using conventional cash and bank books from accounting, and comparing these with the actual cash and bank balances, it may be possible to serve these needs)