How to Audit Power BI Semantic Models and Slash Capacity Spend

Licensing is not the footnote in your BI strategy—it’s the horror movie twist nobody sees coming. One month you feel empowered with Fabric; the next your CFO is asking why BI costs more than your ERP system. It’s not bad math; it’s bad planning.

The scariest part? Many organizations lack clear approval paths or policies for license purchasing, so expenses pile up before anyone notices. Stick around—we’re breaking down how to avoid that mess with three fixes: Fabric Domains to control sprawl, a Center of Excellence to stop duplicate buys, and shared semantic models with proper licensing strategy.

And once you see how unchecked self-service plays out in real life, the picture gets even messier.

The Wild West of Self-Service BI

Welcome to the Wild West of Self-Service BI. If you’ve opened a Fabric tenant and seen workspaces popping up everywhere, you already know the story: one team spins up their own playground, another duplicates a dataset, and pretty soon your tenant looks like a frontier town where everyone builds saloons but nobody pays the tax bill. At first glance, it feels empowering—dashboards appear faster, users skip the IT line, and folks cheer because they finally own their data. On the surface, it looks like freedom.

But freedom isn’t free. Each one of those “just for us” workspaces comes with hidden costs. Refreshes multiply, storage stacks up, and licensing lines balloon. Think of it like everyone quietly adding streaming subscriptions on the corporate card—individually small, collectively eye-watering. The real damage doesn’t show up until your finance team opens the monthly invoice and realizes BI costs are sprinting ahead of plan.

Here’s where governance makes or breaks you. A new workspace doesn’t technically require Premium capacity or PPU by default, but without policies and guardrails, users create so many of them that you’re forced to buy more capacity or expand PPU licensing just to keep up. That’s how you end up covering demand you never planned for. The sprawl itself becomes the driver of the bill, not any one big purchase decision.

I’ve seen it firsthand—a sales team decided to bypass IT to launch their own revenue dashboard. They cloned central datasets into a private workspace, built a fresh semantic model, and handed out access like candy. Everyone loved the speed. Nobody noticed the cost. Those cloned datasets doubled refresh cycles, doubled storage, and added a fresh patch of licensing usage. It wasn’t malicious, just enthusiastic, but the outcome was the same: duplicated spend quietly piling up until the financial report hit leadership.

This is the exact trade-off of self-service BI: speed versus predictability. You get agility today—you can spin up and ship reports without IT hand-holding. But you sacrifice predictability because sprawl drives compute, storage, and licensing up in ways you can’t forecast. It feels efficient right now, but when the CEO asks why BI spend exceeds your CRM or ERP, the “empowerment” story stops being funny.

The other side effect of uncontrolled self-service? Conflicting numbers. Different teams pull their own versions of revenue, cost, or headcount. Analysts ask why one chart says margin is 20% and another claims 14%. Trust in the data erodes. When the reporting team finally gets dragged back in, they’re cleaning up a swamp of duplicated models, misaligned definitions, and dozens of half-baked dashboards. Self-service without structure doesn’t just blow up your budget—it undermines the very reason BI exists: consistent, trusted insight.

None of this means self-service is bad. In fact, done right, it’s the only way to keep up with business demand. But self-service without guardrails is like giving every department a credit card with no limit. Eventually someone asks who’s paying the tab, and the answer always lands in finance. That’s why experts recommend rolling out governance in iterations—start light, learn from the first wave of usage, and tighten rules as adoption grows. It’s faster than over-centralizing but safer than a free-for-all.

So the bottom line is simple: Fabric self-service doesn’t hand you cost savings on autopilot. It hands you a billing accelerator switch. Only governance determines whether that switch builds efficiency or blows straight through your budget ceiling.

Which brings us to the next step. If giving everyone their own workbench is too chaotic, how do you maintain autonomy without burning cash? One answer is to rethink ownership—not in terms of scattered workspaces, but in terms of fenced-in domains.

Data Mesh as Fencing, Not Policing

Data Mesh in Fabric isn’t about locking doors—it’s about putting up fences. Not the barbed-wire kind, but the sort that gives people space without letting them trample the neighbor’s garden. Fabric calls these “Domains.” They let you define who owns which patch of data, catalog trusted datasets as products, and give teams the freedom to build reports without dragging half the IT department into every request. Think of it less as policing and more as building yards: you’re shaping where work happens so licensing and compute don’t spiral out of control.

Here’s the plain-English version. In Fabric, a domain is just a scoped area of ownership. Finance owns revenue data. HR owns headcount. Sales owns pipeline. Each business unit is responsible for curating, publishing, and certifying its own data products. With Fabric Domains, you can assign owners, set catalog visibility, and document who’s accountable for quality. That way, report writers don’t keep cloning “their own” revenue model every week—the domain already provides a certified one. Users still self-serve, but now they do it off a central fence instead of pulling random copies into personal workspaces.

