Apache Fineract loan product configuration guide

Apache Fineract loan product configuration starts with the decisions that cannot be changed later

A team preparing to offer loans on a self-hosted Apache Fineract platform needs to understand one thing before anything else: the loan product is where most of the consequences sit. A Fineract loan product sets the repayment schedule, interest method, fees, delinquency behavior and ledger postings for every loan issued under it, and a mistake in any of these settings surfaces later as a customer balance that is wrong, disputed or hard to explain. Configuration is therefore not a technical formality to finish before the real work starts. It is the point where the product design becomes live behavior.

Fineract is a headless application. It exposes REST APIs and does not provide its own user interface, so product setup is carried out either through the API or through a front end the client chooses or builds. The Fineract README points to the Mifos X web application as the front end used in its Kubernetes example, but that is an example, not a requirement. The current stable release on the Fineract website is 1.15.0, and official releases are created quarterly at the end of each quarter. Teams should confirm in the platform documentation which product attributes are available in the release they plan to deploy, because the options a product exposes can differ between versions.

Configuration is the part of the project where accounting, credit and operations choices meet. The finance team cares how interest is recognized and how fees map to income and receivable accounts. The credit team cares about amortization, grace periods, penalties and how arrears are classified. Operations cares about how a product behaves when a payment is late, partial or reversed. Before building anything, the team should write down who owns each setting, what each choice posts to the general ledger, and which options are judgment calls that need sign-off from both finance and risk.

Some of these decisions are effectively permanent for a product that has already issued loans. Changing an interest method, repayment frequency or fee structure after loans exist does not simply update those loans. It raises a migration question: whether existing accounts keep the old terms, move to the new product, or are restated, and how the accounting entries for past periods are treated. Teams should ask their implementation partner to confirm in writing how Fineract handles a product change on live accounts in their chosen version, and should plan a test of that change before any product goes live.

The practical step is a configuration register kept before the first build. For each loan product, record the intended repayment schedule, interest method, fee and charge rules, delinquency stages, and the ledger account each posting should hit. Then run each product through a set of test loans covering early repayment, missed installments, partial payments and reversals, and reconcile the results with finance. This register also becomes the baseline for later upgrades and regression testing, so the decisions made here are the ones the rest of the platform depends on.

Which Fineract loan product settings decide the outcome

A Fineract loan product is a bundle of decisions that together determine how money is lent, priced, collected and recorded. The cards below cover the settings a team configures for each product and who in the institution should approve each one. Confirm the exact option names and available methods in the Fineract 1.15.0 documentation and in the front end you use, since this page does not list them.

Principal and term limits

Minimum, maximum and default principal and term ranges define the loans a product can originate and the amounts the system will accept at application. Credit risk should set these limits, and product management should confirm them against the credit policy. Check that the limits match the policy document exactly, because a mismatch here lets officers book loans the policy does not allow. Confirm in the Fineract documentation which limit fields exist and how they are enforced on application and on restructuring.

Repayment schedule and amortization type

The amortization method determines how each installment splits between principal and interest and how the schedule is generated at disbursement. Credit risk and finance should agree on the method, and the product owner should confirm it matches the loan agreement the customer signs. Test several loan shapes, including irregular first periods and early repayments, before launch. Confirm the schedule types and rounding behavior available in your Fineract version.

Interest calculation and accrual method

Interest settings define the rate basis, the day-count convention, how often interest is calculated, and whether it accrues daily or on due dates. These choices change the customer's payoff figure and the income recognized in each period. Finance and compliance should sign off, since the accrual method must align with the accounting policy and the disclosures given to borrowers. Confirm the supported calculation and accrual options in the Fineract documentation before writing the policy.

Fees, charges and penalties

Disbursement fees, late payment charges and penalty rules are configured as charges attached to a product, each with its own trigger, amount or percentage and posting behavior. Pricing owners and legal should approve the wording and amounts against the tariff and consumer disclosures. A charge that posts incorrectly is hard to reverse once customers have paid it, so test each charge on sample loans. Confirm how each charge type is calculated and when it is applied in your version.

Grace and moratorium periods

