Loan Payments

Introduction

When a loan officer returns from a meeting or otherwise receives a payment, he/she or a data entry clerk enters the collection details in Mifos and the system updates the relevant records. To record a payment, the user clicks the Apply payment link under Transactions on the loan account details page.

The system enters the current date for the Date of Transaction. The user enters the amount of the payment and, optionally, the receipt ID and date of receipt. When completed, the user previews the payment information and then saves it. Once the payment is recorded the payment is broken into principal, interest, fees, and penalty components, which are displayed in a table on the account details page. The account balance, amount paid and total amount remaining, and the next payment details are updated accordingly.

The loan account details page shows the total amount due on the next scheduled payment date. The user can click the View installment details link to see the total amount broken into the following components for both the current installment and overdue amounts: principal, interest, fees, and penalty.

Early total repayment of loan

After a loan is disbursed, a client can at any time repay the loan in a single payment. To record a total repayment, the user clicks the Repay loan link in the Transaction box on the loan details page. The system calculates the total amount due as of the current date, including principal, interest, fees and penalties, as follows:

Principal. This is the sum of total principal due in unpaid, due and future installments.
Interest. For flat and declining interest types, the interest for all future installments is not included, but the interest for all past unpaid installments and the current installment is included. For example, if the loan is for 12 months and is paid monthly and the client wants to repay the complete loan on her 4th installment date, the interest calculated is for the 4th month. If the client misses the 4th installment and wants to repay the loan in between the 4th and 5th installments, the interest for the 4th and 5th installments is included.

Note on holidays: In case a holiday is added after the disbursal of the loan and the original calculation of the repayment schedule, one installment can be shifted to the next repayment date. For example, payment on 1st Jan is shifted to 1st Feb. In this case, if an early repayment is done on or before 31st Jan, it will not consider the interest amount, which would have been due on 1st Jan if Jan 1st were not a holiday.

Fees. Similarly to interest calculations, the fees due for all future installments is not included, but the fees due for all past unpaid installments and the current installment is included in the total due. Using the previous example, the fee calculated includes only the amount to be paid till the 4th installment, and the fees for the remaining 8 months are ignored. If the client repays the loan in between 4th and 5th installment, the total due will include the fees due for the 5th installment.
Penalty. This includes miscellaneous penalties and penalties due to late repayments, if any. The total includes miscellaneous penalties, both for the current installment and for those due through the last installment. Penalties due to late repayment are calculated as of the night previous to the total repayment.

The user specifies the mode of payment, and optionally the receipt ID and date for the total amount due. The system updates the account summary table with the amounts applied to principal, interest, fees and penalties and changes the account state to Closed – Obligation met.

Payment not equal to payment due

A client may at any time make a payment that is not in the amount due on a specific date. For example, a client may make a partial payment when she’s short of cash or an overpayment when she has a surplus. A user records these payments in the same way he/she records normal installment payments, by clicking the Apply payment link in the Transaction box of the account details page. However, in these cases, the user needs to modify the default amount shown for the payment to reflect the actual payment amount before previewing and submitting the payment.

The implications of payments that do not match the amount due are described in the following paragraphs.

Partial payments

A partial payment is first applied against the penalty due. If the amount exceeds the penalty, it is applied against the fee due, followed by the interest due and then the principal. The system updates the account activity and transaction history entries. If the user clicks the View repayment schedule link, he/she sees that the partial payment is reflected in both the Installments paid and Installments due sections of the table. The Date paid for an installment is displayed only when the entire installment has been received.

Primary Flow- Partial Payment

User clicks on “Apply Payment” link in loan details page.
User modifies the default amount and enters an amount less than the expected amount.
User clicks on “Review Transaction”.
System validates that the date of transaction is between the last payment date and current date.
System validates that the amount entered is not greater than the total amount outstanding on that account.
System displays the Preview page with the information entered.
User clicks on “Submit” to save the transaction.
System submits the amount received. The amount is first applied against the penalty due. After penalty payment, if there is an excess, the amount is applied to the fee due, followed by interest due and then the principal.
System logs Account activity and Transaction History entries.
System: “View repayment schedule" is updated to depict the status of each component (penalty, fee, interest and principal). The partially paid installment is displayed in both “Installments paid” and “Installments due” sections with the amounts paid and due respectively. The “Date paid” should only be displayed when the entire installment is paid off.

Early payments

Before the system accepts an early payment, it validates that the date of transaction is between the last payment date and the current date, and that the amount entered is not greater than the total amount outstanding for the loan. The amount paid is first applied to the current installment. The remaining amount is then applied to the penalty due, if any, for the next installment. An excess at this point is applied to the fee due, followed by the interest due, and then the principal. The system updates the account activity and transaction history entries. If the user clicks the View repayment schedule link, he/she sees that the early payment is reflected in both the Installments paid and Installments due sections of the table.