If you’ve ever lived through the opposite, you know it hurts. Without domains, every report creator drags their own version of the same dataset into a workspace. Finance copies revenue. Sales copies revenue. Ops copies it again. Pretty soon, refresh times triple, storage numbers look like a cloud mining operation, and you feel forced to throw more Premium capacity at the problem. That’s not empowerment—it’s waste disguised as progress.

Here’s the kicker: people assume decentralization itself is expensive. More workspaces, more chaos, more cost… right? Wrong. Microsoft’s governance guidance flat-out says the problem isn’t decentralization—it’s bad decentralization. If every domain publishes its own certified semantic model, one clean refresh can serve hundreds of users. You skip the twelve duplicate refresh cycles chewing through capacity at 2 a.m. The waste only comes when nobody draws boundaries. With proper guardrails, decentralization actually cuts costs because you stop paying for cloned storage and redundant licenses.

Let’s put it in story mode. I once audited a Fabric tenant that looked clean on the surface. Reports ran, dashboards dazzled, nothing was obviously broken. But under the hood? Dozens of different revenue models sitting across random workspaces, each pulling from the same source system, each crunching refresh jobs on its own. Users thought they were being clever. Finance thought they were being agile. In reality, they were just stacking hidden costs. When we consolidated to one finance-owned semantic model, licensed capacity stabilized overnight. Costs stopped creeping, and the CFO finally stopped asking why Power BI was burning more dollars than CRM.

And here’s the practical fix most teams miss: stop the clones at the source. In Fabric, you can endorse semantic models, mark them as discoverable in the OneLake catalog, and turn on Build permission workflows. That way, when a sales analyst wants to extend the revenue model, they request Build rights on the official version instead of dragging their own copy. Small config step, big financial payoff—because every non-cloned model is one less refresh hammering capacity you pay for.

The math is simple: trusted domains + certified semantic models = predictable spend. Everybody still builds their own reports, but they build off the same vetted foundation. IT doesn’t get crushed by constant “why isn’t my refresh working” tickets, business teams trust the numbers, and finance doesn’t walk into another budget shock when Azure sends the monthly bill. Domains don’t kill freedom—they cut off the financial bleed while letting users innovate confidently.

Bottom line, Data Mesh in Fabric works because it reframes governance. You’re not telling people “no.” You’re telling them “yes, through here.” Guardrails that reduce duplication, published models that scale, and ownership that keeps accountability clear. Once you set those fences, the licensing line on your budget actually starts to look like something you can defend.

And while fenced yards keep the chaos contained, you still need someone walking the perimeter, checking the gates, and making sure the same mistakes don’t repeat in every department. That role isn’t about being the fun police—it’s about coordinated cleanup, smarter licensing, and scaling the good practices. Which is exactly where a Center of Excellence comes in.

The Center of Excellence: Your Licensing SWAT Team

Think of the Center of Excellence as your licensing SWAT team. Not the Hollywood kind dropping out of helicopters, but the squad that shows up before every department decides their dashboard needs a separate budget line. Instead of confiscating workspaces or wagging fingers, they’re more like a pit crew—tightening bolts, swapping tires, and keeping the engine from catching fire. And in this case, the “engine” is your licensing costs before they spin out of control.

Here’s the problem: every department believes they’re an exception. HR thinks their attrition dashboard is one of a kind. Finance claims their forecast model is so unique that no one else could possibly share it. Marketing swears their campaign reports are too urgent to wait. That word “unique” becomes the license to duplicate datasets, spin up redundant workspaces, and, yes, buy extra capacity or PPU licenses without telling anyone. It’s not usually malicious—teams just want speed—but it creates fractured costs the CFO sees as one giant bill.

I’ve watched this happen more than once. A team spins up Premium Per User because they want instant access to advanced features. Another group builds their own Premium capacity for “performance.” Both decisions are made in silos, without tenant-level coordination. The result is double spending on separate licensing tiers for overlapping use cases. Try explaining that in a budget defense meeting—you’ll barely make it through the first slide before finance tells you to shut it down. That’s exactly the kind of silent licensing creep the COE exists to stop.

The way it stops is simple: the COE sets the playbook so each team doesn’t reinvent one. Their responsibilities go beyond just watching invoices. In practice, it means they: charter standards for workspace creation, publish policies for lifecycle management, train users to connect to endorsed semantic models, maintain the catalog of certified datasets, and monitor activity logs to catch when usage patterns hint at overspending. Those may sound like governance buzzwords, but in plain English it’s a checklist: write the rules, teach the rules, share the data properly, keep the records clean. Done right, that checklist alone saves thousands in redundant licensing.

