Apache Fineract chart of accounts and accounting rules

Why the Apache Fineract chart of accounts decides whether finance can trust the ledger

The chart of accounts and the product-to-ledger mapping are design decisions that are expensive to change once transactions have posted. A bank or lender configuring Apache Fineract needs a general ledger that finance can close every month, and that outcome depends on how accounts, products and posting rules are defined before the first loan or deposit is booked. Fineract provides real-time integrated accounting and configurable products, but it does not decide the institution's account structure, accounting basis or reconciliation routine for it. Those choices belong to the institution, and they have to be made with finance at the table.

The difficulty is that the platform makes product configuration look simple. A new loan or savings product can be created in a few screens, and each product carries accounting mappings that route interest, fees, principal and deposits to ledger accounts. When a product is changed later, the team must decide how existing accounts behave, whether historical postings stay where they were, and how finance will explain the difference in the period it was made. In a multi-tenant setup, each institution or brand may need its own account structure on the same platform, which multiplies the number of mappings to design and review. Backdated postings add another layer, because a transaction entered for a past date can land in a period finance has already reported.

A further gap sits between operational balances and the ledger. Customer-facing balances in the core show what a client owns or owes, while finance's ledger shows what the institution has recognized and where. These views match only if every product mapping, accrual and reversal is correct and the team runs a routine that compares them. Operations teams should not assume that a balance on a loan screen equals the figure in the general ledger for the same date. Plan a reconciliation step that compares subledger totals with control accounts, and agree who signs it off and how exceptions are cleared before the close.

The Fineract README warns that a production deployment can be complex and time-consuming, and it states that the project does not provide a comprehensive production deployment guide. It also notes that organizations may pay a vendor for deployment and maintenance. Treat the accounting configuration as a project deliverable with its own owner, not as a default setting that will be tidied up later. Confirm every accounting configuration option, including account types, mapping behavior and period handling, against the Fineract 1.15.0 documentation, and record which version your design relies on so that later upgrades can be checked against it.

Which Fineract settings and records make up the ledger design

A Fineract ledger design is not one setting but a set of linked elements: the general ledger, product mappings, generated journal entries, the accounting basis, the office or tenant scope, and the reports finance uses to reconcile. Each element needs a named owner in finance or operations, and a change to one can alter the balances of all the others.

General ledger account setup

This is the chart of accounts that Fineract posts into: asset, liability, income, expense and equity accounts with their codes and hierarchy. It controls where every balance lands, so finance must approve the account list and codes before any product is mapped to it. Confirm the exact account setup labels and required fields in the Fineract documentation for your release, and check that the structure matches the general ledger your finance team reports from.

Loan product accounting mappings

Each loan product is linked to ledger accounts for the principal, interest, fees, penalties and any provisioning or write-off treatment. These mappings decide where each repayment component is recorded, so a wrong link misstates income and receivables without any visible error in the loan itself. Finance and the credit product owner should sign off on each product's mapping together, and the mapping should be tested with sample repayments before launch.

Savings and deposit product mappings

Savings, fixed deposit and recurring deposit products map to ledger accounts for customer deposits, interest payable, interest expense, charges and withdrawals. Because deposits are liabilities owed to customers, errors here affect the institution's obligations as well as its income. Treasury or finance operations should approve these mappings, and the deposit product owner should confirm how interest posting and charges flow into each account.

Journal entries generated by transactions

Fineract creates journal entries automatically when loan and savings transactions occur, which makes these entries the audit trail that links a customer event to a ledger movement. Review them against the mapping design, since an entry that looks balanced can still post to the wrong account. Finance operations should own the review process, and the team should confirm which entry records can be reversed and how corrections are documented in the release they run.

Accounting basis choice

The choice between cash and accrual accounting determines when income and expense are recognized, and it changes how interest accrues across the ledger. This is a policy decision for the chief financial officer and the controller, not a configuration preference, and it must match the institution's reporting framework and regulatory filings. Decide it before the chart of accounts is finalized, because changing it later affects historical comparability.

Office and tenant scope

Offices and, where used, Fineract tenants define which entries belong to which business unit or institution. This scoping controls how balances are segregated and reported, so the structure must reflect legal entities and reporting lines rather than convenience. The finance lead and the platform owner should jointly approve it, and the team should confirm how tenant identifiers and office assignments are set in the documentation for their release.

Reconciliation reports

