Would you like to offer your clients “Current Accounts” with cheque books but you don’t know how to handle this in Loan Performer? Please read this article and you will become a lot wiser.

So how can we configure a Savings Product in Loan Performer as a Current Account? Go to System/Configuration/Savings and indicate that the product allows cheque withdrawals. Also set the charge for the creation of cheque books and the charge for a single cheque leaf if you offer that in case the client's cheque book is finished.

Then at  System/Configuration/Savings, define the General Ledger Account for the Cheque Book charges.

We can now issue Cheque Books with cheque numbers for each client who is authorized to use savings cheques. This is at menu Savings/Cheque Transactions/Issue Cheque Books or Single Cheque Leafs.

Issue the respective Cheque Book for the client.

A cheque withdrawal of 25,000 UGX  from the client’s account appears as follows:

The cheque withdrawal updates the savings account immediately and there is no need to clear the cheque. However this is different if the account holder pays someone by cheque. The third party then takes the cheque to his/her bank and expects the cheque to be cleared in a couple of days. The bank of the third party via the Central Bank’s clearing house will contact our account holder’s bank and ask them to honor the cheque. Our bank then goes to menu Savings/honor Cheques and, provided there is sufficient balance, will clear the cheque:

The Savings Statement then appears as below after the cheque is honored:

So lots of options to choose from. If you need any additional information let us know.

Eclof Uganda is one of the 3 Eclof’ countries that uses Loan Performer. Eclof Tanzania already uses Loan Performer since June 2008. Eclof Uganda uses Loan Performer since August 2011 and in September this year also Eclof Zambia started using Loan Performer.

ECLOF Uganda started with Loan Performer Version 7.10 and later, in September 2013 upgraded to Version 8. ECLOF has 3 branches including the head office and they have 30 users using the system in a decentralised environment.

Peter Rusoke, the Accounts Officer who joined ECLOF Uganda in June 2011, says: “… by then ECLOF was using Microsoft Excel and ledger cards which were updated manually. There was a change of management and 2 billion portfolio was handed over to the new management. Since everything was done manually, there was no transparency, no clear accountability, reporting was a bit vague and this prompted/ led to the idea of acquiring a Management Information System.”

The decision to buy Loan Performer was not difficult. The Chief Executive Officer already knew Loan Performer and had used it before. The other and main reason however was because of the guaranteed and flexible support: "One can easily connect with LPF support staff and get immediate help whenever necessary."

Just like any other institution that wants and is ready to computerise and standardise operations, ECLOF Uganda also had their expectations:

1. Proper portfolio management: with Loan Performer, ECLOF is assured of proper portfolio management through timely reporting and analysis.
   
   
2. Enhancing their internal control process: with the audit trail report, restriction of access to the menu items by different users of the system, use of the usernames and strong passwords, segregation of duties for different users, ECLOF has been able to manage their internal controls.
   
   
3. Financial reporting: Loan Performer has excellent financial reports that are accurate, correct, and credible. Reports are generated as and when they are needed to enable management take informed decisions.
   
4. Credit Staff performance management: with Loan Performer, ECLOF has been able to measure performance of their loan officers.

Though these expectations were met, Robert, the accountant, said that quality control is lacking: “When posting transactions in Loan Performer they directly get posted to the general ledger. In other words there’s no room for prior adjustments of the transactions that are posted to the general ledger.” He recommends that a feature be incorporated in such a way that if an officer enters the transactions, someone else can review them before posting them to the General Ledger."

If your system is ‘live’ there is no difference between the data-entry date (or computer date) and the transaction date (the date keyed in by the user for the transaction). You may even have configured Loan Performer so that no person can enter back-dated transactions. However often this is not the case and people can post today transactions of 1 or more days ago. So, is it possible to know what transactions were posted on a specific day, even if the transaction day is not the same?

We all know the ‘Breakdown’ and ‘Transactions’ reports in the ‘Accounts’ menu. They show us transaction dates only. But if you are an auditor, you would also like to know when they were entered and by whom? For this you need to use the ‘Audit Trail’ report under menu ‘System’.

Below is a form showing how we can generate an ‘Audit Trail’ report for transactions made in the period 01/01/2010 to 14/11/2014. The ‘Reporting period from:’ refers to the data-entry period when the transactions were entered into Loan Performer while the ‘Transaction Date from:’ specifies the transaction date (the date that the user entered for the transaction).

For this example we have specified the same date range, this simply tells the system to generate a report for transactions made for/ in a period. If a transaction was keyed in on 15/11/2014 with a transaction date of 14/11/2014, it would not be shown.

You see that the report is ordered by entry date and then by entry person. So you can easily see in what order a person has been keying in financial transactions. You see here that the user ‘Performer’ on 13/11/2014 entered 2 back-dated transactions for 01/01/2010. It also shows you that the same user entered 2 transactions on 14/11/2014 with a transaction date of the same date.

