Loan rescheduling in Apache Fineract

When an active loan needs loan rescheduling in Apache Fineract

Loan rescheduling in Apache Fineract is a reschedule request that proposes a new repayment schedule for an active loan, with extra grace on principal or interest, extra terms or a changed interest rate, and takes effect only after the proposed schedule has been previewed and approved. It is used when a borrower cannot meet the current schedule and the credit team needs a documented, approved change to the future repayments. Because it alters what the borrower owes from a future date, it is a credit decision as much as a system feature, and the platform should be configured to follow the lender's restructuring policy rather than the other way round. Before the build, the credit, risk and operations teams should agree which concessions are permitted, who may propose them, who approves them, and what evidence must sit alongside each request.

Designing that policy into the system starts with confirming the details that change between releases. The exact request fields, the approval states a request passes through, the permissions needed to create, approve and reject requests, and how the preview is generated must be checked against the Fineract documentation for the release you run, using the Apache Fineract platform documentation as the starting point. Ask the implementation team to show, on a test tenant, which fields are mandatory, whether a rate change can be combined with extra terms in one request, and what the approval step records about who decided and when. Where the lender's policy requires a second approver or a reason code, confirm that the platform supports it or plan a controlled process around it.

Plan the rescheduling rules before the first request is raised, because the system will apply whatever the approved request says. Decide which loan products allow each type of change, the maximum extension a credit committee will approve, how interest accrues during any extra grace period, and whether restructured loans need separate reporting or provisioning treatment. Run the full path on a copy of production data: create a request, review the previewed schedule against a manual calculation, approve it, and then confirm the repayment dates, outstanding balances and accounting entries. Keep in mind that rescheduling differs from re-aging on progressive loans, so teams must confirm which option their product type supports before promising a concession to a borrower.

Reschedule options and when each fits

This table compares the main reschedule levers on an active Fineract loan: extra grace, extra terms, rate changes and combinations. Read each row as a borrower situation, the effect on the remaining schedule and interest, and the policy question credit must settle first. Behavior differs by release and interacts with accrual and charges, so confirm each option in the documentation and a test environment before relying on it.

Option	Borrower situation it fits	Effect on remaining schedule and total interest	Policy question credit must answer
Extra grace on principal	Temporary cash-flow strain where the borrower can keep paying interest but not principal	Principal repayments move later and the term may extend. Interest typically keeps accruing on the outstanding balance, so total interest usually rises. Confirm accrual behavior in your release.	Will interest keep accruing during the grace, and who approves a grace period beyond the product's standard limit?
Extra grace on interest	Short-term income gap where the borrower can meet principal but not interest	Interest due dates shift, and the treatment of unpaid interest during the pause (accrued, deferred or capitalized) depends on configuration. Confirm the mechanism in a test environment.	Is unpaid interest added to the balance, and does that change provisioning or income recognition?
Extra terms (term extension)	Ongoing reduced capacity where a lower installment is needed over a longer period	Installments usually fall while the number of repayments and total interest increase. The effect on the final installment and rounding should be checked on the actual schedule.	What maximum total term applies to this product, and does the extension need a new credit assessment?
Interest rate change	Borrower whose risk profile has changed or where a concession is agreed as part of a restructure	Future interest recalculates from the change date. Past periods remain unchanged. Whether the change applies to paid installments depends on the release, so verify backdating behavior before use.	What rate floor applies, and does a rate cut need a documented approval and regulatory disclosure?
Combination (grace plus term or rate)	Significant hardship where a single lever alone does not produce an affordable payment	Effects compound. Total interest, final maturity and installment size all move together, so preview the full schedule before approval.	Does the combined concession meet forbearance or restructuring criteria, and how is it recorded for reporting?
Charges and penalties on the rescheduled loan	Any case where overdue charges or fees exist at the time of reschedule	Whether outstanding charges are carried forward, waived or recalculated depends on settings. Confirm how each charge type behaves during and after the reschedule.	Which charges are waived as part of the concession, and who signs off on each waiver?