Grace and moratorium settings allow a loan to defer principal, interest or both for a set period, which changes the schedule and the timing of arrears. Credit risk and the collections lead should agree when these periods may be granted and who may approve exceptions. Verify that a grace period does not accidentally suspend interest accrual unless the policy says it should. Confirm which grace types the platform supports and how they interact with the repayment schedule.

Delinquency buckets and aging

Delinquency buckets group overdue loans by days past due, and they drive provisioning, collections queues and regulatory reporting. Risk and the collections team should define the bucket boundaries, and compliance should confirm they match the reporting requirements that apply. Errors here distort both reserves and early-warning reports, so reconcile bucket totals against the ledger at month end. Confirm how aging is computed and which buckets are configurable in your Fineract version.

Product-to-ledger accounting mapping

The accounting mapping links each product's income, receivable, fee and provision events to general ledger accounts in the chart of accounts. Finance must approve every mapping, and the controller should confirm the cash or accrual basis the mapping assumes. A wrong mapping does not fail loudly; it posts balances to the wrong accounts and surfaces only at reconciliation. Test end-of-day postings for each product against the ledger before go-live. Confirm the mapping options and journal behavior in the Fineract documentation.

Which loan product decisions to make before building

This table compares five product design decisions in Apache Fineract loan product configuration, showing when each option fits and what it costs to run afterward. Read each row as a choice to settle with credit, finance and operations before any product is built. The main takeaway is that every option that reduces product count or simplifies one rule usually shifts cost into charges, reporting or regression testing after upgrades.

Decision	Option	When it fits	Operational cost
Interest method	Flat interest on original principal	Short, simple consumer products where the customer expects a fixed interest amount per installment	Harder to reconcile against the outstanding balance if customers prepay, so confirm how early repayment is calculated and tested
Interest method	Declining balance interest	Standard amortizing lending where interest should fall as principal is repaid	Schedule logic is more sensitive to repayment order and early payments, so expect more scenario tests for each product
Repayment structure	Equal installments	Customers and credit teams want predictable payment amounts across the term	Early installments carry more interest, so reporting on principal reduction and arrears needs clear explanation to staff
Repayment structure	Fixed principal per installment	Segments where the principal reduction should be even and the first payments are expected to be higher	Installment amounts vary, so customer communications and collection scripts must reflect the declining payment profile
Product scope	One product per credit segment	Segments differ in rate, term, collateral or regulatory treatment and need separate reporting	More products to maintain, each needing its own regression tests after every Fineract upgrade
Product scope	Broad product with charges and variants	A small number of similar loans where differences are limited to fees or optional add-ons	Charge rules become complex, and reports by segment may require extra logic outside standard product fields
Fee timing	Fee charged at disbursement	Upfront arrangement or origination fees that the institution collects from loan proceeds	Fee effects appear early in the schedule, so accounting mapping and customer disclosures must match exactly
Fee timing	Fee charged per installment	Recurring service or administration fees tied to each period of the loan	Each installment carries fee logic, which adds test cases for skipped, late and partial payments
Delinquency rules	Delinquency rules set per product	Segments with different tolerance, grace periods or write-off policies, such as secured and unsecured lending	Each product needs its own delinquency tests and reporting checks, and staff must know which rule applies
Delinquency rules	Shared delinquency rules	Portfolios where one arrears policy applies across all products and credit committees want one standard	Products with real differences may be forced into one rule, so confirm with credit risk before accepting shared settings

How to configure an Apache Fineract loan product step by step

This sequence takes a loan product from a signed credit policy to an approved configuration that credit, finance and operations can trace back to written decisions. Each step ends with a check, so mistakes surface in a non-production tenant before any customer loan exists.