You can easily see the difference between the ‘Reporting period from:’ and the ‘Transaction Date from:’ by changing the last to 01/01/2010 for both start and end of the period.  You can observe in the report below that only one transaction is reported this time: the back-dated transaction keyed in on 13/11/2014 with a transaction date of 01/01/2010.

Ps. Please note that the date ranges include the dates specified.

If you are doing Savings it has probably already happened to you? You erroneously deposited money to the wrong account, the client came and has withdrawn the money but now you need to delete the deposit. If you do, the result is a negative savings balance. The account is what we call 'overdrawn'. However you can also allow your clients to purposely overdraw their accounts. At a fee of course!

An overdraft occurs when money is withdrawn from a savings account and the available balance goes below zero. In this situation the account is said to be "overdrawn". If there is a prior agreement with the Bank/MFI for an overdraft and the amount overdrawn is within the authorized overdraft limit, then interest is normally charged at the agreed rate. Loan Performer 8.15 and above has an option for allowing clients to overdraw their savings accounts and even to levy interest or commission charges for the overdraft.

To enable the overdraft facility, you must remove the overdraft protection for a particular Savings Product (the facility is product- wise). Overdrafts can be setup for individual, business and group accounts (both at Group and Group–member levels).

On the “Interest on Savings” tab set the minimum balances to zero (0). If you do not use Overdrafts, you may allow all accounts to go into negative and set a maximum negative balance at this place. However if you allow only specific clients to go into negative, use the Overdraft functionality and set the general minimum balance to zero.

Make sure that the account for Overdraft Interest charges is configured for this particular product, by continuing to the “Savings GL Accounts” tab and defining this.

Now we go to the particular client and setup the overdraft. Navigate on the LPF menu to Savings >> Overdrafts >> Set overdraft. Select the savings account on which the limit is to be set. Enter the overdraft amount, interest, starting and expiry date and the interest recognition date. Loan categories, collateral and guarantor information can be set up where applicable. A one off charge can also be set for the overdraft. Note that the interest charges will not be charged unless the overdraft is actually taken. This can be by cash or savings transfer. The overdraft will not be effective until it’s approved. Navigate to the LPF menu to Savings >> Overdrafts >> Approve overdrafts. At this level an overdraft can be approved or rejected with the date of the option taken and an optional reason.

After an overdraft is approved, then it is available for the client to utilize. A client is able to overdraw his or her account into negative up to a tune of the overdraft set.  This means that the client can operate within the overdraft limit until the overdraft expires.  The account will continue to receive deposits and withdrawals as usual and the client can pay and use his/her overdraft again as long as he doesn’t exceed the set limit. If the overdraft has expired and the account is still in negative, the savings account will be charged the interest set on the ‘Interest on Savings’ page at Configuration>>Savings Products under ‘Interest rate for negative balances’. This will be when the MFI calculates the normal interest on its savings accounts. In this case the client pays interest instead of earning it.
In case of groups where tracking is at group level, there is no difference with an individual account. If an overdraft is opened for a group whose tracking is at member-level, then all members have access to the facility on a first-come first-served basis. Any member can access the facility up to what is available at the time and in this way interest will be charged per member in proportion to how much of the facility he/she has used.




Overdraft interest is calculated on the tune by how much a withdrawal has moved the account into negative. Interest is calculated as a percentage on how much a particular withdrawal has moved the account into negative and tracked per member for group accounts whose tracking is at member level. A service Charge (Commission) can be levied at opening of the overdraft and it can be realized by Savings transfer or cash

Reports on overdrafts include Overdraft balances report, Last deposit report, Last withdraw report, Usage of Overdraft report, Ageing of overdraft report, Overdraft provision report, Approved/Rejected overdraft, report and Deleted overdraft report.

In the month of October, we celebrated the wedding of our Administrative Assistant, Ms. Violet Nakibirango Mpiima, who got married to Mr. Innocent Komurubuga.
Violet, now officially referred to as Mrs. Komurubuga, has served at CCS for 11 years running and is one of our longest serving staff members.
Mr. Innocent Komurubuga happened to have worked as a programmer at CCS from to 2003 to 2007 so we know where their happiness originates from!
We wish Violet and Innocent all the best in their marriage.

……it is not all about bug fixes at CCS……

We have every first Monday of the month a training session of 12 days (2 weeks, Monday to Saturday from 9:00 to 17:00 hrs) in Loan Performer version 8. Next training starts Monday 1 December 2014. This takes place at our office in Kampala. Costs are 750$ per participant. At the end of the training the participants have to pass a test and a certificate will be issued. Use this link to download the training schedule.

If Kampala is too far, we can do an e-training via the internet. The full training takes 12 sessions of 4 hours at a cost of USD 150 per session. We can also tune these trainings to your needs and make them more efficient for you.

Need help with Loan Performer? Try the Online Help or Chat with our staff.