10 July 2026
Your data governance policy never reaches the layer where Power BI breaks it
Data governance rarely fails at the policy. It fails at the semantic layer, when SAP Master Data Governance defines a customer and Power BI redefines one.
Most data governance programmes we see have a role model, a data catalogue, and a committee that rules on definitions. What they don't have is an answer to a simple question: if SAP Master Data Governance decides what a customer is, why does the Power BI semantic model three layers down define its own customer?
What SAP Master Data Governance actually enforces
SAP Master Data Governance centralises the maintenance of master data such as customer, material, or vendor records in S/4HANA. A record goes through an approval workflow before it counts as valid. That's the single source of truth the rest of the organisation is meant to rely on, at least on paper. In practice, that governance stops at the system boundary. Once the data is replicated through Data Factory or a direct connection into Azure SQL, nobody is left responsible for making sure the downstream models use the same definition.
Where the gap actually opens
Power BI makes this gap visible without causing it. A semantic model built directly against replicated tables instead of governed views inherits none of the business rules MDG enforced. A DAX measure that recalculates "active customer" does so by the logic of the person who wrote it, not the logic baked into the approval workflow. Once a second workspace appears, with a second model and a second definition of "active," the dashboards disagree, and the data governance policy that was supposed to prevent exactly this never found out.
Data lineage as the actual control point
A role model shows who owns a definition. It doesn't show whether that definition actually arrives where reports get built. That takes data lineage, traceable from the governed master-data table in S/4HANA through the integration layer to the individual measure in the Power BI model. Without that chain, a simple question has no answer: which of the twelve definitions of "revenue" circulating across your organisation's workspaces actually matches what Finance signed off on?
What that means for the next step
A data governance policy that exists only on paper doesn't change this pattern. The approach that actually works starts at the other end: auditing the semantic models, mapping the workspace structure, and making the lineage from the master-data source to the report visible. That's the exact scope of our Power BI & Fabric Review. Where the governance questions go beyond the reporting layer, for instance regulatory requirements on data provenance, we cover that on our governance page.