Note: This approach has been put on hold for now, the current quick fix is illustrated at https://openmf.mybalsamiq.com/mockups/869600.png?key=8378039401411518f98b27a2068867a9e1895716

1         The Problem

The current approach to accounting would work for smaller MFI’s and is simple to setup. However, larger MFI's have custom requirements when it comes to automated system posting, a few requirements from Grameen Koota and Musoni illustrate some of the possible customizations that might be required

1.1         Grameena Koota

• While the current accounting approach works for GK, their accountant anticipates issues in the future (Now all branches share the same fund source which is a Cash account. As and when branches start giving loans directly through Checks from their bank accounts etc, the current approach of setting fund source at a product level might not work for them)

• They want to track different fees and penalties postings under different account heads (currently all fees and penalties in the context of a loan product are tracked in the same head) 

• Principal write-off should write into different accounts based on the cause for write-Off. Ex member death would need to decrease the fund source and increase the expected insurance pay-out.

1.2        Musoni Requirements

• Different repayment and disbursement channels need to be accounted under different heads
• Ability for different branches to have different Fund sources

2         Verbiage Guide

3         Proposed solution

Add a set of additional "Events" to which Accounting rules may be mapped. While this would involve a significant amount of one time configuration, it gives larger organizations the ability to handle any custom automated system posting requirements

3.1        Overview

Every accounting event happens within a particular context. This context includes the following

• Branch: The branch at which the accounting event is triggered (Can be "All" or a particular Branch)
• Product : The Product for which the accounting event is being processed (Can be "All" Loan products or a particular Loan product /  "All" Savings products or a particular savings product)
• Fee or penalty: Some events like fee posting etc. would also have the type of the fee or penalty as a context

Based on the Context, different accounting events would be available.

Some events might have further attributes associated with them, which would allow fine-grained control over the accounting rule to be invoked based on the event attribute

 = applicable only when the products use accrual based accounting

An accounting rule can be attached to an Event (and optionally Event Details) occurring in a given context

3.2        Priorities for resolving posting rule Conflicts

Event driven automated postings are meant to optionally override the default Product default posting rules. The Order of priority the system would use for Interest posting would be as follows

• Product default posting rules have the lowest priority and would apply only if no conflicting "Event driven postings" are defined
• Event driven postings have a higher priority and override any conflicting Product Default Posting Rules.
• In the case that many event driven posting rules are present. The accounting rule attached to the most specific context would be given highest Priority

An English translation of these event driven postings are as follows:

• ID= 1) For all M-pesa disbursals in all branches debit “Loan Portfolio” and credit “MPesa”
• ID= 2) For all M-pesa disbursals in Bangalore debit “Loan Portfolio- bangalore” and credit “MPesa- bangalore”
• ID= 3) For M-pesa disbursals for Product “IGL” in Bangalore branches debit “Loan Portfolio-IGL” and credit “MPesa-bangalore”
• ID= 4) For all payments of Processing fee in all branches debit “Bank-Bangalore” and credit “Income from processing fee”

Now consider the following scenarios

3.2.1        Example 1

An IGL loan is disbursed in Bangalore using M-Pesa

The actual event and the context in which it was triggered can be represented as follows:

The event driven postings that are a match for this event are

• ID 1
• ID 2
• ID 3

Of the possible matching rules, the most specific rule is ID 3, hence “Loan Portfolio-IGL” is debited and “mPesa-bangalore” is credited

3.2.2        Example 2

A cash payment for processing fee is made for a Loan of Type “Emergency Loan” in Tumkur

The actual event and the context in which it happened can be represented as follows:

No event driven posting rules match this event, hence the “Product default posting rules” will apply

3.2.3        Example 3

A cash payment for processing fee is made for a Loan of Type “Emergency Loan” in Bangalore

The actual event and the context in which it happened can be represented as follows:

The event driven postings that are a match for this event are

• ID=4

Since only one posting rule matches this event, “Bank Bangalore” is debited and “Income from processing fee” is credited