<link href="https://fonts.googleapis.com/css2?family=Caveat:wght@400..700&family=Google+Sans+Flex:opsz,wght@6..144,1..1000&display=swap" rel="stylesheet">
Microsoft Power BI

Connect ERPNext to Power BI

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.

How do you connect Power BI 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.

Why BI projects end up distrusted

A dashboard nobody believes is worse than no dashboard, because meetings then argue about the number instead of the business.

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.

The report queries the live database

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.

Everyone sees everything

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.

Measures are redefined in every report

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.

What we set up

The deliverable is a trustworthy data layer. The dashboards on top of it are then yours to build and change without calling us.

A connection that does not touch production

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.

What that means in practice

Replica suits large on-premise or self-hosted datasets. API suits smaller volumes and managed hosting where a replica is not available.

A modelled semantic layer

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.

What that means in practice

This is the single change that stops dashboards disagreeing with the ledger. Draft, submitted and cancelled are decided in the model, not per report.

Incremental refresh

Only changed data is pulled on each refresh rather than reloading history, so refreshes are quick enough to run several times a day.

What that means in practice

Frequency is what makes a dashboard operational rather than a monthly artefact, and incremental refresh is what makes frequency affordable.

Row-level security mirroring ERPNext

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.

What that means in practice

Skipping this is how confidential margin data reaches people who were never permitted to see it in the source system.

A reconciliation report

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.

What that means in practice

Cheap to build, and it is what keeps the dashboard trusted in its second year.

What gets modelled, and how it is defined

Every measure carries an explicit definition. Ambiguity here is what produces two answers to one question.

ERPNext sourcePower BI modelDirectionNotes
Sales InvoiceRevenue fact tableERPNext → Power BISubmitted only; cancelled excluded explicitly
Sales Invoice ItemLine-level revenue & marginERPNext → Power BIMargin uses valuation rate, not standard cost
Purchase InvoiceSpend fact tableERPNext → Power BISupplier and expense analysis
Stock Ledger EntryInventory movement & valuationERPNext → Power BIThe largest table; incremental refresh matters here
GL EntryFinancial statementsERPNext → Power BIReconciled against the ERPNext trial balance
Customer / Supplier / ItemDimension tablesERPNext → Power BISlowly changing where history matters
Territory / Company / Cost CenterSecurity dimensionsERPNext → Power BIDrive row-level security rules
Work Order & Job CardProduction performanceERPNext → Power BIWhere manufacturing reporting is in scope
NothingWrite-back to ERPNextNeverThe connection is strictly read-only

How it goes in

Questions before data. A model built without knowing what will be asked of it ends up modelling everything and answering nothing.

  1. 1

    Agree the questions

    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.

  2. 2

    Choose the connection method

    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.

  3. 3

    Build the semantic layer

    Fact and dimension tables with measures defined once, including the treatment of draft, submitted and cancelled documents and the date basis for each measure.

  4. 4

    Mirror the permissions

    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.

  5. 5

    Reconcile and hand over

    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.

What this does not do

Worth reading, because BI projects attract more optimism per rupee than almost anything else.

  • It does not write back to ERPNext. The connection is read-only, deliberately, and planning writes into the ERP through a dashboard is not something we will build.
  • It does not include Power BI licences. Those are contracted with Microsoft in your own name and are a recurring cost separate from this work.
  • It does not replace ERPNext reporting. Operational reports belong in the ERP where the user can act on them; BI is for cross-period, cross-source analysis.
  • It does not give real-time figures. Even frequent incremental refresh means the dashboard is minutes or hours behind. Anything needing live numbers should be read in ERPNext.
  • It does not fix the underlying data. A dashboard built on an unreconciled ledger presents wrong numbers faster and more attractively than a spreadsheet did.

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.

ERPNext & Power BI —common questions

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.

Next step

Talk to us about reporting on ERPNext data

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.

ERPNext CalculatorContact Us