Setting up reschedule requests and approval in your environment

This sequence moves rescheduling from policy to production by fixing the rules, roles and product settings first, then proving the request and approval flow in a non-production tenant before any live loan is touched. Each step ends with a check you can record and show to your risk and audit teams.

Agree the restructuring policy and eligibility rules
Credit risk, operations and compliance agree in writing which reasons justify a reschedule, which loan states and arrears levels qualify, how many extra grace periods or terms a borrower may receive, when an interest rate change is allowed, and who must sign off. Write these rules as a short policy document that the configuration will be tested against. The step is complete when each rule has a named owner and the policy has been approved by the people accountable for credit losses.
Configure roles for request and approval
Your Fineract administrator defines the permissions that allow staff to create reschedule requests and separate permissions that allow other staff to approve or reject them, so one person cannot complete both steps on the same loan. Map each role to the branch, staff or office scope your policy requires. Confirm the exact permission names and any maker-checker behavior against the version you run in the platform documentation, since these details depend on the release. The check is a test login for each role that shows the expected actions and blocks the rest.
Confirm loan product settings that affect rescheduling
Review each loan product that will be rescheduled and record the settings that govern the outcome: interest calculation method, repayment frequency, grace settings, charge behavior and any recalculation options. Decide which products allow rate changes and which do not, and document this as a product rule rather than leaving it to individual staff judgment. The check is a signed product configuration sheet that matches what the tenant actually shows when you open each product.
Test requests in a non-production tenant
Load a copy of representative active loans into a non-production tenant, selected to cover each product, arrears state, repayment frequency and interest method in use. Run the full flow: create a request, preview the schedule, submit, approve on a separate login and, where relevant, reject a second request to confirm the rejection path. Use a tenant identifier set through the Fineract-Platform-TenantId header so testing stays isolated from live data. The check is a test log listing every request, outcome and user involved.
Verify previewed schedules against hand calculations
For a sample of test loans, have a second person recalculate the new installments, balances and final maturity date by hand or in a separate spreadsheet using the agreed terms and the product's interest method. Compare each line of the previewed schedule with the independent figures and record any difference, including rounding. Investigate every mismatch before accepting the configuration. The check is a signed comparison sheet showing that the sample agrees to the agreed tolerance.
Confirm the audit trail and accounting postings
Review the audit records for the test requests and confirm they show who created the request, who approved or rejected it, when each action occurred and the reason recorded. If your configuration posts accounting entries for rescheduling, run a test month-end and compare the journal output with the expected entries agreed with your finance team. Confirm the extract your auditors will use contains these fields. The check is a sign-off from finance and internal audit that the trail and postings meet your records requirements.
Document the approved process and go-live controls
Write the approved steps, roles, product rules, test evidence and exception path into an operating procedure, and decide who can change these settings after go-live. Confirm with your Fineract administrator and risk owner how production changes are tested and recorded before they are made. The step is complete when the procedure is approved, the test evidence is filed, and production access matches the role design tested in earlier steps.

Where loan rescheduling goes wrong and how to design around it

Rescheduling changes what a borrower owes, when, and at what cost, so every change touches credit, accounting and customer communication at once. The cards below cover the failure modes we see most often in Fineract reschedule flows and the design control and test that address each one.

Hiding arrears instead of resolving them

A reschedule can move overdue amounts into new installments so the account no longer shows as delinquent, while the underlying repayment problem is untouched. Define in policy which arrears may be rescheduled, who may approve it, and how many times one loan may be rescheduled. Test that an account with arrears still reports correct overdue days, delinquency bucket and non-performing asset status after the change, and that repeated reschedules trigger the review rules you set.

Schedule changes without a credit reason

Extra grace, extra terms and rate changes all alter exposure, yet a reschedule request can be created with only a free-text note. Require a reason code and supporting data as a mandatory data table or note field before the request can be submitted, and map each code to the approval level it needs. Test that a request without a reason code cannot reach approval and that the reason appears in the loan history for audit.

Interest and fees accruing differently than disclosed