Reports that compare Fineract balances, journal entries and trial balances with the general ledger and subledger totals are the control that proves the design works. They should run at a set frequency and be retained as evidence for internal audit and external auditors. Finance must sign off on the reconciliation method and tolerance, and the team should confirm which report names and parameters exist in the documentation for their release before building the control.

Accounting decisions to settle before configuring the ledger

This table compares the main ledger design options for a Fineract deployment and the operational cost each one carries. Read each row as a decision to settle with finance and audit before product configuration starts, because most of these choices are costly to reverse once transactions post. Confirm each Fineract capability against the exact version in use before committing to a design.

Decision	Option	When it fits	Operational cost
Chart of accounts structure	Single flat chart	A small number of products and one reporting entity, with finance able to map balances without extra dimensions	Lower setup effort, but product-level and branch-level reporting usually needs manual analysis or external tooling
Chart of accounts structure	Structured by product family and branch	Several product families, multiple branches or cost centers, and management reporting by segment	More accounts to create, name and govern, and every new product or branch requires a change request and mapping review
Recognition basis for interest and fees	Cash basis	Income is recognized when received, and finance accepts that accrued but unpaid interest is not shown in the period	Simpler journals, but arrears and accrued income need separate tracking and can distort period results
Recognition basis for interest and fees	Accrual basis	Income is recognized as earned, which the finance function and auditors expect for most lending books	Requires accrual posting logic, periodic accrual reversal checks and reconciliation between accruals and cash receipts. Confirm which accounting bases the Fineract version in use supports
Posting timing	Posting at transaction time	Finance needs near real-time balances and each transaction should be traceable to its journal entry	Higher write load on the database, and corrections must be made through reversing entries rather than edits
Posting timing	Periodic summarized journals	Batch processing windows are acceptable and finance prefers a small number of consolidated journals per period	Less traceability at the individual transaction level, so reconciliation depends on the summary logic and its audit trail
Tenant scope of the chart	One shared chart across tenants	Institutions or brands share reporting structure and a single finance function	Changes affect all tenants, so testing and sign-off must cover every tenant that uses the chart
Tenant scope of the chart	Separate chart per tenant	Institutions have different regulators, reporting calendars or ownership	Each chart needs its own maintenance, review and reconciliation, which increases effort for upgrades and audits
Product ledger mapping	Each product mapped to its own income and receivable accounts	Products have different pricing, risk or reporting needs and finance wants product-level profitability	More accounts to reconcile and maintain, with mapping errors more likely as products multiply
Product ledger mapping	Shared income and receivable accounts	A small product set where simplicity matters more than product-level reporting	Product performance is harder to isolate, and any later split requires historical reclassification

How to build the Apache Fineract ledger in sequence

This sequence takes a Fineract general ledger from an agreed accounting basis to a documented account-to-product map that finance has tested and locked. Each step ends with a check that finance or the auditor can verify before the next step begins.