Confirm the credit policy and fee schedule in writing
Credit, finance and the product owner agree the product terms on paper before anyone changes the configuration. The specification covers target segment, maximum principal, term range, repayment frequency, interest basis, every fee and charge, and penalty rules. Each term has a named owner and a decision date. Ask your implementation partner or internal team to map each term to a configuration field the platform exposes, so unsupported terms appear now and not during testing. The step is done when credit and finance have signed the specification and every open question is logged with an owner.
Create the product in a non-production tenant
Create the product in a test tenant that holds no customer data. Fineract is multi-tenant and API requests carry a tenant identifier, so confirm the tenant used for configuration is the one your test scripts and reviewers point to. Record the product name, the tenant identifier and the Fineract version your environment runs (the current stable line is 1.15.0 at the time of writing, so confirm your deployed version). The check is that the product appears in the test tenant with the name and identifier from the specification, and nowhere else.
Set principal, term and repayment frequency
Enter the minimum, maximum and default principal, the term range with its unit, and the repayment frequency from the signed specification. Check each value against the specification line by line, including currency and decimal handling, because a single wrong default propagates to every loan created from the product. Then create a test loan at the minimum, default and maximum values and confirm that the system accepts the valid combinations and rejects the out-of-range ones. The step is done when a reviewer other than the person who entered the values has ticked every field against the specification.
Select amortization and interest calculation methods
Choose the amortization method, the interest calculation basis, the day-count convention and how interest accrues between repayments, as set out in the specification. These choices change every installment, so confirm each option's behavior in the Fineract documentation for your version and in the front end you use. Generate a sample repayment schedule for one representative loan and compare it to a hand calculation prepared independently. The check is that every installment, interest and principal split, and the final balance match the hand calculation, and that credit has signed the comparison.
Add fees and charges with their trigger events
Add each fee and charge from the specification and set its amount or percentage, its calculation basis and the event that triggers it, such as disbursement, a specific installment date, or a manual action by staff. Trigger events determine when money moves, so write them down next to each charge before configuring it. Test each charge on a test loan and confirm it posts once, at the expected event, and only for the intended loans. The check is a short test table listing each charge, its trigger, the expected amount and the observed amount, signed by finance.
Configure delinquency and penalty handling
Set the delinquency buckets, the grace periods, the penalty rules and the actions that follow each stage, as the credit policy describes them. Confirm which penalties accrue automatically and which require a staff action, and how a payment is applied across fees, penalties, interest and principal. Simulate a missed installment on a test loan and advance the test date to confirm that the loan moves to the expected bucket and that the penalty posts once. The check is a delinquency test script with expected and actual results, reviewed by credit and operations.
Map the product to ledger accounts with finance
Work with finance to map each product output, including principal, interest, fees, penalties and any write-off or provisioning account, to a specific general ledger account in your chart of accounts. Agree whether the institution uses cash or accrual treatment for each item before mapping it. Post test transactions and reconcile the resulting journal entries to the expected totals from the test schedule and the delinquency test. The step is done when finance signs the mapping table and the reconciliation of test postings shows no unexplained differences.
Approve the product through change control
Submit the configured product to the institution's change control process with the signed specification, the test evidence from each earlier step and the open-items log. Before approval, confirm with your vendor and the Fineract documentation which settings can still be edited once live loans exist on the product, and document any that cannot be changed without a new product. Record the product version, the tenant and the configuration export at the point of approval, and store them with the change record so each later change can be compared against this baseline. The step is done when the approver signs the change record and the export is archived.

Why repayment schedules and delinquency rules must agree

A repayment schedule in Apache Fineract is only correct if the nightly processing agrees with it. The schedule a borrower sees in a statement or app is generated from the loan product's terms: the amortization method, the interest recalculation settings, the repayment frequency and the grace periods. The Close of Business (COB) batch then accrues interest, applies penalties and fees, and updates overdue status against that same schedule. When these pieces are configured separately and tested separately, a borrower can be shown one amount while the ledger accrues another. Treat the schedule, the accrual logic and the overdue logic as one design problem and review them together before any product goes live.

Delinquency aging depends directly on due dates and grace settings. If the grace period, the due-date rule for weekends or holidays, or the installment allocation order is set differently from what the business expects, a loan can age into a delinquency bucket a day early or late, and the provisioning, collections queue and borrower notices built on that bucket will be wrong too. Ask the product owner to write down, for each product, when an installment becomes due, how long the grace period runs, when a missed payment becomes overdue and which bucket it lands in. Then check the Fineract configuration against that written rule, not against memory of how the product was meant to work.

