§Blog · 9 min read
How to audit a Power BI file you inherited
Someone hands you a .pbix file. Maybe the analyst who built it left. Maybe you bought a business and inherited its reporting stack. Maybe you are a new BI lead and this is the flagship board your executive team reads every Monday morning. In all three cases, the same question applies: can you trust what is in it?
The honest answer is: not yet. A Power BI file is a container holding a data model, a set of measures, a query layer, row-level security rules, and a refresh dependency chain. Any one of those layers can be broken, misleading, or silently wrong. The only way to know is to check them methodically.
You could do that by hand if you had two clear weeks and a tolerance for .pbix XML. Most managers do not. Here is the checklist, and here is what "bad" looks like at each step.
The Six-Point Inherited .pbix Checklist
1. Model Bloat: Unused Tables and Columns
Open the model view and count the tables. Then look at how many of those tables are actually referenced by a measure, a visual, or a relationship that matters. In production files built over multiple years, it is common to find 30 to 40 percent of columns never touched by a single visual or measure. Every one of those columns is imported into memory on every refresh.
What bad looks like: a staging table left in after a query was refactored, a date table imported twice under different names, dimension columns from a source system that nobody thought to remove. The practical consequence is that your refresh takes twice as long as it needs to, and your file sits at 400 MB when 180 MB would cover everything actually used. Before you trust the model, confirm the surface area is intentional.
2. Measure Divergence: Two Numbers That Should Match But Don't
This is the most dangerous class of problem because it is invisible until someone notices. A measure called Total Revenue on the finance page and a measure calledRevenue YTD on the executive summary page should agree when the filter context is equivalent. Often they do not, because one was written against a different date table, one uses CALCULATE with a filter that the author did not intend to be persistent, or one was copied from an older version of the file before a schema change.
What bad looks like: the board says $14.2M and the finance team's reconciliation says $14.6M, and nobody can explain the gap because both numbers come from the same file. To check this, you need to enumerate every measure that references the same base fact and compare their filter logic line by line. In a file with 80 to 120 measures, that is not a quick task.
3. Row-Level Security Gaps
If the file has row-level security configured, you need to verify that every role is actually restricting what it is supposed to restrict, and that there are no tables left outside the security perimeter. The most common gap: a new table is added to the model after the original RLS rules were written, and nobody updates the security definitions to cover it. Every member of every role can then see the full contents of that table.
What bad looks like: a regional manager role that was scoped to Australia can still browse the full customer table because RLS was only applied to the sales fact, not the customer dimension. The "View As Role" function in Power BI Desktop shows you what each role sees, but you have to know to run it, and you have to run it against every role systematically, not just the one the original analyst tested.
4. Broken or Fragile Refresh Dependencies
The Power Query layer connects your file to its sources. Each query step is a potential failure point. Source paths hard-coded to a developer's local machine will fail the moment the file is moved to a gateway. Queries that rely on a specific column name in the source will fail silently or error out if the upstream schema changes. Parameters that were intended to be environment-specific are often left baked in with development values.
What bad looks like: the file refreshes cleanly today because the gateway still has the old connection cached. Two weeks from now, when a source system is updated, six queries fail and the board goes dark. Checking this means reading every query's source step and confirming that the connection is parameterised correctly for the environment where it actually runs.
5. DAX Quality and Hidden Assumptions
A measure can produce the right number in the context it was tested in and the wrong number everywhere else. The most common DAX traps in inherited files: CALCULATE filters that override context in ways that are not obvious, ALLSELECTED used where ALL was intended, time intelligence functions that assume a specific date table relationship without documenting it, and division expressions with no blank-check on the denominator.
What bad looks like: a conversion rate measure that returns 0 instead of blank when the denominator is empty, causing a visual to show a floor of zero across all time periods where there was no activity. Or a rolling 12-month calculation that is hardwired to a specific year rather than calculated relative to the current date. These are not always bugs in isolation; they are assumptions the original author made that do not survive a change in context or a date rollover.
6. Governance: Who Changed What, and When
Power BI Desktop files do not have a native change log. If the file has been through multiple authors and multiple rounds of edits, there is no built-in way to see what was changed, when, or why. In practice this means you cannot distinguish between a measure that has been stable for three years and a measure that was quietly adjusted last month because a report was off.
What bad looks like: you find a version of the file in a shared drive dated six months ago and another version dated last week. The measures have different logic. Nobody in the business knows which version is authoritative or what changed between them. Without version control discipline from the start, the only way to reconstruct the history is to diff the XML inside the two files manually, and even then the diffs are not always interpretable.
What This Costs to Do Manually
A thorough manual pass through these six areas on a moderately complex file takes between two and four days for an experienced analyst, longer if the file is large or the original author is not available to answer questions. Most of that time is spent on the mechanical work: enumerating columns, cross-referencing measures, reading query steps, testing RLS roles. The judgement calls are fast once you have the data in front of you.
Nexlytics runs exactly this checklist automatically in roughly 90 seconds. Upload the .pbix in a browser, no install required, and it returns a scored verdict across all six areas plus a client-ready PDF you can use to brief stakeholders or frame a remediation plan. The framework behind it is the same one Onwards Analytics has used auditing Power BI environments for tier-one metals and mining clients over the past twelve years. The trial is $9.
Related: Nexlytics vs a manual Power BI audit.