Power BI is great. It's also too much for most reports.

Calling Power BI too complex is unfair to a very good tool, but for a six-number monthly report it is often the honest verdict. Power BI is a serious analytics platform, and a lot of the reports built in it would be quicker to build, and cheaper to share, somewhere else.

I have built a lot of Power BI dashboards. I like the tool. This post is about the gap between what it is designed for and what most people use it for.

What Power BI is actually good at

Credit first, because it has earned it.

Power BI is built around a semantic model: tables, relationships between them, and measures defined once and reused everywhere. Done well, that model is the single agreed definition of "revenue" for a whole company. Fifty reports can sit on top of it, and they all agree.

It handles large data properly, with incremental refresh, aggregations and a compression engine that keeps millions of rows responsive. It has row-level security, so a regional manager sees only their region in the same report the CEO uses. And it fits into Microsoft 365, Teams and SharePoint, which matters if that is where your company already works.

If you are a data team serving a few hundred people from governed data, Power BI is a sensible choice and this post is not trying to talk you out of it.

What a typical monthly report needs

Now look at what most reports actually contain. A monthly business review, a board update or a client report usually needs:

• Five to ten headline numbers
• A comparison for each one (last month, last year, or budget)
• One or two breakdowns, usually by region, product or channel
• A sentence or two explaining what moved

The data often comes from two or three sources, typically a CRM export, a finance spreadsheet and maybe Google Analytics. The audience is a handful of people who will never open the BI tool themselves.

That is an explanation problem, and for explanation problems much of Power BI's machinery is overhead.

The DAX tax

DAX is the formula language behind every Power BI measure. It is powerful, and it is the main reason people say Power BI is hard. The difficulty isn't syntax. It is filter context: the same measure returns a different value depending on where it is placed and what filters surround it.

Start with something simple. Margin is profit over revenue. In DAX you would typically write two base measures and a third that divides them:

Total Revenue = SUM(Sales[Revenue])
Total Profit = SUM(Sales[Profit])
Margin % = DIVIDE([Total Profit], [Total Revenue])

That is fine. Now someone asks for revenue compared with last year:

Revenue LY = CALCULATE([Total Revenue], SAMEPERIODLASTYEAR('Date'[Date]))

This only works if you have a proper date table, related to your sales table and marked as a date table, with no gaps. Many first Power BI projects stall right here, because the source data has a date column and nobody explained why that isn't enough.

Then someone asks what share of total revenue each region represents:

Region Share = DIVIDE([Total Revenue], CALCULATE([Total Revenue], REMOVEFILTERS(Sales[Region])))

Read that slowly. You compute revenue, then compute it again with the region filter deliberately removed, then divide. It is elegant once you understand filter context. Before that, it reads like a spell.

And there is the measure versus calculated column distinction, and SUM versus SUMX, where SUMX(Sales, Sales[Units] * Sales[Price]) iterates row by row while SUM doesn't. Each is a reasonable design decision. Together they make a learning curve that a finance manager with a monthly deadline doesn't have time to climb.

Compare the plain version. In a spreadsheet, region share is =B2/SUM(B$2:B$4). On a canvas, it is Share = @NorthRevenue / @Revenue. Margin is profit divided by revenue, written as profit divided by revenue. Nobody needs a lesson in context transition to read it.

The costs that aren't DAX

Complexity shows up in other places too.

Licences. Power BI Pro lists at $14 per user per month and Premium Per User at $24, billed annually, according to Microsoft's pricing page. The part that surprises people is that viewers generally need a licence as well, unless the content sits on a capacity that allows free viewers. Sharing a report with twenty people who only read it each month adds up quickly.

Desktop is Windows only. Authoring happens in Power BI Desktop, which runs on Windows. Mac users end up in a virtual machine or the more limited web editor.

Gateways and refresh. Data that lives on a local server or a laptop needs an on-premises data gateway to refresh in the cloud. Someone has to install it, keep it running and fix it when the password changes.

Publishing. Workspaces, apps, permissions and scheduled refresh are all sensible, and all extra steps between "the numbers are ready" and "the CFO can see them".

None of these is unreasonable for an enterprise platform. They are just a lot of platform for a six-number report.

When Power BI is worth it

Use this as a rough checklist. If several of these are true, Power BI is probably the right home:

• Your data spans many related tables, and the relationships matter to the answers.
• The same definitions are reused across many reports, and inconsistency would cause real damage.
• Different people must see different rows of the same report.
• The data is large: millions of rows that refresh daily.
• People check the dashboard every day as part of operations.
• Your company already pays for Microsoft 365 E5, which includes Power BI Pro.

When it isn't

And if these sound more like your situation, a lighter setup will serve you better:

• The report is monthly or quarterly, and it is mostly read in one meeting.
• The audience is small, and most of them would need a licence just to look.
• The person building it is an analyst or manager, not a BI developer.
• The hard question in the meeting is "why did this move?", not "what is the number?"
• The data comes from a few exports that already exist as spreadsheets.

In that second situation, I would rather spend the hours on the explanation than on the date table.

Five questions before you start a Power BI project

If you are about to build something new, these are worth answering in writing first. The answers usually make the choice obvious:

1. Who will open it, and how often? Ten people once a month is a different product from two hundred people every morning.
2. Do those people have licences? If not, who pays for them, and is that in the budget?
3. How many tables does the answer need? Count them. One or two is a spreadsheet problem. Fifteen is a modelling problem.
4. Who maintains it after launch? A Power BI report with no owner degrades faster than a spreadsheet, because fewer people can fix it.
5. What question will the first meeting ask? If it is "why did this move?", make sure the design answers that, whichever tool you pick.

None of these is a trick question. Plenty of honest answers point straight at Power BI, and that is a perfectly good outcome.

What simpler looks like

The simplest version needs no new tool at all. Keep the data in Excel or Google Sheets, write the handful of formulas you need in plain arithmetic, and draw a small metric tree that shows how the headline number is built. Add a snapshot of last month's values on a separate tab so comparisons are one subtraction. That setup has real limits, which I covered in why Excel dashboards break, but for a monthly review it beats a half-built semantic model.

The next step up is a tool built for explaining a few numbers rather than modelling many. That is what I built FlowProofs to be: plain formulas like Margin = @Profit / @Revenue * 100, numbers drawn as shapes on a canvas, and a link that viewers open for free. It is honestly the wrong choice if you need a 40-table data model or row-level security for hundreds of users. Keep Power BI for that. The Power BI comparison page lays out both sides, including where Power BI wins.

Before you choose any tool, though, try this test. Take your current Power BI report and count the measures that someone actually looks at in the monthly meeting. If the answer is under ten, write them out in plain arithmetic on one page. If that page explains the month better than the report does, you have your answer.