PBIR, PBIP and TMDL explained: how finance teams are putting Power BI under source control

Somewhere on a shared drive near you sits Board_Pack_v7_FINAL_FINAL(2).pbix. Nobody knows who changed the gross margin measure in March, or why. Internal audit has just asked. And the person who might remember left in April.

This is the problem Microsoft has spent the last two years quietly solving, and 2026 is the year it lands. The fix comes with three acronyms. Here's what they mean, why the regulated end of finance cares more than most, and how to get started without turning your reporting team into a software house.

What PBIR, PBIP and TMDL actually are

For years a Power BI report was one big binary file. You couldn't read it, compare it, or merge two people's changes to it. Two developers touching the same report meant one of them losing. The new formats break that file open into text.

1.PBIP — Power BI Project

The folder. Instead of one .pbix, you save as a project and get a directory of plain-text files: one bit for the report, one bit for the semantic model. This is the container the other two live in.

2.PBIR — Power BI Enhanced Report Format

The report, as readable JSON. Every page is a file. Every visual is a file. Every bookmark is a file. Change the colour of one bar chart and Git sees three lines of JSON change, not a 40 MB blob. It has a published schema, so VS Code can validate it, and so can scripts and AI agents.

3.TMDL — Tabular Model Definition Language

The model, as text. Tables, measures, relationships and roles written out in a format humans can read and diff. TMDL view has been in Desktop for a while; since July you can edit it in the browser too, straight from the service.

Where things stand: new reports in the Power BI service have used PBIR by default since January. Desktop has been switching over through the summer, and general availability for the full PBIP format is due later this year. Your .pbix files aren't going anywhere; PBIR simply lives inside them. Anyone who doesn't care about Git will never notice.

Why regulated finance teams care more than most

Because "who changed it, when, and who signed it off" is not a nice-to-have when the FCA, the PRA or your own second line are asking. The regulators' thinking on model risk (the PRA's SS1/23 being the obvious one) expects an inventory, change control and independent review. Internal audit has been chasing end-user computing controls since the spreadsheet days. Power BI has largely escaped that scrutiny because it was too awkward to audit properly. Not anymore.

With text-based reports in Git you get, for free:

• A line-by-line history of every change to every measure, with a name and a timestamp against it.
• A pull request with two named reviewers, which is four-eyes control without a separate form.
• The ability to roll back to last Tuesday's version in one command rather than a Teams plea.
• Promotion from dev to test to production through Fabric deployment pipelines, so the version the board sees is the version that was approved.

Put plainly: this is the difference between telling an auditor "we think Dave changed it" and showing them the commit.

Getting Power BI into source control: a starting checklist

1. Turn on the project format. In Desktop, save a copy of a small, non-critical report as a .pbip and open the folder. Read what's in it. That half hour demystifies the whole thing.
    
2. Pick your repo. Most finance houses already have Azure DevOps or GitHub Enterprise with a change process wrapped round it. Use that. Inventing a new one for Power BI is how you end up with two audits.
    
3. Connect a Fabric workspace to Git. You'll need a workspace on Fabric capacity or Premium Per User. Once linked, the workspace syncs with a branch; changes made in the service or pushed from Desktop show up as commits.
    
4. Set a branch policy. Nothing merges to main without a pull request and at least one reviewer who isn't the author. That single rule satisfies most of what a control framework wants.
    
5. Add a .gitignore on day one. Cache files, local settings and anything with data in it stay out of the repo. Model definitions in; the 4 million rows behind them very much out.
    
6. Use deployment pipelines for dev, test and prod. Separate workspaces, promoted in order. This is what lets you say "production hasn't changed since the 14th" and mean it.
    
7. Teach people to read a diff. The tooling is the easy part. A reviewer who can look at a TMDL change and spot that a filter context has quietly shifted is worth more than any pipeline.

The honest caveats

It isn't magic. Merge conflicts in JSON are real, and two people rearranging the same page will still need a conversation. Some older visuals and features lag behind on PBIR support. Git integration needs the right licence tier. And the first month is slower, not faster, because the team is learning a new habit. Budget for that, then enjoy the years afterwards where nobody asks who changed the margin measure, because everyone can see.
 

Editor's insight

The teams that get this working aren't the ones with the best developers. They're the ones where the analysts, the finance leads and the reviewer from risk all understand the same folder structure and the same workflow. Source control only works when the whole team speaks it. Excelgoodies runs live, instructor-led Power BI Courses, mostly employer-funded, that now cover PBIP, TMDL and Git as part of the standard curriculum rather than as an optional extra, for anyone who'd rather learn it in a room than from the first merge conflict.

Power BI