Confirm the accounting basis with finance and the auditor
Before any account is created, agree with the finance lead and the external auditor whether the ledger will follow cash or accrual recognition for interest, fees and charges, and how income is recognized over the life of a loan. Record the decisions, the reporting framework, and the period-end cut-off rules in a short written basis note. Fineract can post accounting automatically, but it cannot decide which treatment your institution is required to use. This step closes when finance and the auditor sign the basis note.
Draft the chart of accounts with codes and owners
Build the chart of accounts from the basis note, grouping assets, liabilities, equity, income and expenses, and give every account a code, a name, a normal balance and a named owner in finance. Include the control accounts that will hold sub-ledger totals for loans, savings, interest receivable, fee income and suspense. Confirm the coding scheme with the team that maintains the general ledger outside Fineract so codes match existing reporting. This step closes when finance approves the draft with an owner recorded against every account.
Map each product to the accounts it posts to
For every planned loan and savings product, list each event that creates a financial effect, such as disbursement, repayment, interest accrual or posting, fee, penalty, write-off and withdrawal, and name the debit and credit accounts each event should use. Record this as a product-to-account matrix that the product owner and finance both review, because the matrix is the source of every later journal entry. Flag any event that has no account, since Fineract will not post it correctly without one. This step closes when the matrix has no unmapped events and finance has initialled it.
Configure ledger accounts and product mappings in a test environment
In a non-production Fineract instance, create the general ledger accounts exactly as drafted, then configure each product's accounting mappings to point at those accounts. Use the matrix from the previous step as the only input, and do not create accounts ad hoc during configuration. Record the configuration version and who made each change so the build can be repeated. This step closes when a configuration export matches the approved matrix line for line, checked by a second person.
Run test transactions for each product event
Execute a scripted set of test transactions covering disbursement, repayment, interest accrual or posting, fee, write-off and reversal for each product, using test clients and accounts. For every transaction, open the journal entries Fineract generates and compare the debit and credit accounts and amounts against the expected entries written before the test. Keep a log of each test with its expected and actual result. This step closes when every scripted event produces the expected journal entries, with any mismatch fixed and retested.
Reconcile test sub-ledgers to the test general ledger
After the test transactions, compare the loan and savings sub-ledger balances in Fineract with the control account balances in the test general ledger, and confirm that interest receivable, fee income and suspense accounts agree to their expected values. Investigate every difference to its source journal entry rather than adjusting balances to force agreement. Ask finance to review a sample of journal entries against source transactions. This step closes when a trial balance ties to the sub-ledger totals with no unexplained differences.
Lock the chart and mappings under change control
Move the approved chart of accounts and product mappings into a change-controlled process, so any new account, changed mapping or new product event needs a written request, a test run and a finance approval before it reaches production. Assign who may change accounting configuration in the Fineract user roles, and separate that right from the people who create transactions. Confirm this approach with your internal audit or controls function. This step closes when the change procedure is approved and the production configuration matches the locked version.
Document the account-to-product map for finance
Produce a finance-facing document that lists every account code, its owner, each product mapping and the journal entries each event creates, with the test evidence attached. Keep it current with each approved change so finance can answer questions at period end without reading configuration screens. Store it with the basis note and the test log. This step closes when finance confirms the document matches the production configuration and accepts it as the reference for close.

How ledger design changes across single node, high availability and Kubernetes

On a single node, one Fineract instance handles configuration, postings and reporting. Chart of accounts changes and product-to-ledger mappings are applied in one place, so the team can sequence a change, test it and confirm postings before the next business day starts. The trade-off is that the same instance is also the outage boundary, so a mapping change applied during business hours carries more risk.

Sequencing: Apply account and mapping changes in a defined window when no transactions are being posted.
Single source: Configuration, postings and report queries all read from one database, so a reconciliation query reflects the same state users created.
Recovery: Confirm how the database is backed up and how a mapping error would be reversed before go-live.
Volume limits: Confirm with the vendor and your own tests how Close of Business performance behaves at your expected account volume.

Check whether the team can pause postings during a mapping change and who signs off the change before it is applied.

What drives the effort of designing and reconciling the ledger

This table lists the factors that change how much design, review and testing a Fineract general ledger needs, with the reason each one matters and how to limit it. Read it as a checklist for scoping: the largest effort usually sits in reviewing accounting mappings and testing accounting events, not in filling in configuration screens. Ask for a quote that states the product count, ledger account count and test cases covered.

Driver	Why it changes effort	How to keep it down
Loan and savings products and accounting variants	Each product, and each variant with different fee, interest or write-off treatment, needs its own mapping to ledger accounts and its own test cases.	Standardize product templates, limit variants to real business differences, and approve the product list before mapping starts.
Number of general ledger accounts	Every account needs a documented purpose, an owner and a mapping rule. More accounts mean more review rounds with finance and more reconciliation points.	Start from the institution's existing chart, retire unused accounts, and agree naming and numbering rules before setup.
Branches, offices and tenants or legal entities	Each office or legal entity may need its own ledger views, consolidation rules and inter-entity postings. Several tenants multiply the setup and test runs.	Confirm early whether separate tenants or one tenant with offices is required, and reuse one mapping design across entities where the rules allow.
Cash or accrual accounting choices	Accrual treatment of interest, fees and provisions adds journal entries, timing rules and period-end checks that cash-basis designs do not need.	Decide the accounting basis with the finance and audit teams before product design, and document it in one accounting policy.
Accounting events that must be tested	Each event type, such as disbursement, repayment, interest posting, reversal, write-off and close of business, needs expected journal entries and pass or fail evidence.	Build a test matrix from the product list, prioritize events by financial impact, and agree which events are covered before the quote is signed.
Integration with the existing general ledger or reporting tools	Journal exports, field mappings, cut-off timing and reconciliation reports must match what the existing ledger and reporting tools expect.	Define the interface contract early, agree the export format and frequency, and test one full period end to end.
Historical balances to reconcile during migration	Opening balances, open loans and savings, and accrued amounts must agree to the legacy ledger, often across several trial runs.	Agree the reconciliation tolerance and the cut-off date, and reconcile by product and account rather than only in total.
Finance and audit reviewers involved	Each reviewer adds sign-off rounds, questions and rework. Reviewers who join late often reopen approved mappings.	Name the approvers and their review windows at the start, and keep a single decision log for account and rule changes.