Once the new schedule is accepted, interest accrual, charges and penalties continue under product rules that may differ from the customer letter sent at approval. Confirm for each reschedule type which interest method, grace treatment and charge rules apply from the reschedule date. Test one loan per reschedule type, comparing the accrued interest and charges with the figures in the customer communication, including a partial period and a payment made during the grace window.

Accounting and provisioning not updating as expected

Changes to principal, interest receivable and deferred amounts must post to the right general ledger accounts, and provisioning calculations must read the new schedule. Confirm with your accounting team which journal entries a reschedule creates and whether any amounts require manual adjustment. Run month-end on a test copy after a reschedule, then compare the ledger, loan portfolio report and provision figures against an independently calculated expected result.

Approvers acting on incomplete previews

Approvers who see only the total term or new installment amount may not see the effect on total interest, the final maturity date or the balance after grace ends. Require the preview to show the full new schedule, the change in total cost to the borrower, and the difference from the current schedule before approval is possible. Test that the approval screen and the preview return the same figures and that a later change to the request invalidates the earlier approval.

Borrowers in the wrong product after a change

A reschedule that moves a borrower between products, or that leaves the loan on a product whose rules no longer match the new terms, can break limits, product mix checks and reporting. Decide which changes stay on the original product and which require a new loan, and document that boundary with your credit team. Test that product mix, borrower cycle and product-level reports still classify the account correctly after each reschedule type.

How rescheduling differs from re-aging on progressive loans

Rescheduling and re-aging both move repayment dates, but they answer different questions, so decide which one a restructuring needs before any product or loan configuration starts. Rescheduling changes the schedule of an active loan through a reschedule request that is previewed and then approved, so the new installments, extra grace or extra terms are visible and signed off as one discrete event. Re-aging on progressive loans is a separate mechanism that moves the loan's aging position, which changes how overdue days are counted. The two do not produce the same arrears, delinquency or schedule outcome, so a policy that treats them as interchangeable will report loans inconsistently.

The practical difference shows up in three places: arrears, delinquency reporting and the repayment schedule. After a reschedule, the new schedule carries forward from the approved request, so the installments due on each date change. Confirm how overdue amounts that existed before the request are carried into the new schedule. After a re-age, check the aging position against your delinquency buckets and non-performing asset rules, because that position drives how the loan is reported. Have your team build a test loan for each case and read the schedule, arrears aging and delinquency output after each action.

Before configuring anything, write the policy: which restructuring cases use rescheduling, which use re-aging, who approves each, and what each does to reported arrears and any provisioning that depends on them. Then confirm the exact behavior for each loan type in the Apache Fineract platform documentation, since the two features are not interchangeable and their rules can differ by product type. Verify any behavior against the Fineract release you actually run, because the documentation and your deployment must match before you rely on either tool.

What a reschedule changes for each team

Credit and risk approve the reschedule terms and then watch how the loan performs against them. A reschedule changes the schedule that portfolio reports measure against, so approval should rest on the previewed schedule and the total cost to the borrower, not only on the original contract.

Approval criteria: Define which reasons, grace types, extra terms and rate changes need credit approval, and who may approve each one.
Exposure and maturity: Expect the maturity date and remaining term to move, which changes concentration and repayment-profile reports.
Arrears and stage monitoring: Check how a rescheduled loan is classified in arrears and delinquency reporting, and whether it carries a flag for restructured status.
Repeated reschedules: Set a limit on how many times one loan can be rescheduled and make that count visible on the account.

Confirm with the implementation team which reports read the original schedule and which read the current one, and where the reschedule reason is stored.

Security and operational controls for reschedules

The first control to settle is who can create a reschedule request and who can approve it, and to keep those two roles with different people. A reschedule changes the repayment schedule of an active loan, so a single user who can both raise and approve the request can alter a borrower's obligations without a second check. Map Fineract's permissions for loan reschedule requests to named roles in your own access model, then confirm in a non-production tenant which permissions a requester role needs and which an approver role needs, and that neither role carries the other's rights by default. Record the mapping as part of your change-control evidence, and review it whenever staff roles change. Confirm also how the approval screens and the matching REST endpoints enforce the same permissions, because a role that is blocked in the user interface but allowed through the API is a common gap.

