Pro vs PPU vs capacity

What it does

Three ways of paying for Power BI, and the job of working out which shape a client needs. Pro is per user for authors and viewers. PPU is per user with most Premium features attached. Capacity is an organisational subscription that carries the compute and, above a threshold, the viewers.

Key facts

Authors always need a paid per-user licence. Creating content in any workspace other than My workspace requires at least Pro, no matter how much capacity the organisation buys.
On shared capacity, everyone in the sharing loop needs Pro. Publisher and viewer both.
PPU adds most Premium features per user, and restricts consumption to other PPU holders unless the workspace is on capacity.
Capacity above the free-viewing threshold — Microsoft states F64 or larger, or a Premium P capacity — lets free-licensed users view content, provided they hold a workspace role or app access.
Both the report and its semantic model must be on the qualifying capacity for free viewing. One without the other produces an upgrade prompt.
Microsoft is retiring the Power BI Premium per-capacity P SKUs and advises customers to consider Fabric F SKUs. Guidance for both coexists in the documentation during the transition.
Below F64, capacity buys compute and features, not licence relief.
Workspaces can be moved between PPU and capacity, but moving a workspace back onto capacity requires a full refresh of its semantic models and dataflows.
Fabric trial capacities run at 64 CUs for sixty days and behave like a paid capacity while they last.

When to use / skip

The honest rule: count authors and viewers separately, then find the smallest shape that carries both. Ten authors and thirty viewers is Pro for all forty, and no amount of enthusiasm about capacity features changes that. Ten authors and eight hundred viewers is capacity at F64 or above, with Pro for the ten. A closed team of fifteen who need large models, frequent refresh and XMLA, sharing with nobody outside — that's PPU, and it's the only shape PPU is really for.

The failure you'll actually meet is a client buying PPU for the modelling team and expecting the business to read the output. It doesn't work: PPU content is only accessible to PPU holders. The other failure is buying capacity below F64 in the belief that it removes per-user cost. Both are avoidable with one question asked early, and both are expensive to unwind once workspaces and apps have been built around them.

Configuration decisions

Author count and viewer count, gathered from the client, written down, and agreed with whoever signs the invoice. Everything else follows from these two numbers.
Whether the viewer population is going to grow. A shape that works at three hundred and breaks at a thousand is a shape you'll be migrating in eighteen months.
Whether any Premium-only feature is genuinely required, and by whom. Name the feature; "we might want AI" is not a requirement.
Whether the content ever needs to leave the team. This is the PPU question and it decides PPU versus capacity on its own.
Whether the workload needs Fabric items — lakehouses, notebooks, pipelines — because that pushes towards F SKUs regardless of the viewer maths.
Where the capacity boundary sits between business units, and who gets blamed when one unit's refresh degrades another's reports.

Gotchas

The semantic model placement rule catches almost everyone. A shared enterprise model left on a Pro workspace turns every downstream free viewer into a paid one, and the error message gives no clue.
Buying just under the free-viewing threshold is the worst outcome available: capacity cost plus per-user cost.
Moving a workspace from PPU back onto capacity forces full refreshes. On a large incremental model that's hours nobody scheduled.
Individual PPU trials mean PPU features can creep into a tenant without a purchasing decision, and content starts depending on them.
Pilots on trial capacity look wonderful and then expire. Sixty days later the licensing conversation happens under time pressure.
P SKU and F SKU guidance disagree in places while the consolidation runs. Take the more recently updated page and say so rather than resolving it quietly.

Consultant notes

Do the arithmetic on a whiteboard in front of the client. Licensing disputes end faster with numbers on a wall than with a slide deck.
Never quote a price from memory. Point at the Microsoft pricing page and the current licensing documentation, and let procurement own the figure. Getting this wrong in a workshop is the kind of error that follows you into a contract.
Ask "who reads this?" before "what do you need?". Feature requirements pull towards PPU; audience requirements pull towards capacity, and the audience nearly always wins.
Put the recommendation in writing with the assumptions attached — author count, viewer count, growth assumption, threshold SKU. When one assumption changes, you can show which conclusion moved.
For existing P SKU customers, add the P-to-F migration to the plan explicitly. It's a live retirement and it will come up in a renewal conversation whether or not you raised it.

Re-run the numbers whenever the SKU line-up or the free-viewing threshold shifts — the whole guide hangs on those two facts