How to test that Fineract journal entries match finance's expectations

The most reliable way to show that Fineract journal entries match finance's expectations is to agree the expected answer before anyone runs a test. Build a test matrix that lists each product event (a loan disbursement, a repayment split into principal, interest and fees, a savings deposit, an interest posting, a withdrawal fee, a write-off) and, for each one, the debit and credit lines finance expects, including the GL accounts named in the chart of accounts and the product-to-ledger mappings. Finance should sign off that matrix as the specification. Without it, the team ends up judging whether the output looks reasonable, which is a weaker test and one that is hard to repeat after an upgrade.

Run the matrix in a non-production tenant that carries the same chart of accounts and mappings as the planned launch configuration. After each batch of test transactions, tie out the trial balance: total debits must equal total credits, and each GL account's movement must equal the sum of the expected lines from the matrix. Then test reversals and corrections separately. A reversed repayment or a corrected disbursement should leave the original entries visible, add offsetting entries, and leave balances where the matrix says they should be. Check the end-of-day and end-of-period accounting runs the same way, comparing the postings and closing balances to the expected results rather than only confirming that the job completed.

Test the failure paths deliberately, because they are where ledger errors usually hide. Remove a product mapping for a test product and confirm the posting fails visibly instead of defaulting to an unexpected account. Post to a closed GL account and confirm the rejection. Reverse a transaction and confirm that the reversal does not double count in the trial balance. Change a product configuration or accounting rule after postings exist, then confirm the system behavior matches your policy: whether historical entries stay as posted, and whether finance can explain any difference. Record what happened for each case, not only whether it passed. Confirm the exact behavior with DeployOpen's engineers and your own Fineract version before you rely on it.

The Close of Business Day batch needs its own test. The Fineract README notes that this Spring Batch job can run for several hours on deployments with millions of accounts. A test with a few hundred accounts will not show whether the accounting outputs remain correct and complete when the job runs long, when it is partitioned across workers, or when it overlaps with other processing. Ask for a test with volumes close to your expected account count, and check that the accounting totals for the business day are identical to the matrix-based expectations, with no gaps or duplicates at partition boundaries.

Document the results as a signed evidence pack that finance and internal audit can review. It should include the approved matrix, the configuration baseline and version, the trial balance tie-outs, reversal and failure test records, batch volume results, a sample of entries selected by finance with their source transactions, and any open defects with their owners. Finance signs the expected outcomes, the test lead signs the execution record, and internal audit receives the pack before go-live. This pack also becomes the baseline you repeat after each Fineract upgrade, so agree its format and retention period with your auditors at the start.

Access control and change control for the chart of accounts

These controls cover who can change the chart of accounts and product-to-ledger mappings, how those changes are approved, how finance tools reach the platform, and how each institution's ledger stays separate. Each control can be tested in a non-production environment and recorded as evidence before go-live.

Replace the default login first

Fineract's README documents a development login of mifos with the password password and states that it must be changed for any production deployment. Change it, and disable or remove any other default or test accounts, before anyone creates a GL account or a product mapping. Verify by attempting a sign-in with the old credentials and confirming it fails, then file the change record with the deployment evidence.

Limit who can change accounts and mappings

The people who maintain the chart of accounts and product-to-ledger mappings should hold a narrow set of permissions, separate from the permissions that staff posting daily transactions need. Map each staff role to the accounting permissions it requires, and remove broad administrator access from day-to-day users. Confirm the exact permission names in your release, then sign in as each role and attempt to create an account and change a mapping to check that the results match the role design.

Maker-checker approval for ledger changes

Changes to accounts, mappings and accounting rules should need a second person to review and approve them before they take effect. Confirm which approval steps your Fineract version supports for each of these entities, because coverage can differ between features. Where a step is not supported, document the manual review and the evidence it leaves. Test by submitting a change as one user and confirming that the same user cannot complete the approval.

