Two reports, two answers
Revenue in the dashboard and revenue in the ledger differ, usually because one includes draft documents, or cancelled invoices, or a different date basis. Once that happens twice, people stop opening the dashboard.
One version of the number, in the tool your board already uses. ERPNext reports well enough for the people who work in it. The trouble starts when a director wants a view across three years, or finance wants to blend ERP data with a budget that lives elsewhere. That is a genuine job for a BI tool — provided the dashboard and the ledger cannot drift apart.
The connection is read-only by design. Nothing in this setup writes back to ERPNext.
Either through a read-only database replica, which suits large volumes and complex models, or through the ERPNext REST API, which suits smaller datasets and cloud hosting. Either way a modelled semantic layer sits in between, so measures are defined once and every report draws the same definition of revenue, margin and stock value.
A dashboard nobody believes is worse than no dashboard, because meetings then argue about the number instead of the business.
Revenue in the dashboard and revenue in the ledger differ, usually because one includes draft documents, or cancelled invoices, or a different date basis. Once that happens twice, people stop opening the dashboard.
A refresh runs an expensive query against production and the system slows for everyone. The usual response is to refresh less often, which makes the dashboard stale, which makes people trust it less.
A salesperson who cannot see another territory in ERPNext opens a dashboard and sees the whole country, including margins. Permissions that exist in the ERP have not been carried into the reporting layer at all.
Each report author writes their own version of gross margin. There is no shared definition, so two dashboards built from identical data show different figures and both authors are convinced they are right.
The deliverable is a trustworthy data layer. The dashboards on top of it are then yours to build and change without calling us.
Either a read-only database replica or the REST API, chosen on your data volume, hosting and refresh needs, so reporting load never lands on the instance your users work in.
Replica suits large on-premise or self-hosted datasets. API suits smaller volumes and managed hosting where a replica is not available.
Revenue, gross margin, stock value, receivable ageing and the rest are defined once as measures, with document status and date basis explicit in the definition.
This is the single change that stops dashboards disagreeing with the ledger. Draft, submitted and cancelled are decided in the model, not per report.
Only changed data is pulled on each refresh rather than reloading history, so refreshes are quick enough to run several times a day.
Frequency is what makes a dashboard operational rather than a monthly artefact, and incremental refresh is what makes frequency affordable.
Territory, company and cost centre restrictions from ERPNext are reproduced as row-level security, so a user sees the same scope of data in Power BI as they do in the ERP.
Skipping this is how confidential margin data reaches people who were never permitted to see it in the source system.
A control report compares headline figures in Power BI against the equivalent ERPNext report for the same period, so drift is caught by the system rather than in a board meeting.
Cheap to build, and it is what keeps the dashboard trusted in its second year.
Every measure carries an explicit definition. Ambiguity here is what produces two answers to one question.
| ERPNext source | Power BI model | Direction | Notes |
|---|---|---|---|
| Sales Invoice | Revenue fact table | ERPNext → Power BI | Submitted only; cancelled excluded explicitly |
| Sales Invoice Item | Line-level revenue & margin | ERPNext → Power BI | Margin uses valuation rate, not standard cost |
| Purchase Invoice | Spend fact table | ERPNext → Power BI | Supplier and expense analysis |
| Stock Ledger Entry | Inventory movement & valuation | ERPNext → Power BI | The largest table; incremental refresh matters here |
| GL Entry | Financial statements | ERPNext → Power BI | Reconciled against the ERPNext trial balance |
| Customer / Supplier / Item | Dimension tables | ERPNext → Power BI | Slowly changing where history matters |
| Territory / Company / Cost Center | Security dimensions | ERPNext → Power BI | Drive row-level security rules |
| Work Order & Job Card | Production performance | ERPNext → Power BI | Where manufacturing reporting is in scope |
| Nothing | Write-back to ERPNext | Never | The connection is strictly read-only |
Questions before data. A model built without knowing what will be asked of it ends up modelling everything and answering nothing.
The dozen or so questions this has to answer, and who asks them. That determines the model, and it prevents the common outcome of a comprehensive warehouse nobody queries.
Read replica or REST API, decided on data volume, hosting arrangement and refresh frequency. Neither is universally right and the trade-offs are explained rather than assumed.
Fact and dimension tables with measures defined once, including the treatment of draft, submitted and cancelled documents and the date basis for each measure.
ERPNext territory, company and cost centre restrictions are reproduced as row-level security and tested by signing in as a restricted user rather than by inspecting configuration.
Headline figures are tied to the equivalent ERPNext reports, the control report is scheduled, and your team is trained on the model so they can build their own dashboards.
Timeline shown is indicative for a finance and sales model. Manufacturing or project reporting adds scope to the modelling stage.
Worth reading, because BI projects attract more optimism per rupee than almost anything else.
The same modelling approach applies to Metabase, Superset or ERPNext Insights if you would rather not add a licence cost. The connection method is the only real difference.
A read-only replica suits large datasets and complex models, and keeps reporting load away from the instance your users work in. The REST API suits smaller volumes and managed hosting where a replica is not available. Data volume and hosting arrangement usually decide it rather than preference.
Not if it is set up properly. Queries run against a replica rather than the production database, and incremental refresh pulls only changed rows. Pointing Power BI straight at a live production database is how BI projects earn a reputation for slowing the ERP.
Yes, and it should be treated as mandatory rather than optional. Territory, company and cost centre restrictions from ERPNext are reproduced as row-level security, and tested by signing in as a restricted user rather than by reviewing the configuration.
Almost always document status or date basis — draft invoices included, cancelled ones not excluded, or posting date versus delivery date. Defining that once in the semantic layer, and running a control report against ERPNext, is what stops it recurring.
As current as the refresh schedule, typically several times a day with incremental refresh. It is not real time, and it should not be relied on as such. Anything needing a live figure is read in ERPNext, where it is authoritative.
No. Metabase, Superset and ERPNext Insights connect on the same principles and avoid a licence cost. Power BI is common where an organisation already standardises on it and finance teams are comfortable in it, which is a perfectly good reason to choose it.
A short call about the questions your management actually asks and whether anyone currently trusts the answers.
Power BI and Microsoft are trademarks of Microsoft Corporation. Metabase and Apache Superset are trademarks of their respective owners. ERPNext and Frappe are trademarks of Frappe Technologies Pvt. Ltd. These names are used here only to identify the software described. Finstein is not affiliated with or endorsed by Microsoft Corporation, and Power BI licences are contracted directly in your own name.