The Fineract README states that the Close of Business Day Spring Batch job can run for several hours on deployments with millions of accounts. This matters for testing. A single test loan processed by hand will not reveal how accrual and aging behave when the batch processes a full day of real activity across many products, partial payments, reversals and backdated transactions. Plan a test run that replays a full business day of activity against a realistic data volume in a non-production environment, and compare the closing balances, accrued interest and overdue amounts with an independent calculation. The exact volume your environment can handle depends on your hardware and database, so measure it rather than assume it.

Confirm, in the documentation for the Fineract version you deploy, which batch steps touch interest, penalties and aging. The official platform documentation at the Apache Fineract site and the apache/fineract repository are the references to check, and the current stable release at the time of writing is 1.15.0. Record the step names, their order and any configuration that changes their behavior. Then test one loan through several due dates, including a payment on time, a partial payment, a missed payment that moves the loan into grace and then overdue, a catch-up payment and a reversal. Compare the schedule, the accrued amounts and the aging after each batch run with your expected values. Repeat the test whenever the product, the batch configuration or the Fineract version changes.

How loan product setup differs across single node, high availability and Kubernetes

On a single node, one Fineract instance handles every workload: configuration writes, customer and account reads, and the nightly batch. Loan product changes therefore compete for the same application resources as day-to-day operations, and there is no separate instance to absorb a heavy read load while a product is being edited. The setup is simpler to operate, but the team has fewer places to isolate a problem.

What to test differently:

Create and edit loan products while the Close of Business job is running in a non-production copy, and confirm that both complete without errors or contention.
Confirm that a product change made during business hours is picked up by subsequent account operations and does not alter schedules already generated for open loans.
Measure response times for product configuration screens and API calls under a realistic transaction mix, using your own test data.
Test restart behavior: stop the instance during a batch run, start it again, and confirm that repayment schedules and accruals are not duplicated.
Record the upgrade path for the single instance, including the database migration step and the rollback plan.

Before sign-off, ask your implementation partner to show the test results for batch timing and restart on a copy of your own data volume.

How to test Apache Fineract loan products before launch

A loan product in Apache Fineract is only ready for launch when it has been tested against signed-off numbers, across its whole lifecycle, and against the ledger it feeds. Build the test plan in four layers, and treat each layer as a gate that must pass before the product is offered to customers. The first layer checks the repayment schedule and interest. Take a set of worked examples that the credit, finance and product owners have signed off, covering each interest method, grace period, moratorium and day-count rule the product uses. Enter the same inputs into the test tenant, then compare the generated schedule, installment amounts, rounding of the final installment and accrued interest line by line. Any difference is a configuration error until proven otherwise.

The second layer covers fee and charge triggers across the loan lifecycle. Each charge attached to the product, whether applied at disbursement, on a due date, on a late payment or on demand, needs a test that fires it and a test that proves it does not fire when it should not. Include early repayment, partial prepayment, and the reversal of a payment and a rejected payment, because these change balances after the fact. Confirm that a reversal restores the state the schedule had before the payment, and that a rejected payment does not leave a charge or a posted transaction behind. Record the expected balances for each step in a table before running the test, so the result is compared against a written expectation rather than against whatever the system returns.

The third layer tests delinquency and penalty behavior over several cycles, not one. Run an account through missed payments, partial catch-up, further missed payments and final repayment, using the delinquency buckets and penalty rules configured for the product. Check when a loan moves between buckets, when penalties accrue and stop, and whether the delinquency state clears correctly after a catch-up. The fourth layer reconciles accounting postings to the trial balance. For each test scenario, confirm that every journal entry maps to the intended general ledger account from the product mapping, and that the sum of postings for the test run matches the change in the trial balance for the test tenant. Finance should sign off this reconciliation, not only the engineers who built the configuration.

Two practices keep this plan reliable over time. First, the test tenant should mirror production configuration, so compare configuration exports from the test and production tenants before each test cycle and resolve any drift. Second, keep a regression pack for each product, and re-run it after every Fineract upgrade. Upgrades are released quarterly, so the pack should be part of the upgrade runbook and not a one-off exercise at launch. If any external consumer, such as a payment, notification or reporting system, depends on loan changes, confirm with your team which business events Fineract publishes, because external event publishing is disabled by default according to the README. Test those consumers against the same scenarios, since a loan change that is not published is invisible to them.