Here’s one practical move you can copy tomorrow: publish a short set of workspace policies. Decide who can request a workspace, which ones require Premium capacity approval, set lifecycle rules for archiving, and keep a regularly updated catalog of which datasets are certified. That one document alone cuts down duplicate projects and keeps license usage mapped to actual business need instead of whatever someone bought last quarter.

What makes a COE even more powerful is that it’s not just policy muscle—it’s also mentorship. They don’t just say “don’t clone that model.” They teach analysts why building off certified versions matters, show workspace leads how to right-size capacity, and match use cases to the correct license tier so managers don’t overspend “just to be safe.” Training often reduces costs more than enforcement because people stop creating problems in the first place.

But here’s the underrated piece: the Community of Practice. Get analysts from Finance, Ops, and Marketing talking together in a shared forum, and suddenly they realize they’re solving the same problems. Peer pressure and shared tips cut down duplication better than a dozen policy memos. It’s governance that scales by culture, not bureaucracy. When someone in Sales admits “we solved that refresh bottleneck by using the Finance model,” everyone else picks it up—no mandate required.

The real payoff of a strong COE is predictable spend. Instead of chaotic months where hidden purchases swing costs like a yo-yo, you get consistent licensing strategies and stable capacity usage. Executives stop doubting whether BI offers ROI, IT stops playing cleanup, and departments get the speed of self-service without blowing through the company credit card. That balance—empowerment with discipline—is what keeps the BI program alive long term.

Bottom line: the COE keeps self-service from becoming self-sabotage. Not by saying “no,” but by showing a smarter “yes.” They capture winning patterns, prevent waste, and turn financial surprises into controlled costs. It’s the only way to keep the promise of self-service BI without waking up to a wrecked licensing budget.

And while the COE patches a lot of leaks, there’s one drain that runs straight under the surface and often goes unnoticed. It’s not just the obvious licenses that hurt—it’s the hidden costs inside the semantic models themselves.

Semantic Models: Where Costs Hide

Semantic models are where the money quietly drains out of your Fabric tenant. They look harmless—just a data brain feeding your reports—but the moment users start cloning them, the costs start stacking. Each duplicate eats storage, spawns its own refresh schedule, and chews through compute cycles. None of that might show up in your day-to-day dashboarding, but it shows up in capacity costs and invoices. Duplicates multiply refresh jobs and wasted storage, which means your cloud bill grows faster than your forecast.

In plain English, a semantic model is the reusable foundation. Reports don’t actually hold the data themselves—they connect to a model that defines relationships, measures, and calculations. Think of it as the recipe book driving your dashboards. If everyone uses the same certified recipe, great. But when every team photocopies the whole thing just to adjust the seasoning, you end up maintaining dozens of almost-identical cookbooks. Every one of those copies takes compute to refresh and capacity to store, whether anyone is reading it or not.

This duplication sounds small, but it inflates costs in silence. A dozen cloned models all hitting refresh overnight can triple your compute load without warning. Teams convince themselves each copy is “custom” or “needed for speed,” but in practice most of them are just replicas wearing a different workspace badge. It’s like printing 500-page binders for every department instead of handing out one shared PDF. The company’s drowning in toner, paper, and maintenance—all to maintain stacks of nearly identical manuals nobody has time to reconcile.

The fix isn’t complicated, but it takes discipline. Stop letting everyone spawn their own model whenever they hit a roadblock. Instead, push them toward endorsed models—either promoted or certified—and make those models easy to find. Fabric lets you mark models as discoverable in the OneLake catalog so users don’t have to guess what’s available. Pair that with Build permissions, so report writers can request access to extend the existing model instead of copying the whole thing. That one-two punch cuts the number of phantom clones in half overnight.

Another practical move: run an audit. Have your COE or governance team pull activity logs and use the lineage view in Power BI. The lineage map shows which reports depend on which models. It also reveals when 15 “different” sales reports are actually pointing at 15 cloned sales models. Once you spot the duplicates, consolidate to a single endorsed version and redirect reports back to it. Not glamorous—but it’s the difference between paying 15 refresh bills every day or one refresh bill that serves everyone.

Some admins push back because endorsing a semantic model feels like overhead. You need an owner, you need to vet the definitions, someone has to certify it. But that overhead is cheaper than sprawl. One certified model replaces a dozen cloned ones. One refresh feeds hundreds of reports. You cut capacity costs, improve trust in the numbers, and eliminate the “which revenue number is right?” arguments. Consolidation isn’t just cleaner—it saves real money every billing cycle.

The payoff is simple and tangible. Consolidating models removes parallel refresh jobs, stabilizes costs, and ensures your users connect to a single, trusted source. Instead of constantly firefighting capacity alerts, you can predict usage. Instead of reconciling conflicting numbers, teams rally around one version of the truth. It’s cost control and governance in one move.

