Apache Fineract reporting and Pentaho reports: when a team needs them
Teams running or planning a self-hosted Apache Fineract instance that needs operational and regulatory reports will generate them from the legacy API report types: Table, Pentaho and Chart. The Pentaho route depends on the Mifos reporting plugin, which the project describes as compatible with the Fineract backend. Implement this module when your credit, operations, finance or compliance staff need recurring, parameterized views of portfolio, savings, collections or accounting data that the standard screens and API responses do not give them, and when someone must own the report definitions, their parameters and who may run them. The legacy documentation lists parameters such as date ranges, office, loan officer, currency and fund, so decide early which of these your reporters need and which users may see which offices.
Reports are not a substitute for the general ledger, for the Close of Business processing that updates balances, or for a data warehouse and BI layer if your analysts need free-form exploration across systems. Those needs usually belong to the accounting, batch and integration design, and to tools such as the analytics platforms covered elsewhere in this group. Treat report generation as a read path that adds load to your database, and plan it with the same read replica and batch scheduling decisions you make for the rest of the platform. Confirm with the project documentation which report features your target release supports, because the report types, plugin versions and parameter lists are the details most likely to change between releases.
Before you build anything, confirm that your target release includes the fixes for CVE-2026-35152, an SQL injection in the runreports endpoint that affected 1.14.0 and earlier and was fixed in 1.15.0. Report endpoints accept user-influenced input, so the access model for who may run which report is a security decision, not only a reporting one. Ask the Apache Fineract security reports page for current advisories before go-live, and record which release, plugin version and report definitions you validated so that later upgrades can be tested against the same list.
What Fineract reporting can do according to its documentation
The Fineract legacy API documentation describes three report types and a set of filter parameters that together cover most operational and portfolio questions. The cards below separate what the docs describe from what your release actually exposes, because report endpoints, plugins and mailing jobs each need their own checks before you rely on them.
Table reports
Table reports are the simplest report type in the legacy API, returning tabular output for a report definition you select and parameterize. They suit operational lists such as client, loan or savings extracts that finance and operations teams pull on a regular basis. Confirm which table reports ship with your release, who may run each one, and whether output can be exported in the formats your team needs.
Pentaho reports
Pentaho report types depend on a report engine and a report definition that the Mifos X Reporting Plugin supports with Apache Fineract. Plan for the plugin, the Pentaho runtime and the report templates as separate components with their own versions and change control. Confirm compatibility with your Fineract release before you commit to a report catalog.
Chart reports
Chart reports are the third type listed in the legacy API documentation and produce graphical output from the same report parameters. They are useful for management dashboards on portfolio trends, but they inherit the data scope of the underlying query. Ask who defines each chart, how often the data refreshes, and whether a chart can show data a user is not permitted to see in a table.
Date, office and officer filters
The legacy API accepts parameters such as date ranges, office, loan officer, currency and fund. These filters decide what a report can reveal, so they are the first place to check for over-broad access. Define which parameters each role may set, test edge cases such as multi-currency offices and closed periods, and document the expected totals before users rely on the numbers.
Mifos X Reporting Plugin license
The Mifos X Reporting Plugin is described as compatible with the Apache Fineract backend and is licensed under MPL-2.0, which carries file-level copyleft obligations. Legal and procurement teams should review the license terms alongside the Apache License 2.0 of Fineract itself. Confirm the plugin version you will deploy, track its maintenance status, and record the source of each change you make to it.
Runreports endpoint and patch level
The runreports endpoint is the route through which report requests execute, and CVE-2026-35152 was an SQL injection flaw in it affecting 1.14.0 and earlier, fixed in 1.15.0. Confirm your deployed version, restrict who can call the endpoint, and review how report parameters are validated before they reach the database. Treat any custom report definition as code that needs the same review as an API change.
Choosing between table, chart and Pentaho reports
This table compares the three Fineract report types and the three places report logic can live: Fineract report definitions, the Mifos reporting plugin for Pentaho, and an external analytics tool reading the database. Read each row against your access model, your team's skills and who must be able to change a report. The main takeaway is that the more logic you place outside Fineract, the more you own its security, access and upgrade path.
| Option | Strengths | Access and skills | When it fits |
|---|---|---|---|
| Table reports in Fineract | Defined and run through the reports API, with parameters such as date range, office, loan officer, currency and fund | Runs under Fineract's own authentication and tenant context; needs API and SQL-aware staff to write definitions | Routine operational lists that finance or branch teams run from existing workflows |
| Chart reports in Fineract | Returns chart-style output from the same report definition model as table reports | Same API access model as table reports; confirm chart rendering options in your version | Simple trend or distribution views where the built-in output is enough |
| Pentaho reports via the Mifos plugin | Richer layout and formatting for printed or formal reports, using the Pentaho report designer | Requires the Mifos X Reporting Plugin (MPL-2.0) and Pentaho report design skills; confirm plugin compatibility with your Fineract version | Formal statements or regulator-style layouts that business users need to format precisely |
| External analytics tool reading the database | Full freedom in queries, visualization and sharing, independent of Fineract's report release cycle | Needs direct database access, a read-only role and data governance; bypasses Fineract API controls unless you design them in | Cross-system analysis, large exploratory work and dashboards for analysts, once database access is approved and scoped |
| Access control in Fineract reports | Report access follows the API user and permissions you configure | Requires review of who can run which report and with which parameters | Any deployment where report output contains client or loan data |
| Upgrade and maintenance effort | Definitions stay inside Fineract and are tested with the platform | Plugin and Pentaho designs need retesting after Fineract upgrades; external queries depend on schema stability | Choose the option whose upkeep your team can sustain across releases |
| Security exposure | Reduced surface when reports run through the API and parameters are controlled | Report SQL and parameters must be validated; the 1.15.0 fix for CVE-2026-35152 in the runreports endpoint applies to this option | Confirm you run 1.15.0 or later before exposing any report endpoint |
How a reporting build proceeds from inventory to handover
This sequence turns a list of reporting needs into tested Fineract reports, scheduled delivery and secured endpoints, with the definitions and access records handed to the team that will run them. Each step ends with a named output so gaps surface before go-live.
Inventory the reports people actually need
Gather the reporting requirements from regulators, external auditors, finance, credit and branch managers, and list each report with its audience, purpose, frequency and the data it must contain. Ask each owner which figures they reconcile against and which decisions depend on them. The output is a signed-off inventory that records the owner of every report, so no report is built without someone who will check it.
Map each report to a type and parameters
For each inventory line, decide whether the Fineract legacy API report type fits: Table, Pentaho or Chart, as listed in the legacy API documentation. Then define the parameters the report needs, such as date ranges, office, loan officer, currency and fund, and note which ones users must supply at run time. The output is a mapping sheet that shows, for every report, its type, parameters and any figure that cannot be produced from Fineract data alone.
Confirm plugin and Fineract version compatibility
Check that the Mifos X Reporting Plugin version you intend to use is compatible with the Fineract release running in your non-production environment, and record both versions in the change log. The plugin is licensed under MPL-2.0, so have legal confirm that its terms fit your distribution model. The output is a compatibility record that names the exact plugin and Fineract versions, plus the reason each was chosen.
Build and test reports on a non-production tenant
Create the report definitions in a non-production tenant that holds data representative of production, identified by the Fineract-Platform-TenantId header used in your environment. Run each report with boundary parameters, such as empty date ranges, closed offices and multi-currency accounts, and reconcile totals against the general ledger and the owner's known figures. The output is a test log where each report has a recorded expected result and a sign-off from its owner.
Configure scheduled report mailing
Set up the scheduled mailing jobs for the reports that need regular delivery, choosing recipients, formats and run times with the report owners. Run each job once in the non-production tenant and confirm that recipients receive the expected file, that failures are logged, and that the mailing list excludes people who should not see the data. The output is a job register listing each schedule, recipient group and the test result that proved delivery works.
Lock down report endpoints and apply the 1.15.0 fix
Confirm the production Fineract version is 1.15.0 or later, since CVE-2026-35152, an SQL injection in the runreports endpoint affecting 1.14.0 and earlier, was fixed in 1.15.0. Restrict which roles can run each report, require HTTPS, and review who can change report definitions. Retest the runreports endpoint with the security team before go-live. The output is a signed access matrix and a test record showing the patched version and restricted roles are in place.
Hand over definitions, runbooks and access records
Deliver the report definitions, parameter mappings, test logs, job register and access matrix to the operations and reporting team, together with a runbook for running reports, handling failed mail jobs and upgrading the plugin or Fineract. Walk the team through one full run and one recovery scenario. The output is an accepted handover package, with named owners for each report and a record of who holds the administrative access.
Securing report endpoints after the CVE-2026-35152 fix
Upgrade to Apache Fineract 1.15.0 or later before anything else. CVE-2026-35152 was an SQL injection in the runreports endpoint that affected 1.14.0 and earlier, and the fix shipped in 1.15.0. Any deployment still on 1.14.0 or earlier is exposed on that endpoint regardless of how reports are used internally. Confirm the running version in each environment, including test and reporting copies, because a stale staging instance can be reached from the same network as production. Treat the upgrade as a change with its own test cycle: run your report catalogue against the new version, confirm that Table, Pentaho and Chart reports still return the same results, and record the outcome as evidence for your change record.
After the upgrade, review who can call report endpoints. Reports reach across loan, savings and client data, so access should be granted by role and tied to the reporting purpose, not to a general-purpose administrator account. Check which users, service accounts and integrations hold permissions for running reports, and remove the development login described in the Fineract README if any environment still uses it. Where report requests pass through a gateway or proxy, confirm that the route for report execution is restricted to the callers who need it and that the TLS settings documented for the server are enforced. Ask your implementation partner or the project for a written list of the report-related permissions in the version you run, because permission names change between releases.
Restrict report parameters and log every execution. Date ranges, office, loan officer, currency and fund are the parameters the legacy API documents, and each is an input an attacker or a careless user can manipulate. Validate parameter types and allowed values at the boundary you control, and make sure the Mifos X Reporting Plugin and any Pentaho report definitions do not concatenate free-text input into queries. Enable logging for report runs, capturing user, report name, parameters and time, and forward those logs to your monitoring system. Finally, do not assume the runreports fix covers every reporting path. Read the Apache Fineract security reports page for the current advisories, and ask the project security contacts in writing whether any other reporting route needs review for your version.
What drives reporting effort and how to keep it down
Reporting effort on Fineract grows with the number of reports, the roles that read them and the checks each figure must pass. The cards below cover the drivers that matter most and the design choices that keep each one contained.
Number of reports and parameters
Every report adds a definition, a parameter set, test data and a user-facing description to maintain. Each distinct date range, office, loan officer, currency or fund filter multiplies the combinations that someone must check. Start with a short list of reports that answer real operating and regulatory questions, and reuse the same parameter names and formats across them so a user who learns one report can run the next. Ask whether each new report replaces an existing one before adding it.
Pentaho template complexity
A Pentaho template with nested subreports, many calculated fields and hard-coded SQL is slow to change and hard to review. Each join or calculation that depends on Fineract table structure also has to be re-tested after a schema change. Keep templates to one purpose, move shared logic into a small number of reusable subreports or views, and avoid embedding business rules that a reviewer cannot trace back to a ledger definition. Record which Fineract tables each template reads so an upgrade review can find affected reports quickly.
Roles that need different data
Branch staff, loan officers, finance, risk and external reviewers usually need different slices of the same data. If each role gets a bespoke report, the number of artifacts grows with the number of roles rather than with the number of questions. Map each role to a fixed set of reports and parameter defaults, then confirm in your own environment that the Fineract permissions for each user group return only the rows that role should see. Treat permission changes as a reporting change and review them the same way.
Validation against source ledgers
A report that runs without errors can still be wrong, for example when a filter excludes reversed transactions or a currency is summed without conversion. Each finance-facing report needs a reconciliation step that ties its totals to the general ledger, the loan and savings balances, or a previously approved report for the same period. Agree the tolerance and the owner of each check before go-live. Repeat the reconciliation whenever a template or parameter changes, not only at first release.
Mailing schedules and recipients
Scheduled report mails create ongoing work: each schedule has a timing rule, a recipient list, an output format and an owner who must know when it stops being useful. Recipient lists go stale as staff move, and a mail that sends a sensitive report to the wrong address is a data incident. Keep the schedule register short, tie each schedule to a named business owner, and review recipients on a fixed cadence. Confirm in the Fineract documentation how mailing jobs authenticate and where their output is stored before you set up any schedule.
Upgrade regression testing
Each Fineract release can change API behavior, database structure or the reports interface, and the Mifos reporting plugin must be checked against the release in use. Without a fixed regression set, the first sign of a broken report is usually a user complaint at month end. Keep a baseline set of reports with known inputs and expected outputs, run it in a non-production environment after every upgrade, and include the security checks for report endpoints. Plan this work into the upgrade calendar rather than treating it as optional.
How reporting connects to the rest of the Fineract platform
How do report callers authenticate to Fineract endpoints?
Report callers authenticate with the same mechanisms as other Fineract API clients: OAuth2 or HTTP basic authentication, as shown in the README. The default development login of mifos with its default password must be replaced before any real deployment, and each caller should use a dedicated service account with only the report permissions it needs. Serve every request over HTTPS only, configuring SSL through settings such as FINERACT_SERVER_SSL_ENABLED. Send the Fineract-Platform-TenantId header on every call so reports run in the intended tenant. Confirm with your own security team how service credentials are issued, rotated and stored, because report endpoints can return large volumes of client and loan data.
Can reporting read from a PostgreSQL read replica?
The Fineract documentation recommends one write instance, one batch instance and multiple read instances on database read replicas for high load, so read-heavy reporting is designed to sit on the read side. Before you point any external query or report at a replica, confirm which Fineract report types execute on read instances and which need the write database, and test this on your release. Direct SQL access to a replica is a separate decision from the API: it bypasses Fineract's permission model, so it needs a read-only database role, a documented schema list and a change process for schema changes between releases.
How does the Mifos web front end give users access to reports?
Fineract is headless and provides no user interface of its own. The README points to the Mifos X web application as the front end used in its Kubernetes example, and that application calls the same REST APIs that the reports API uses. Check which report screens your chosen front end exposes, which report types it can run, and whether it passes parameters such as office, loan officer, currency and fund in the form your users need. If you add the Mifos reporting plugin for Pentaho reports, confirm its version pairing with your Fineract release and your front end before the plugin is part of the production build.
What do monitoring and audit logs need to cover for reports?
Monitoring should record who ran which report, with which parameters, against which tenant, and when it finished or failed. Fineract's own logs and the proxy or gateway in front of it are the first sources to check, so confirm exactly which fields each one records before you rely on them for an audit trail. Forward these logs to your central log platform, set alerts on repeated failed authentication and on unusual report volume, and keep retention aligned with your records policy. Test the trail by running a known report and confirming that the entry can be found and tied to a named service account.
Can Apache Superset or Metabase read Fineract data safely?
External analytics tools such as Apache Superset or Metabase can read Fineract data, but the safe pattern is a governed reporting database or read replica that the analytics tool reaches through a read-only role, not the transactional write database. Fineract's data model is an internal detail of the application, so each dashboard should depend on a documented set of views or extracts that your team owns and tests after every upgrade. Decide who approves new datasets, how row-level access by office or tenant is enforced, and how long extracts are kept. Confirm the schema stability commitments for your Fineract release with the project documentation before building long-lived dashboards.
How should reporting load be planned against the read instances?
Plan reporting load against the read instance model: the documentation describes write, batch and read instance types set through environment variables, with read instances serving query traffic. Keep scheduled reports and mailing jobs off the write instance where possible, and place heavy report runs on read replicas sized for the largest expected report. Schedule large runs away from the Close of Business Day job, because the README notes that this job can run for several hours on deployments with millions of accounts. Measure report duration and replica lag during a realistic test, then set limits on concurrent report runs so one user cannot starve the rest.
What drives the cost of building reporting on Fineract?
Cost comes from the people and infrastructure that make reports reliable: a platform engineer to configure report definitions and parameters, a database engineer to set up the replica and a read-only role, a security review of report endpoints and credentials, and the work to keep the Mifos reporting plugin and any analytics tool compatible across upgrades. Some of this is one-time, such as building the first report set and the access model, and some recurs, such as patching, plugin updates and testing after each Fineract release. Ask any partner for a quote that lists each report type, each data source, the access model, the scheduled jobs, and the upgrade tests, so the scope can be compared directly with your in-house estimate.
How do reports stay inside one tenant in a multi-tenant deployment?
Fineract is multi-tenant: each API request carries a Fineract-Platform-TenantId header, and tenant database connections come from a tenants database. Reports should therefore be tested for tenant isolation before go-live, by running the same report definition as users from two tenants and confirming that no rows cross the boundary. Make sure your gateway or front end always sets the tenant header and does not let callers choose an arbitrary value. For external analytics, the tenant boundary must be enforced in the database or the dataset, not only in the dashboard, and you should confirm how your release handles tenant-scoped reporting tables.
Official sources for Fineract reporting
Start with the Apache Fineract legacy API documentation before you design any report, because it is the only source in this set that lists the report types the platform accepts: Table, Pentaho and Chart. It also documents the parameters a report can take, such as date ranges, office, loan officer, currency and fund. Read the entry for the runreports endpoint against the exact release you run, and confirm which parameters each report type expects in your environment. Use the Apache Fineract API legacy documentation as the reference for request shape, and keep a copy of the version you tested against so your report definitions can be reviewed later.
The openMF reporting plugin repository is the source to check if you plan to build Pentaho reports. The project describes the plugin as compatible with the Apache Fineract backend and licenses it under MPL-2.0, which your legal team should review alongside your other open-source licenses. Confirm the plugin version you intend to use against the Fineract release in your environment, read its installation notes and open issues, and record who will maintain the plugin after launch. The repository is the place to verify compatibility, not an assumption you carry into the design.
The Apache Fineract security reports page should be checked before any reporting endpoint goes live. It records CVE-2026-35152, an SQL injection flaw in the runreports endpoint that affected 1.14.0 and earlier and was fixed in 1.15.0. Treat that entry as the trigger for two actions: confirm your build is at 1.15.0 or later, and add a recurring check of the page to your patching routine so that future advisories reach the team responsible for report access. Ask the project or your implementation partner to confirm whether any other report-related advisories apply to your version.
How DeployOpen scopes and delivers Fineract reporting
DeployOpen plans, builds, documents and supports Apache Fineract reporting inside infrastructure you control, from the first report definition to the scheduled jobs that deliver it. Each engagement starts with a written scope that names the report types, data sources, access rules and hand-over items before any build work begins.
How we scope
- We list every report, its type (table, Pentaho or chart) and the parameters users need, such as date range, office and currency.
- We confirm which Fineract version and database platform the reports run against, including whether the 1.15.0 SQL injection fixes are in place.
- We record who may run, view and schedule each report, and which report endpoints are exposed beyond your internal network.
How we build
- We configure table and chart reports through the reports API and build Pentaho reports with the Mifos reporting plugin where your layouts need it.
- We test report output against known ledger and portfolio figures, and review every report query for injection and parameter handling risk.
- We set up scheduled report mailing jobs with recipient lists, delivery testing and failure alerts agreed with your operations team.
How we hand over
- You receive report definitions, parameter references, access rules and the scheduled job configuration, documented for your own team.
- We provide a verification record showing which reports were tested, against which data, and the results of each test run.
- We walk your administrators through adding, changing and retiring reports so new requests follow the same review path.
How we support
- Ongoing support, upgrades and continuous security testing of report endpoints are available as a retainer.
- We plan report regression tests around each Fineract release so upgrades do not silently change figures in your management reports.
- Support covers the reporting layer only, and any change to ledger mapping or core product setup is scoped separately in writing.