Finally, test the failure cases on purpose. Select the wrong product for an applicant on a test account and confirm the system's controls stop the loan from being created or disbursed under that product, and that a correction path exists without leaving orphaned accounting entries. Change a product's configuration after a loan has been disbursed, then verify that the existing loan keeps its original terms, schedule and charges, and that the change applies only to new loans as your policy states. Interrupt the Close of Business batch job partway through a run, then restart it and confirm that no transaction is posted twice, no charge is applied twice and the trial balance still reconciles. Write down the expected safe outcome for each failure before running it. If the team cannot describe that outcome, the product is not ready to launch.

What drives effort and cost in loan product configuration

This table lists the main drivers that change how much work loan product configuration takes in Apache Fineract, with how each one raises effort and how to keep it down. Read each row against your own product catalog and integration list, then ask a partner to price the drivers you actually have. The main takeaway is that decisions made before build, such as a signed policy document and a shared product design, usually cost less than rework after testing begins.

Driver	How it raises effort	How to reduce it
Number of products and credit segments	Each product needs its own terms, schedule rules, fee set, accounting mapping and test cases, so effort grows with the catalog rather than with the number of customers.	Consolidate products that differ only in amount or term, and share rule sets across segments where the policy allows.
Complexity of fee and penalty rules	Conditional fees, penalties tied to days past due, and fees that depend on loan amount or product type multiply the scenarios that must be built and tested.	Agree the fee schedule in a written table before configuration, and remove rules that no current product uses.
Number of repayment and interest variants	Each combination of amortization method, grace period, moratorium, interest calculation period and rounding rule needs its own schedule verification.	Limit the first release to the methods the business will actually sell, and add variants later through a controlled change.
Accounting mapping complexity with finance	Every product, charge and write-off must map to general ledger accounts, and unclear cash or accrual decisions force rework once journals are reviewed.	Finalize the chart of accounts and the cash or accrual choice with finance before product build, and sign off a mapping table.
Number of integrations that read loan data	Payment, reporting, collections and CRM systems that read schedules or balances need field-level agreement, so product changes can break downstream consumers.	Publish a data dictionary for loan fields early and treat schedule output as a versioned contract with each consumer.
Number of environments and tenants	Each environment needs the same product configuration applied and verified, and each tenant may need its own products, fee rules or branding.	Manage product definitions as versioned configuration that is promoted between environments, and use one reference tenant for shared rules.
Customization needed beyond configuration	Rules that standard product settings cannot express need custom code, which adds design, development, review and regression effort on every upgrade.	Confirm each requirement against configurable options first, and isolate any custom logic in separate modules so upgrades remain possible.
Compliance evidence requirements	Assessors and internal audit may ask for signed product approvals, change logs, test records and proof of who approved each rate or fee, which adds documentation work.	Agree the evidence list with compliance before build, keep approvals in a signed policy document, and reuse a standard test pack for each product.

What to hand over and maintain after loan products go live

The handover for loan products should give the operating team everything needed to change, test and audit those products without relying on the people who built them. At minimum, the package should include exported product configurations for each tenant, the signed fee and repayment schedule specifications that the configurations are meant to reflect, the worked-example test results, the accounting mapping document that links each product, fee and charge to its ledger accounts, a change log tied to the Fineract release version in use at each change, and the regression pack used to test the products. Ask your implementation partner to confirm the exact format of each item, and check that the exports can be re-imported or compared against a live tenant without manual retyping.