Bottom line: endorse your models, catalog them, and keep discovery turned on. Don’t wait for finance to throw a fit—cut off the silent creep before it hits your budget. A tenant with 20 scattered sales models will burn cash. A tenant with one certified sales model will run predictably. That predictability is what keeps your analytics program funded for the long run.

And once you get models under control, the next trap comes into view—the part of the equation everyone underestimates at the start. It isn’t about storage or refresh jobs anymore. It’s about how the licensing math itself flips from feeling cheap to looking like an ERP-sized expense overnight.

The Real Horror: Licensing Math Gone Wrong

Here’s where the math side of licensing comes back to bite. The real horror isn’t the dashboards or the datasets—it’s what happens when the wrong license model gets picked without a plan. Premium Per User looks harmless at the start. You hand out a few PPU licenses for a proof of concept, and it feels cheap and painless. Small team, small spend, fast results. But when adoption spreads and suddenly hundreds of users expect access, that per‑user approach stops being pocket change and starts behaving like a runaway tab at an open bar.

That’s the trap: PPU works great for pilots or contained groups of power users because you only license what you need. Once BI starts spreading across departments, though, everyone wants in—and every seat costs you. At that point you’re not paying for analytics at scale, you’re paying one microcharge at a time, and the total doesn’t stay small. Compare that to Premium Capacity: yes, it stings when you see the upfront price tag, but it covers broad usage. Once the audience grows, capacity is predictable while PPU costs just keep multiplying.

Where most organizations stumble is failing to forecast how quickly those audiences grow. A single report takes off in popularity, managers forward it around, and suddenly people across finance, sales, and ops all need in. If you’re still stuck on PPU, the only way to serve them is to buy dozens—or hundreds—of additional licenses in a hurry. Some IT shops find themselves scrambling to convert to Premium Capacity after adoption is already out of control, which leads to messy overlaps and ugly invoices. These aren’t “gotchas” baked in by Microsoft; they’re the direct result of skipping early planning.

I watched one marketing department roll out 40 PPUs for a pilot campaign. Reports worked well, got noticed by executives, and then went global in weeks. IT had to scramble to open access across other departments, but by that point the PPU footprint had ballooned. The end result? A rushed move into Premium Capacity layered on top of existing PPU spend. Finance wasn’t amused. The technical wins were real, but the financial optics were “we bought the same tool twice.” That is exactly the kind of budgeting headache most leaders won’t tolerate.

Microsoft’s own governance playbooks point at the same answer: plan licensing strategy early. Treat it like infrastructure decisions, not one-off team expenses. Think about Wi-Fi: you don’t buy a router per laptop, you plan coverage for the office. BI is no different. Without that upfront decision, unplanned growth guarantees a panic spend later. And unlike a surprise pizza order, this bill isn’t five digits—it can hit way higher.

So what’s the practical move? Run a basic forecast instead of winging it. Map who your initial users are, then project adoption if reports get shared across the wider org. Ask: how many users, how often do they hit reports, how many refresh jobs run in peak business hours? You don’t need hard math—just enough to see whether you’re better off staying on a handful of PPUs or jumping to Premium Capacity earlier. That simple back-of-the-napkin exercise gives you predictable spend instead of sticker shock.

Governance structures help here as well. With Data Mesh principles, domain owners can predict how widely their data products will spread. With a Center of Excellence, you can map licensing strategy to actual usage patterns instead of guessing. Together, they turn licensing from a reaction to a design choice. That means you don’t wait for finance to complain—you proactively explain the plan, complete with cost curves, and avoid the budget firefight entirely.

Bottom line: PPU is for pilots, capacity is for scale. Confuse the two, and you’ll end up paying more than you expect while adoption races ahead of control. The goal isn’t to stall innovation—it’s to make sure growth doesn’t set off alarms in the finance department.

And that brings us full circle. The real nightmare isn’t Fabric itself—it’s deploying it without fences, playbooks, or any sense of scale. The good news? That nightmare isn’t inevitable.

Conclusion

Fabric self-service BI doesn’t sink budgets on its own—it’s how you manage it. The fix isn’t flashy, but it’s practical. This week you can: audit for duplicate semantic models and endorse a trusted version; define domain ownership and workspace policies to stop uncontrolled sprawl; and have your COE lock in a licensing plan—PPU for pilots, Premium Capacity for scale—while training teams to use what you already pay for.

Governance isn’t bureaucracy here—it’s the mechanism that lets self-service run safely and predictably without draining your budget. Subscribe at m365.show for the survival guides and follow the M365.Show LinkedIn page for live MVP sessions.

This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit m365.show/subscribe