Retain the audit trail for each request, its preview, its approval or rejection, and the transactions it produces, and make sure you can tie each entry to a user and a time. Confirm with your Fineract version which of these records are kept in the database, how long your backup and log retention policies keep them, and whether approver comments are stored with the request. For access logging, decide where the application and reverse proxy logs for the approval screens and the loan reschedule endpoints will go, and who reviews them. Authentication and transport settings are covered in the Fineract documentation on Apache Fineract platform documentation, which you should read alongside your own identity provider configuration and the TLS settings described there. Do not assume that logging of a request is the same as logging of an approval.

Plan operational timing around close-of-business processing and scheduled jobs. Do not approve a reschedule while the Close of Business Day job is running or while a batch that touches the same loans is pending, and agree a cut-off time in your operating procedure. Test how a rejected or reversed request behaves: confirm that the original schedule is restored, that any preview-only changes leave no postings, and that a reversed transaction is reflected in the ledger and in the loan's schedule. Your own change-control process should define who approves a reschedule rule change, how a faulty reschedule is corrected by a documented reversal rather than a direct database edit, and how each correction is recorded for auditors.

Limits to confirm before you commit to a design

Rescheduling touches the schedule, the money owed, and the books at the same time, so a design that looks correct on paper can break in a test run. The items below are questions to settle with the platform documentation and a rehearsal in your own environment before you fix a process or a product configuration.

Reschedule options by loan type

Confirm which loan types and products in your release accept each reschedule option: extra grace on principal, extra grace on interest, extra terms, and interest rate changes. Support can differ between standard loans and progressive loans, so check each product you plan to offer. Run one reschedule per product in a test tenant and record which options are blocked, greyed out, or silently ignored.

Reviewing the preview as another user

Confirm whether the previewed schedule can be reviewed and approved by someone other than the user who requested it, and which permissions the approver needs. Your segregation of duties depends on this answer. Test whether the approver sees the same figures the requester saw, and whether a changed loan invalidates a pending request.

Charges, overdue amounts and accrued interest

Confirm how a reschedule treats charges already applied, overdue installments, and interest accrued but not yet posted. Ask whether overdue amounts move into the new schedule or stay on the old dates, and whether penalties keep accruing during a grace period. Use a loan with an open penalty and an unposted accrual to check each balance before and after the change.

Holidays and working-day rules

Confirm how holiday calendars and working-day settings move the new due dates produced by a reschedule. A date that is valid for one branch may fall on a holiday for another. Test a reschedule that crosses a holiday in each branch calendar and check whether the system shifts the date, rejects it, or keeps it unchanged.

Reporting and accounting outputs

Confirm what a reschedule posts to the general ledger, if anything, and whether reports on arrears, expected receivables, and maturity update as your finance team expects. Compare the journal entries and report totals before and after a rescheduled loan in a test run, and agree the expected results with finance before go-live.

Questions lenders ask about loan rescheduling in Apache Fineract

What drives the cost of configuring loan rescheduling in Fineract?

The cost follows the scope you agree in writing: how many loan products can be rescheduled, which rescheduling types you need (extra grace on principal or interest, extra terms, or interest rate changes), and how many approval levels sit between a request and a posted schedule. Products with multiple disbursements, floating rates or progressive features add test cases. Integrations with a core repayment channel, reporting or a general ledger export add build and test work. Your quote should separate one-time configuration and testing from any recurring support or upgrade retainer. DeployOpen does not publish a price list, so ask for a quote built from a written scope.

How long does a typical rescheduling setup and test cycle take?

Length depends on the number of loan products in scope, the rescheduling rules you want per product, how many approval steps you require, and how much of your own loan book you need to replay in a test environment. Teams that already run a tested environment and have written rescheduling rules usually shorten the cycle, while new approval workflows, custom reporting or integration changes extend it. The timeline is set in the written scope before work starts, so ask for the phases, the entry and exit criteria for each test round, and which dependencies sit with your team.