HTTPS only for finance tool access

Reconciliation tools, reporting jobs and other finance systems that call the Fineract API send account and balance data across the network, so their connections should use HTTPS only. The project documents SSL settings through environment variables, including FINERACT_SERVER_SSL_ENABLED. Confirm that plain HTTP is refused at the entry point and in each client's configuration, and that each client validates server certificates instead of skipping validation.

Check tenant identifiers on every call

Fineract is multi-tenant: API requests carry a Fineract-Platform-TenantId header, and tenant connections are configured from a tenants database. A finance integration that omits the header, sends the wrong value or takes the value from user input could post entries to another institution's ledger. Confirm that each client sets the tenant identifier from its own configuration, then test against a separate test tenant to check that requests cannot read or write across tenants.

Audit trail for configuration and journal entries

Keep a record of who changed account setup, product mappings and accounting settings, and of every manual journal entry, including who entered it and who approved it. Confirm which events your version records by default, where those records are stored, and whether Fineract administrators can alter them. Test by making a sample configuration change and a sample manual journal entry, then checking that both appear in the trail with the correct user and timestamp.

What to monitor, document and re-check after the ledger goes live

The first thing operations should own after go-live is proof that the general ledger still agrees with the Fineract sub-ledgers. Run a daily reconciliation between the sub-ledger balances for loan portfolio, savings and deposit products and the matching general ledger accounts, and agree on who signs off each difference before the next business day opens. Store the output of every run. An unexplained variance on day one is far cheaper to trace than the same variance discovered at a quarter end, when the transactions that caused it are buried under weeks of activity.

Next, watch the posting path itself. Journal entries are created as a side effect of product transactions, so failed or rejected postings are the most direct sign that a product-to-account mapping is incomplete or wrong. Review the journal entry records and any error logs for each product type, not only the total volume. Pay attention to entries that land in a suspense or default account, because they indicate a mapping that was never completed. Confirm which Close of Business Day batch job runs each night, how long it took, and whether it finished on schedule. Batch timing is also an accounting control: if the job slips, accruals and end-of-day balances may be stale when finance pulls its numbers.

Treat every change to a chart of accounts entry, a GL account status, or a product-to-account mapping as a controlled event. Record who requested it, who approved it, the effective date and the reason, and check that the change is reflected in the next reconciliation. The documentation to hand over should be specific. Provide the chart of accounts with a named owner for each account, the product-to-account map, and the accounting basis decision (cash or accrual) with the name of the approver and the date it was made. Include the written reconciliation procedure, the escalation path for variances, and the change log. A new operations hire should be able to answer "where does this loan's interest income post and who approved that?" from these documents alone.

Each Fineract quarterly release needs a deliberate re-check before adoption. The project creates official releases at the end of each quarter, and a release can change configuration behavior even when the API surface looks the same. Read the release notes for anything touching accounting, products, batch jobs or database migrations, then run the accounting regression tests against a copy of production configuration. Those tests should cover at least one transaction of every product type, the resulting journal entries, the reconciliation outcome and the batch job run. Do not adopt a new release into production until those tests pass and the finance owner has reviewed the differences. Upgrade sequencing, Liquibase migrations and rollback planning are covered on the upgrades and support page, so this step focuses on what the ledger must still prove after the change.

Confirm, with your own team and the Fineract documentation for your release, which events, logs and reports you can export to support reconciliation. Where a capability such as an audit trail for configuration changes is not clearly documented for your version, ask the implementation team to demonstrate it in your environment rather than assuming it exists. Agree in advance who runs the daily reconciliation, who reviews the batch timing, and who owns the quarterly re-check, because a monitoring plan without named owners tends to lapse within a few cycles.

Questions teams ask before designing the Apache Fineract ledger

How long does it take to design a Fineract chart of accounts?

The duration depends on how many products, branches and reporting lines the institution needs, and on how quickly finance can agree on them. No standard duration applies, so ask for a timeline in the written scope rather than relying on a general figure. The main drivers are the number of product-to-ledger mappings, whether the institution needs one ledger or several per tenant, how many accounting events (disbursement, interest accrual, fee income, write-off) must post, and how many review rounds finance and audit require. Teams that already have a finance-approved account list usually move faster. The decisions and test cases described on this page show where most of that time goes.

