Sooner or later, in every organisation running BI at any scale, the finance team asks the question: why is this costing so much? And the reflex, every single time, is to look at the licence line. Cut a few Pro licences, renegotiate the Premium tier, squeeze the per-seat cost — that's where people instinctively go, because it's the number with a clear label. It's also almost never where the money actually is. I've done enough cost work now to say it plainly: the licence is the visible cost, and the visible cost is rarely the big one. The real money leaks out through waste you can't see on an invoice — inefficient compute, duplicated effort, and models nobody ever cleaned up — and that's genuinely good news, because waste is far easier to cut than the price of the tool.

I learned this most vividly on a cleanup where we took infrastructure cost down by a serious margin — I wrote up the −44% story at the time — and almost none of the saving came from licensing. It came from the unglamorous middle of the stack, the part nobody puts on a slide. Let me lay out where it actually hides.

Where the money really goes

  • Refreshes doing far more work than they need to. This is the big one. Datasets reloading their entire history every few hours when only recent data changed; refreshes scheduled hourly on data that updates daily; a dozen reports each independently pulling and transforming the same source. Every needless refresh is compute you're paying for to recompute something that didn't change. On a capacity model this is direct money, and it's usually the single largest pool of waste.
  • The same work done many times over. Five teams each build their own version of the customer table, their own revenue measure, their own date logic — computed separately, stored separately, refreshed separately. You're paying five times to produce five slightly different answers to the same question, and then paying again in the meetings where people argue about which number is right.
  • Models that grew and were never pruned. Datasets carrying columns nobody uses, granularity finer than any report needs, history nobody looks at — all of it consuming memory and refresh time. A model on a diet refreshes faster and fits in a smaller, cheaper capacity.
  • Over-provisioned capacity absorbing the inefficiency. When the workload is wasteful, the fix everyone reaches for is a bigger capacity — paying more to power through the waste rather than removing it. You end up renting headroom to accommodate inefficiency you could have deleted for free.

Notice that not one of those is a licence. They're all operational waste, and they compound: the redundant refreshes on the bloated models push you toward the bigger capacity, and round it goes.

How to actually cut it

The method is boring and it works: measure before you cut. Find out what's actually consuming your capacity — which datasets, which refreshes, which reports — because the waste is never evenly spread. It's almost always a handful of offenders eating a disproportionate share, and you can't fix what you haven't measured. Then, in rough order of payoff:

  1. Fix the refreshes. Match refresh frequency to how often data genuinely changes. Adopt incremental refresh on the big fact tables so you stop reloading settled history. This is usually the fastest, largest saving available.
  2. Consolidate the duplication. One certified customer table, one revenue measure, built once and shared. This cuts compute and ends the "which number is right" argument, which has its own hidden cost in wasted human hours.
  3. Put the models on a diet. Drop unused columns, coarsen granularity to what reports actually need, trim history to what anyone looks at. Smaller models are cheaper in memory, refresh, and capacity size all at once.
  4. Right-size the capacity — last. Only after you've removed the waste should you look at the capacity tier, because now you're sizing for real need instead of for the inefficiency you could have deleted. Do it in the other order and you just lock in the waste at a lower price.

The reframe for the finance conversation

So when finance asks why BI costs what it does, the productive move is to change the question from "can we pay less for the tool?" to "how much of what we're paying is waste?" The licence conversation caps out quickly — there's only so much to squeeze, and squeezing too hard just annoys the users who need the seats. The waste conversation, by contrast, is where the real money lives, and cutting it makes the platform better at the same time: faster refreshes, trustworthy shared numbers, leaner models, a right-sized bill. You rarely get to cut cost and improve quality in the same move, but BI waste is one of those happy places where you do.

Here's the fair counter-view: licence and tier optimisation isn't nothing, and for some organisations — heavy on seats, light on compute — it's a legitimate lever worth pulling. Don't ignore it. Just don't start there, and don't let it be the whole conversation, because for most organisations the licence is the small, visible tip of a much larger, invisible iceberg of operational waste. The money that makes finance happy isn't hiding in the price of Power BI. It's hiding in how carelessly you were using it — and careless is a thing you can fix for free.