Progressive vs cumulative loans in Apache Fineract: which schedule type, and why it matters

(Quick disambiguation, because search engines confuse the two: this is about Apache Fineract's loan schedule types, not Progressive Leasing or any rent-to-own product.)

When you create a loan product in Fineract, one setting quietly decides more than almost any other: the loan schedule type. There are two, cumulative and progressive, and the default is cumulative. Most people leave it there, because the field is easy to miss and the docs describe the two in isolation rather than as a choice. The catch is that the choice is sticky. A loan is locked to its product's schedule type the day it is created, and a whole set of newer Fineract features only work on one of the two.

We run managed Fineract, so we set this up for a living and answer the "which one do I pick" question often. Here is the honest version: what the two types actually do, what changes the moment a loan gets a second disbursement, what progressive unlocks that cumulative cannot, and a straight recommendation for when to use each.

The one difference that matters: what happens on a second disbursement

Both types handle a simple single-disbursement loan almost identically. The difference shows up the moment a loan is funded in more than one go, which is exactly the case for construction lending, stage-funded business loans, BNPL, and anything line-of-credit shaped.

Take one loan: 12,000 over 12 monthly installments, but disbursed in two tranches of 6,000, the second one in month 4. To keep the mechanics visible, the chart below shows only the principal per installment (interest accrues on the outstanding balance on top of this). The numbers are illustrative, but the behavior is real.

Progressive only ever looks at money that has actually been disbursed, and it only ever recalculates installments that have not happened yet. The first four installments were set at 500 when 6,000 was drawn, and they stay at 500 forever. When the second 6,000 lands in month 4, it gets spread across the eight remaining installments, which step up to 1,250. The past is frozen. The borrower pays for what they have drawn, from the date they drew it.

Cumulative does the opposite. It spreads every disbursement across all installments, including ones that have already been paid. So when the second tranche lands in month 4, Fineract recalculates the whole schedule, and the four installments the borrower already paid at 500 are now "supposed to be" 1,000. That backdated adjustment ripples through already-executed installments and the transactions attached to them. For a planned, evenly disbursed loan that is fine, and it is even what you want. For a loan where disbursements are not written in stone, it is a recalculation headache and a borrower-statement headache.

That single behavioral split is the whole reason progressive exists.

Why progressive exists

Progressive is the newer of the two, and it did not arrive by accident. In 2024 the Fineract project formally adopted FSIP-3, a proposal to build out a new progressive loan module and, over time, "ideally deprecate the legacy loan module." It passed a PMC vote. The stated reason was blunt: the legacy loan module was "far too complicated to build these new loan capabilities onto." The trigger was a real enterprise customer moving its BNPL and installment products onto Fineract, products the cumulative engine could not serve cleanly because of exactly the recalculate-the-past behavior above.

So progressive is not a cosmetic alternative. It is the engine the project intends to grow into, rebuilt to handle modern lending: declining-balance interest with daily calculation, interest recalculated forward only, and the math moved onto proper decimals instead of the old hard-coded 30-day-month assumptions.

It also comes bound to a different repayment strategy. A progressive product must use the Advanced Payment Allocation strategy, and that strategy cannot be used on a cumulative product. They are two halves of the same design. Advanced Payment Allocation is what replaced the old hard-coded repayment-ordering strategies (mifos-standard, rbi-india, and the rest) with rules you configure per transaction type: which bucket a payment fills first, whether it works horizontally across one installment at a time or vertically down one balance type across all installments, and how to handle reamortization and reaging. If you have ever wanted to control how a payment is applied and found Fineract's fixed strategies too rigid, that flexibility lives on the progressive side.

What progressive unlocks (and what works on both)

This is the part that makes the choice consequential. A long list of features Fineract has added since 2024 only work on progressive products. The code rejects them outright on cumulative. Here is the verified split.

Progressive only:

• Advanced Payment Allocation (configurable repayment ordering, horizontal or vertical processing)
• Charge-off behaviour (regular, zero-interest, or accelerate-maturity, covered in our charge-off accounting post)
• Interest refund on early repayment and merchant-issued refunds
• Interest pause (interest-free periods mid-loan)
• Capitalized income and buy-down fees (the deferred-income accounting features)
• Loan re-amortization and re-aging
• Backdated interest rate changes and per-product day-count customization

Works on both schedule types, despite what you may have read:

• Down payment. Down payment is configured by a single product flag and works on both cumulative and progressive. This one is worth calling out because a lot of material online, including some of our own older documentation we are now fixing, says down payment is progressive-only. It is not. The Fineract code has an explicit cumulative branch for it.
• Multiple disbursements. Both support multi-tranche loans. The difference is not whether you can, it is how the schedule reacts, which is the whole point of the first section.
• Interest recalculation in general. Both can recalculate; progressive just does it forward-only by design.

If your product roadmap includes any of the progressive-only features, the decision is made for you. Pick progressive.

The honest part: progressive is the future, cumulative is still the present

It would be easy to end with "use progressive, it is newer." That is not the honest answer.

Progressive is younger, and it shows. As recently as early 2026 a critical pre-payment miscalculation was being fixed in the progressive interest engine, and a Fineract PMC member, asked directly in April 2026 whether progressive was production-ready, gave a measured answer: a handful of organizations run it in production, but named gaps remain around floating interest rates, variable installments, top-up loans, and collateral. The interest-recalculation paths in particular absorbed a wave of edge-case fixes through 2025. Progressive is solid and improving fast, but it is still maturing, and if your needs touch one of those gap areas you should test thoroughly before committing.

Cumulative, meanwhile, is not going anywhere soon. The same PMC member confirmed that deprecating it is not currently planned, and it remains the engine for traditional microfinance: simple, predictable, equal installments, well-worn over a decade of production use. The "deprecate the legacy module" language in FSIP-3 is a direction, not a deadline. Cumulative is the supported present.

So the real framing is not new versus old. It is: progressive is where all new development goes, cumulative is where a decade of stability lives, and you are choosing which of those two profiles fits the product in front of you.

So which one should you pick?

Use cumulative when your loans are simple and fully disbursed up front: a standard term loan, a classic microfinance product, anything where the borrower gets the money once and repays it in equal installments. You get a schedule that is fixed and predictable from day one, an engine with a long production track record, and fewer moving parts. Do not reach for progressive just because it is newer.

Use progressive when any of these is true:

• Disbursements happen in stages (construction, BNPL, working-capital lines).
• The outstanding balance can change after origination and you do not want earlier installments rewritten.
• You need any progressive-only feature: charge-off behaviour, interest refund, interest pause, capitalized income, buy-down fees, configurable payment allocation.
• You are starting fresh and want to build on the engine the project is investing in.

One thing the decision does not let you defer: you cannot change it later. Schedule type is fixed on the loan product, and a loan inherits it permanently at creation. There is no "switch this loan from cumulative to progressive" operation. If you might need progressive features down the line, it is far cheaper to start the product on progressive than to migrate loans off cumulative after the fact.

The short version

Cumulative spreads every disbursement across the entire schedule, including installments already paid. Progressive only touches future installments and only counts money actually drawn. That single difference is why progressive exists, why a growing list of features are progressive-only, and why staged-lending products belong on progressive while simple term loans are perfectly happy on cumulative. Pick deliberately, because the loan is stuck with your choice.

The configuration details, the full payment-allocation rules, and the charge-off behaviour options are in our progressive loans guide. If you would rather not work out which schedule type, allocation strategy, and recalculation settings your product needs, that is the part we take off your plate. Finecko runs managed Apache Fineract, set up correctly for the products you actually offer, so the schedule behaves the way your borrowers and your auditors expect.