Can our own team configure the Fineract chart of accounts without outside help?

Yes, a team with Fineract experience and a clear finance model can configure the chart of accounts and mappings internally, because these are set through the platform's configuration rather than custom code. The harder part is the design: deciding which GL accounts exist, how each loan and savings product posts, and how accruals and reversals behave. Most teams benefit from a second pair of eyes on those decisions and on the test plan, especially where the product set is large. Ask a partner to separate the design review from the build so your team keeps ownership of the final mapping.

What does the ledger design need from finance and audit?

Finance must own the account structure, the posting rules for each product event, and the reconciliation method between the core and the general ledger. Audit and compliance should review the control points early, including who can change mappings, how journal corrections are approved and how period-end is evidenced. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, so the institution's independent auditor makes the final assessment. Ask finance to supply a sample month of transactions, a current chart of accounts and the reconciliation reports they rely on, since these drive the design sessions.

Can we switch between cash and accrual accounting in Fineract later?

Switching basis after go-live is possible only with careful planning, because it changes when income and expense are recognized and therefore changes historical comparisons. The cost depends on how many products accrue interest or fees, how much history must be restated or bridged, and how the change is reported to regulators and management. Decide the basis before configuring products, record the reasoning in the design document, and test both basis outcomes on a copy of the data. Ask any partner to quote the switch as a separate scope item with its own reconciliation and testing steps, not as a configuration tweak.

How should we handle several institutions or brands in one Fineract ledger setup?

Fineract is multi-tenant: each API request carries a tenant identifier header, and tenant connections come from a tenants database. Each institution or brand can have its own chart of accounts and product set, but the design must confirm how accounts, reports and users are separated per tenant. Decide early whether tenants share any ledger structure or reporting consolidation, because that affects both design and testing. Operating limits, upgrades per tenant and data separation should also be reviewed before the mapping work starts. Ask for these points to appear explicitly in the fixed-scope quote.

What should a fixed-scope quote for ledger design include?

A fixed-scope quote should name the products and tenants covered, the accounts and mappings to be designed, the number of finance review rounds, the test scenarios, and the reconciliation reports to be delivered. It should also state who supplies the finance and audit inputs, what is excluded (for example, migration of historical balances or custom reports) and the acceptance criteria. Ask whether each item is one-time or recurring, such as later chart changes or regression testing after quarterly Fineract releases. DeployOpen does not publish a price list, and a quote follows from the written scope, so the clearer the scope, the more precise the quote.

How do we test journal entries before go-live?

Build a test pack that covers each product event, including disbursement, repayment, interest accrual, fee posting, reversal and write-off, and compare the journal output with finance's expected entries. Run the pack on each change to the chart of accounts and again after each Fineract upgrade, because a configuration change or new release can alter posting behavior. Reconcile the closing balances from the core against the general ledger for several test periods before cutover. The test cases and reconciliation steps on this page give the starting structure for that plan.

How DeployOpen scopes and hands over a Fineract ledger design

DeployOpen plans, implements and documents Apache Fineract chart of accounts and accounting rules inside the client's own infrastructure. The work starts from a written scope, builds the ledger mapping against agreed test cases, and ends with documentation finance and operations can run without us.

How we scope

Engagements are fixed-scope, with the ledger deliverables and timelines agreed in writing before work starts.
The written scope lists every product type to be mapped to a general ledger account, with its accrual or cash treatment.
Confirm with finance whether the chart of accounts is final before build, since later changes affect mapping and reconciliation.

How we build

We configure the chart of accounts and product-to-ledger mappings in Fineract, then test journal entries for each product event.
Each accounting rule is tested against worked examples agreed with finance, covering postings, reversals and end-of-day balances.
Reconciliation reports are built so finance can match Fineract totals to the general ledger in their own system.

How we hand over

Handover includes the chart of accounts, product mapping tables, rule definitions and the test cases used to verify them.
Documentation records which configuration is set through the API or database, so future changes can be reviewed and repeated.
Finance and operations staff are walked through reconciliation steps and the process for requesting a new ledger account.

How we support

Ongoing support, upgrades and regression testing of accounting rules are available as a retainer after go-live.
Before each Fineract upgrade, we re-run the ledger test cases against the new release in a non-production environment.
Confirm with DeployOpen what the retainer covers for accounting changes, response handling and quarterly release reviews.