Before go-live, confirm with your chosen front end which of these items it can export. Fineract is headless and exposes REST APIs, so product definitions, fee rules and accounting mappings may need to be pulled through the API, and the front end you select (for example, the Mifos X web application used in the project's Kubernetes example, or another client you build or buy) may not export all of them in a usable form. If a product definition cannot be exported, the change log and the signed specifications become the only record of what was configured, which makes them critical. Record the gap as a risk and decide who owns the manual evidence before launch.

Ongoing work starts with regression. Re-run the product regression pack after each quarterly Fineract release, since the project creates official releases at the end of each quarter, and compare the worked-example results against the signed specifications. Schedule this as a standing task with a named owner rather than an ad hoc activity. Also review the Liquibase migration notes for each release before upgrading the write instance, because Liquibase migrations run only on write instances and can change the database schema under your products and accounting configuration. Test the upgrade on a non-production tenant first, and keep the regression results with the release change log.

Operational monitoring closes the loop. Track Close of Business completion every day, because the batch job applies interest, fees and delinquency processing across the loan book, and a failed or late run will show up first as incorrect balances or missing postings. Review delinquency reports against the delinquency rules in the product configuration, and reconcile the accounting outputs with finance on a schedule agreed in advance. Where Close of Business runs for several hours at scale, agree with operations what time window is acceptable and who is alerted on failure.

Finally, put every product change through maker-checker control. Staff who configure products should not be the same people who approve them, and the approval should be recorded in Fineract with the reason for the change, the affected products and the release version. Review the maker-checker roles and permissions periodically, because access creep is common when staff move between teams. Ask your partner to explain how maker-checker is configured in your deployment and how an auditor would be shown the approval trail for a sample of product changes.

How to control who can change loan products in Fineract

Loan products define rates, fees, schedules and ledger postings, so a change made by the wrong person or without review can affect every account opened afterward. The controls below work together: remove default access, limit who can change products, review changes before they go live, and protect the connections and credentials that carry those changes. Each card names the control, the failure it prevents and what to confirm in your own deployment.

Replace the default development login

Fineract's README ships a default development login (username mifos, password password) for HTTP basic and OAuth2 testing, and it must be changed before any real deployment. Before configuring products, remove or disable that account in every environment, including staging, so no one can edit products with a known credential. Confirm that no environment still accepts the default login by testing it directly against the API.

Restrict product rights to named roles

Product creation and editing should sit with a small set of named roles, separate from teller, loan officer and reporting roles. Map each role to the specific product permissions it needs, and record who holds each role. The failure this prevents is a routine operator silently changing an interest method or fee on a live product. Confirm in your version which permissions govern product create, update and read, and test each role with a non-admin account.

Require a second approver for changes

Product changes should go through a maker-checker step in which one person proposes the change and a different person approves it before it takes effect. Without this, a single privileged user can alter repayment rules, penalties or accounting mappings with no independent review. Confirm whether your Fineract version and identity setup enforce maker-checker for product changes, or whether you must enforce it through a documented change process and audit review.

Enforce HTTPS for all API traffic

Product configuration, client data and credentials all travel over the Fineract REST API, so plain HTTP exposes both. The Fineract documentation strongly encourages HTTPS only and documents SSL settings through environment variables such as FINERACT_SERVER_SSL_ENABLED. Set these variables for every instance, including read, write and batch instances, and confirm that the load balancer and any front end also refuse unencrypted connections.

Keep API client credentials out of exports

Configuration exports, backups and copies of product definitions are often shared between teams, and they should never contain API client secrets, OAuth2 client credentials or database passwords. Store these in a secrets manager and reference them at runtime. The failure this prevents is a shared export that gives a third party a working integration credential. Confirm which exports your team produces, search them for secrets before distribution, and rotate any credential that has appeared in one.

Questions teams ask before configuring Apache Fineract loan products

How much effort does Apache Fineract loan product configuration take?

Effort depends on how many products you need, how far they differ from each other, and how many rules must be decided before anyone touches the configuration. A single standard amortizing loan with one fee schedule is a small exercise. A portfolio with several repayment methods, interest accrual rules, penalty and fee structures, delinquency buckets and separate accounting mappings is a much larger one. The biggest driver is usually not the typing in Fineract but the decisions behind it: a credit policy that is final, a fee schedule that finance has approved, and an accounting map that has been agreed. Ask any quote to break effort down by product, by rule type and by testing, so you can see which parts scale with the number of products.

Can an in-house team configure Fineract loan products without a partner?

Yes, a team with banking product knowledge and Fineract experience can do it, and some institutions prefer that. The question is whether the skills, time and review capacity exist in-house. The project's own README warns that a production deployment can be complex, costly and time-consuming, and that the project does not provide a comprehensive production deployment guide. Configuration also touches accounting, delinquency handling and testing, so your team needs people from credit, finance, operations and engineering. If you go it alone, confirm who owns each decision, how test loans will be checked against expected results, and who will run regression tests after each quarterly release.

What does the institution need to provide before loan products can be configured?

Configuration is only as good as the decisions it encodes, so the institution must supply four things before work starts. First, a credit policy that sets eligibility, limits, terms and collateral rules for each product. Second, a fee schedule covering origination, late payment, prepayment and other charges, with the conditions for each. Third, sign-off from finance on how each product posts to the general ledger, including accrual or cash treatment. Fourth, a set of test loans with expected schedules, balances and accounting entries, so the configured products can be checked against known answers. Missing any of these usually causes rework during testing, which is where schedule or posting errors are easiest to find.

How long does loan product configuration take?

The duration depends on scope, and no single number applies across institutions. The main inputs are the number of products, whether the institution is starting from a blank configuration or migrating existing products, how quickly the policy and accounting decisions are made, and how much testing is required before launch. A narrow scope with decisions already documented moves quickly. A broad scope where credit, finance and operations disagree on rules will take longer regardless of technical skill. Ask for a timeline tied to written milestones, such as sign-off on the product design, completion of configuration, and completion of test loan verification, rather than a single end date.

Can loan products be changed after loans already exist in Fineract?

Changing a product after loans exist is possible but needs care, because existing loans carry their own terms, schedules and postings. Changes to a product definition generally affect new loans, while existing loans keep the terms they were created with unless a specific change process is applied. This is why the design must be settled before the first live loan is written. Confirm with your Fineract version exactly which product attributes can be edited on active products and how existing accounts behave after an edit. Any change that alters interest, fees or accounting should be tested against a copy of live data before it reaches production.

Can a fixed-scope quote cover both loan product configuration and testing?

Yes. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A useful quote should list each product in scope, the repayment, interest, fee and delinquency rules to be configured, the accounting mapping, the test loans and expected results, and the acceptance criteria for each deliverable. It should also state what the institution must provide and by when, because late decisions are the most common cause of schedule change. Ask what happens if scope changes during testing, how that is priced and approved, and whether regression testing after a later Fineract release is included or offered separately as a retainer.

What should a loan product test plan check in Fineract?

A test plan should check that each product produces the expected results for known inputs, and that those results post correctly. For each product, test loans should cover disbursement, a full repayment schedule, interest accrual across period boundaries, fee application, late payment and penalty handling, delinquency progression, prepayment and closure. Each test should compare the Fineract output against an expected schedule and expected ledger entries that finance has signed off. Include negative cases such as invalid amounts and out-of-policy terms. Keep the test set, expected results and the release it was run against, so the same checks can be repeated when Fineract is upgraded.

How DeployOpen scopes, configures and hands over Fineract loan products

DeployOpen configures Apache Fineract loan products inside the client's own infrastructure, starting from a written scope that names each product, its repayment and interest rules, fees, delinquency handling and ledger mapping. Each product is built, tested against agreed cases and documented so the client's team can operate and change it after handover.

How we scope

The written scope lists every loan product, with its repayment schedule, interest method and fee rules.
Delinquency stages, write-off rules and the accounting mapping for each product are defined before build starts.
Scope confirms which Fineract version and PostgreSQL environment the products will run on.

How we build

Products are configured in Fineract's supported product settings, with changes recorded so they can be reviewed.
Test cases cover schedule generation, interest accrual, fee posting, arrears classification and journal entries for each product.
Accounting mapping is checked against the client's chart of accounts with finance before any test sign-off.

How we hand over

Handover includes a product catalogue documenting settings, rules, ledger mappings and the test evidence behind each one.
Staff receive a walkthrough of how to create, amend and retire products and which changes need maker-checker approval.
Client teams own the configuration records, with the open issues and assumptions listed in the handover pack.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and regression testing of loan products are available as a retainer.
Product changes after go-live are tested again against the same cases before they reach production.

Apache Fineract loan product configuration