Primary Flow- Early Payment

User clicks on “Apply Payment” link in loan details page.
User modifies the default amount and enters an amount greater than the expected amount.
User clicks on “Review Transaction”.
System validates that the date of transaction is between the last payment date and current date.
System validates that the amount entered is not greater than the total amount outstanding on that account.
System displays the Preview page with the information entered.
User clicks on “Submit” to save the transaction.
System submits the amount received. The amount is first applied to the current installment due. The excess amount is then applied to the penalty due, if any, for the next installment. After penalty payment, if there is still excess, the amount is applied to the fee due, followed by interest due and then the principal.
System displays Preview page for the next installment if there was excess.
System logs Account activity and Transaction History entries.
System: “View repayment schedule’ is updated to depict the status of each component and installment (penalty, fee, interest and principal).

Principal pre-payments

Mifos provides Principal Pre-payment option for Loan accounts with ‘Declining Balance’ or ‘Declining Balance-Equal Principal Installment’ interest rate type.

This option allows you to make more than one transaction on the same day, even if there is a payment applied for interest on the same date.

Principal Pre-payment option gives also a possibility to make principal pre-payment on non-meeting date (i.e. on a date on which there is no entry in the loan schedule table) or if the duration of the loan went beyond what was entered into loan schedule table by Mifos.

Primary Flow- Principal pre-payments

User clicks on Apply Principal Pre-payment link in Transaction box.
User types all mandatory information such as: Date of transaction, Amount and Mode of payment. You can also specify also Receipt ID and Receipt Date.
User clicks on Submit button.
Repayment schedule on Loan account details page is updated.

Backdating loan payments

Mifos allows backdated payments if the configuration settings allow it. The system calculates and displays the total amount due as of the current date. If a backdated payment is paid, the user manually calculates the amount due as of the transaction date. The system verifies the date and amount. If the amount entered is not equal to the amount due as of the transaction date, the system does not accept the payment.

The date of payment can be between the date of the last meeting and the current date.

Partial, back-dated payments. For these payments, the user modifies the date of the transaction to a past date, in addition to modifying the default amount to a lesser amount than expected. When the user submits the transaction, the system applies the amount to the penalty due for the oldest unpaid installment. Any excess is paid against the fee due, followed by the interest due, and then the principal. At this point, the process is repeated for any remaining amount, and the payment is applied against the next unpaid installment, and then the next, until the entire payment has been applied.

Alternate Flow- Backdated Payment

User clicks on “Apply Payment” link in loan details page.
User modifies date of transaction to a past date.
User modifies the default amount and enters an amount less than the expected amount.
User clicks on “Review Transaction”.
System validates that the date of transaction is between the last payment date and current date.
System validates that the amount entered is not greater than the total amount outstanding on that account.
System displays the Preview page with the information entered.
User clicks on “Submit” to save the transaction.
System submits the amount received. The system picks the oldest unpaid installment and applies the amount against the penalty due for that installment. After penalty payment, if there is an excess, the amount applied to the fee due, followed by interest due and then the principal.
System rrepeats step 9 for all the unpaid installments until the amount become 0.
System logs Account activity and Transaction History entries.
System: “View repayment schedule’ is updated to depict the status of each component and installment (penalty, fee, interest and principal).

Overpayments

Client may make payment greater then remaining balance of the loan (an overpayment). Sometimes it is only a few dollars over, sometimes an entire extra installment is mistakenly paid. Handling overpayment of remaining loan balance is available in Mifos and the MIS will track this so that action can be taken to return the overpayment portion to clients in future.

Primary Flow- Overpayment

1. Overpayment situation only happens when repaying the last payment of a loan.
2. System detects an Overpayment during bulk payment upload.
3. The system closes the loan account and makes an entry in the new database table with details such as loan account number, overpayment amount, date and time, status of the overpayment and payment id (to be able to track the overpayment is linked to which payment).
4. On the loan page, the system displays the amount of the overpayment. Adjacent to this, there is a button labeled 'Clear' which is available for a user to manually clear the amount in case the last repayment was adjusted for some reason. The click of this button allows user to specify how much amount he would want to clear off.
5. Each loan can have more than one overpayment.

Missed loan installments

If an installment payment is missed, it is displayed in the overdue information, and the Total Amount Due includes the missed installment. For example, if a client has to repay $100 (principal = $80 and Interest = $20) every month, and she defaults for the month of August, then for the month of September, the following amounts are displayed in the Next Payment details:

