...

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  Grameena Koota

• While the current accounting approach works for GK, their accountant anticipated concerns 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 may 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 writeoff write-off should write into different accounts based on the cause for writeOffwrite-Off. Ex member death would would need to decrease the fund source and increase the expected insurance payout
  

...

• pay-out.
• Different repayment and disbursement channels need to be accounted in under different heads
• Ability for different branches to have different Fund sources

2         Proposed solution

The current accounting module is intuitive and works for our Target clientele (small MFI’s who want Integrated accounting with their portfolio tracking)

1.2        Musoni Requirements

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

2.2        The Event

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

• Disbursement
• Interest Applied 
• Fee Applied 
• Penalty Applied 
• Principal repayment
• Interest repayment
• Fee payment
• Penalty payment
• Principal write-Off
• Interest waiver
• Fee waiver
• penalty waiver

...

2.3        Event Detail

Some events might further have sub events that would allow fine-grained control over the accounting rule to be implemented based on the event detail

For now, we would hardcode the sub-events as Enums in Java. Going forward it would be nicer if we could make sub-events configurable by an end user

Ex: The Disbursal Event could have the following details

• Check Disbursal
• Cash Disbursal
• Wire transfer Disbursal

Similarly, event details for the principal write-off could be “Member Death”, “Member spouse Death” etc

...

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

 = 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

Ex of the type of rules that can be created:

• In all branches, for all Loan product Types and for “Processing fee”, on a fee repayment, debit account X and credit account Y
• For branch “Bangalore” for all loan products, for any disbursal, credit account X and debit account Y
• In all branches, for all Loan product Types, for a “Check Disbursal”, credit account X and debit account Y

2.5       Priority of Event Driven postings over Product accounting rules

...

3.2        Priorities for resolving posting rule Conflicts

Event driven automated postings are meant to optionally override the default accounting behavior configured at the product leveldefault 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 . The would be followed and would apply only if no conflicting "Event driven postings" are defined
• "Generic" Event driven postings have a higher priority and override any conflicting Product Default Posting Rules.For Example: If the event "Disbursal" with Event Detail "Mobile Transfer" occurrs in the Context of a Loan Product in any Branch, the accounting rule mapped to this event would override the Product Default Posting rule

• 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 scenario

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