Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

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 illustrating these needs are as follows

1.1        Grameena Koota

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

1.2        Musoni Requirements

  • Different repayment and disbursement channels need to be accounted in 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)

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

2.1        The Context

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 (star)
  • Fee Applied (star)
  • Penalty Applied (star)
  • Principal repayment
  • Interest repayment
  • Fee payment
  • Penalty payment
  • Principal write-Off
  • Interest waiver(star)
  • Fee waiver(star)
  • penalty waiver(star)


(star)applicable only when the products use accrual based accounting

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

2.4        Accounting Rule

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

 Event driven automated postings are meant to optionally override the default accounting behavior configured at the product level. 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 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

 

 

 

 

 

 

  • No labels