Principal Due= $80

Interest Due = $20

Penalty Due = $2 (for the missed/defaulted installment)

Principal Overdue= $80 (for the missed/defaulted installment)

Interest Overdue = $20 (for the missed/defaulted installment)

Total Amount Due= $202

While the payment is entered, the system accepts either $202 or no payment at all.

Adjusting payments

To rectify errors, the full amount of the last amount paid can be nullified by clicking the Apply adjustment link from the Transactions box on the account details page, the repayment schedule page, or the next installment details page. Multiple repayments can be reversed by reversing each payment amounts one at a time.

Users adjusting loan payments for a loan already of the status Closed – met obligation, must have a specific permission to do so.

When the user clicks the Apply adjustment link, he indicates that the last payment should be reverted, and includes a note describing the reason for the adjustment. These notes are stored with the transaction history, rather than with the Recent notes or All notes for the client. After the adjustment has been previewed and submitted, the user can click the Apply adjustment link again, to reverse the previous payment, and so on, until only the first payment remains.

Once an adjustment is made, the system breaks down the last amount paid into its components and updates the respective amounts where required. For example, if the last amount was paid for principal, interest and fees together, the system breaks the total amount into these amounts and subtracts it from the principal paid till date, the interest paid till date, and the fee paid till date, and adds it to the loan balance of principal, interest, and fees to pay.

After each adjustment, the system updates the following:

The account summary:
- Total amount due on the current day is increased by the adjusted amounts
- Amount in arrears = adjusted amounts, if adjustment date > last installment date
- Amount paid: the amount adjusted is subtracted from the amount paid
- Loan balance: the amount adjusted is added to the amount due
The repayment schedule: both the "installments paid" section and "future installments" sections. The repayment schedule gives a picture prior to the repayment adjusted.
The respective repayment line is removed from the "installments paid" section and inserted in the "future installments" section.
The installment details: the current installment and overdue amount due on the next meeting (always from the current day)
Current installment is updated with the next meeting due amount
Overdue amount increases with the adjusted payment, if adjustment date > last installment date
Performance history updates:
- The number of payments
- The number of missed payments are incremented:
- The number of days in arrears are recalculated = Today's date-last payment date
Transaction history includes entries for the related transactions that were reversed due to the adjustment entries

Alternate Flow - Adjusting payments

User makes a complete payment of Rs. 100 on 1st Jan.
User clicks on “Apply adjustment” link on loan details page on 15th Jan and nullifies the last transaction.
System completes the adjustment flow.
User clicks on “Apply payment” link in loan details page on 16th Jan.
User modifies the date of transaction to 10th Jan.
User makes a partial payment and saves the transaction.
System should consider the amount due as Rs. 100 and complete the partial payment flow.

Waiving Fees and Penalty

See Collecting Client Charges

Additional information

If adjustment is done after a partial payment, the complete amount paid in last transaction should be nullified.
- For example, User records a partial payment of 20 rs.
- User then makes an adjustment on last transaction.
- The payment of the entire 20 rupees is adjusted.
If fee due = fee 1 + fee 2, fee 1= 20 and fee 2= 30, and the amount paid = 25- system should not have a logic to distribute the partial amount into various fee types.
- For example- Client owes 150 Rs.- 25 in penalty, 25 in fees across 3 different fee types, and 50 in interest and 50 in principal.
- Client makes payment of 35 Rs.
- System accepts 25Rs to cover penalty and 10Rs to cover fees partially.
- Repayment schedule will display 10 Rs as paid fees and 15 Rs as unpaid fees.
- System will not know how the partial payment is disbursed across the various fee types.
- The partially paid fee and/or penalty can be waived by the user.
If an installment is partially paid, it should be considered as a “missed payment” for performance metrics.
If an account is in “Active in bad standing” state, the state should be changed to “Active in good standing” only on complete payment of due amount.
Even for backdated transactions, “amount due” displayed by the system should be as of current date
Early payment- if the client pays complete amount for one future installment and then an upfront fee is applied to the account- this fee should be applied to the first unpaid installment.
Early payment- if an adjustment is done after an early payment, system should nullify the transaction and revert the transaction like a normal adjustment.
If a client/group has 2 or more loan accounts of the same product, system will not allow early/partial payment from bulk entry.â€¨
- System will validate that the amount entered is not greater than the total amount outstanding.
- This amount will be more than the amount calculated by the system through “repay loan”.
- The assumption is that if the user wants to completely repay the loan, “Repay loan” will be used and not “Apply payment” or bulk entry.