Do Your Qlik Apps and Power BI Reports Show Different Numbers?
Neither Qlik nor Power BI is wrong. Each has its own load logic, its own definitions and its own lineage, so the same metric is calculated twice and nobody can reconcile them. The rules belong in one governed warehouse model both tools read.
The data warehouse automation platform trusted by data teams across industries
Does this sound familiar?
- The Qlik app and the Power BI report show different revenue for the same month.
- Each team trusts its own tool, and both can explain how their number was built.
- Reconciling the two means reading a load script and Power Query side by side.
- Management asks which number is right, and the honest answer is that both are.
When two BI tools disagree, it is tempting to blame one of them. Usually both calculated exactly what they were told. They were just told different things.
Why the numbers diverge
- Each tool has its own logic. Qlik applies it in the load script, Power BI in Power Query and DAX.
- Definitions were written twice. Returns, cancellations and currency are handled separately in each, by different people.
- Timing differs. A reload and a refresh run at different times against different extracts.
- Lineage stops at the tool. Neither side can show the other where its number came from.
Aligning the two by hand fixes this month. The next rule change drifts them apart again.
Why it lands on you
- You are asked to explain a gap created by decisions made in another team’s tool.
- Reconciliation is invisible work, noticed only when the numbers do not match.
- You can document your Qlik logic. You cannot make the Power BI model follow it.
The work is in the wrong place
- Defining a metric is warehouse work. Done in each BI tool, it produces one answer per tool.
- It belongs in one central place: a data warehouse or data hub, built once and read by every app.
- If that sounds expensive, the estimate probably assumes hand built pipelines. A specialised automation platform generates them from a model, which changes both the cost and the time it takes.
What changes when the model arrives finished
Datavault Builder holds the business rules in the warehouse and generates the dimensional layer natively in the database you already have, from Fabric and SQL Server to Snowflake or BigQuery.
- The metric is calculated once, and Qlik and Power BI read the same figure.
- Both tools load finished tables, so neither script nor model carries its own definition.
- The rule is visible and versioned, rather than split across a
.qvfand a.pbix. - Lineage shows the derivation, so a question is settled by opening the graph.
- Choosing a BI tool becomes a matter of preference, not of which number you want.
What to ask for
Not “Power BI is wrong”, but:
“Qlik and Power BI calculate revenue with separate logic, so they disagree and we cannot trace why. Can the definition live once in the warehouse, so both tools read the same governed dimensional view?”
That moves the discussion from which tool is right to where the definition belongs.
See It Working on Your Own Data
Book a free demo and bring the report that gives you the most trouble.
Three Steps to Numbers That Add Up
-
Extract the existing logic
Collect the calculations, joins and filters that live in your reports today.
-
Centralize it in one place
The logic moves into the warehouse model once, so every report reads the same definition.
-
Enjoy numbers that add up
Every report shows the same figure, and “where did this number come from” has a visible answer.
How Datavault Builder Hands Your Report a Finished Model
-
The model arrives finished
Datavault Builder generates the vault and the star schema to run natively in the database you already have: SQL Server, Azure SQL, Synapse, Fabric, Snowflake, Databricks or BigQuery.
-
The work leaves the report
No merge, no parsing, no fuzzy match. That work is gone from the report.
-
Sources arrive integrated
Customers from the ERP, the CRM and the web shop are matched into one set of conformed dimensions. The join happens once in the warehouse, not again in every report.
-
History you can query
Every change is retained as it arrives, so you can report as-was as well as as-is, even where the source system overwrites its own records.
-
Every number has lineage
The logic gains lineage, so “where did this number come from” has a visible answer.
-
Changes handled upstream
Slowly changing dimensions are handled upstream as vault satellites, not approximated.
Recognized by BARC in The Data Fabric Survey 26
Meet Our Expert
Twenty minutes with our Sales Director, and an honest answer on whether this fits your situation.
Matt Collett
Sales Director
Great, pick a time that works for you:
Other Problems This Series Covers
-
Do You Clean the Same Data Again in Every Qlik Load Script?
The same mapping loads, string fixes and deduplication are written again in every app and QVD layer, and the copies drift apart. The cleansing is repeated per script because no integrated warehouse layer does it once.
-
Are Your Qlik Set Analysis Expressions Too Long and Too Slow?
Set analysis is precise for genuine comparisons. Most of the long expressions in your app are there because the model never delivered history, flags or a single grain, so the chart rebuilds them on every selection.
-
Do Your Qlik Apps Keep Creating Synthetic Keys?
Synthetic keys and circular references are Qlik associating exactly what it was given. They appear because the data arrives without conformed dimensions or real keys, so every app has to invent them.