What does the work need from our credit and operations teams?

Credit policy owners need to decide who may request a reschedule, the maximum extra grace or extra terms allowed per product, when an interest rate change is permitted, and which approvals are required. Operations teams need to define how requests are logged, how previews are checked against the customer's repayment capacity, and how exceptions are handled. Both teams should sign off test scenarios that cover early, late and partially paid accounts. Without these decisions, the configuration can be technically correct but still fail a credit review.

Can an internal team configure rescheduling without a partner?

Yes, if the team has Fineract engineering skills, a non-production environment with realistic loan data, and time to read the rescheduling documentation in the Apache Fineract platform documentation carefully. Many lenders choose a hybrid model in which their own staff own the policy and a partner builds, tests and documents the configuration. The deciding factors are internal Fineract experience, the number of products affected, and whether you need an independent test record for audit or model risk reviews. Confirm your own skill and capacity gaps before you decide.

How does rescheduling interact with our existing product mix and migration?

Rescheduling acts on individual active loans, so its rules must match each product's interest method, grace settings, repayment strategy and any floating rate or progressive configuration. A product mix that includes multi-disbursement, interest recalculation or grace on arrears ageing needs its interactions tested, not assumed. If you are migrating loans into Fineract, confirm that the imported schedules and balances are in a state where rescheduling behaves as expected, and plan that check before go-live. Re-aging on progressive loans is a different mechanism, so do not treat the two as interchangeable in your rules.

What should we confirm in writing in a fixed-scope quote?

Ask for the list of loan products and rescheduling types in scope, the approval workflow to be configured, the test scenarios and acceptance criteria, the environments used, and who performs each test. Confirm the deliverables, such as configuration records, test evidence and operating procedures, and the dates or milestones that trigger payment. Also confirm what is excluded, including integrations, reporting changes, data migration and training, and any post-go-live support. Clarify whether the quote covers one platform version or includes upgrade work, and how change requests are priced if your credit policy changes mid-project.

Does DeployOpen issue audit or compliance certificates for rescheduling controls?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, including documented rescheduling rules, approval records and test results. Independent auditors and certification bodies issue audit reports, attestations and certifications. Ask your auditor which evidence they expect to see for loan modifications, and agree the evidence format before testing begins so the same records serve your internal review and any external assessment.

How DeployOpen scopes and delivers loan rescheduling

DeployOpen treats loan rescheduling in Apache Fineract as a configured, tested and documented change to how active loans are restructured, not a one-off data edit. The work starts with the written scope, covers the products and loan types in play, and ends with the operating procedure your staff will follow after handover.

How we scope

The written scope lists which reschedule scenarios are in play: extra grace on principal or interest, extra terms, and interest rate changes.
We confirm which loan products and loan types need the flow, including whether any progressive loans need a different rule than re-aging.
Approval roles, maker and checker separation, and who may preview a schedule are agreed before any configuration starts.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.

How we build

We configure the reschedule request flow in a non-production tenant and record each setting against the requirement it satisfies.
Test cases cover preview, approval and rejection, and the resulting schedule, installment amounts and accrued interest on sample loans.
Accounting and reporting effects of each reschedule type are checked against the ledger mapping agreed for your chart of accounts.
Environment access, test data and sign-off steps follow the controls your organization already applies to production changes.

How we hand over

You receive the configuration record, test evidence and a runbook describing when each reschedule type applies and who approves it.
Staff training covers how to read the previewed schedule and what to check before approving a request on an active loan.
Operating notes state which reschedule outcomes need manual review and which follow the configured rules.
Handover documentation is written so your own team can repeat the procedure without DeployOpen present.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so rescheduling rules can follow policy changes.
Retainer support can cover regression testing of the reschedule flow when you move to a new Fineract release.
Confirm with DeployOpen which upgrade and support terms apply to your environment before the scope is signed.