Power BI Pricing: What It Costs per User, per Capacity and per Customer

Why There Is No Single Power BI Price

You want one number. We found three, spread across three Microsoft pages.

Power BI pricing is the set of three separate cost models Microsoft uses to sell Power BI: per-user licences (Pro at $14.00 and Premium Per User at $24.00 per user/month paid yearly), Microsoft Fabric F stock-keeping units (SKUs) priced per hour but billed per second (Microsoft Learn) (F64 is $11.52/hour pay-as-you-go in Central US), and Power BI Embedded A SKUs, hourly Power BI-only capacity for app-owns-data embedding (Azure). All figures were checked on 23 September 2026 and vary by region and currency.

Which model applies depends on the embedding scenario. Viewers who sign in, whether staff or named guests in your tenant, need a Pro or PPU licence on any A SKU and on F capacity below F64; on an F64-or-larger F SKU or a P SKU, free Power BI users can consume shared content (Microsoft Learn).

When a software company embeds reports for its own customers under app-owns-data, end users need no licence on any SKU (Microsoft Learn). They still size the capacity, because their usage and concurrency drive its compute load, so the bill becomes a capacity-sizing decision (Microsoft Learn).

Microsoft's Power BI pricing page shows Fabric and Embedded only as "Variable", with a footnote citing "currency, country, and regional variant factors."

Power BI is a strong internal business intelligence (BI) tool. There's no single price because it's sold three ways on three pages, and the usual landing page hides two behind "Variable".

What Power BI Actually Costs: The Three Pricing Models

Power BI is paid for in three ways: per user (Pro or Premium Per User, PPU), per Fabric capacity (F stock-keeping units, or SKUs) and per embedded capacity (Power BI Embedded A SKUs). Each model assumes a different kind of viewer.

The table is also a list of what each model is not. Pro and PPU are per-user seats. They can reach people outside your company through Microsoft Entra B2B guest access: Microsoft's guest-sharing guide (read 23 September 2026) says that "Assigning a Power BI Pro or PPU license from your organization to a guest user lets that guest user view content shared with them."

That is the user-owns-data path, though, and every external reader is a named guest in your tenant, holding a Pro or PPU licence or reading from F64-or-larger F or P capacity, never from an A SKU. Pro and PPU are not a way to license the customers of a SaaS product, which is app-owns-data on capacity.

F capacity is shared compute that serves every Fabric workload, so it isn't a Power BI-only purchase. A SKUs are the narrowest of the three, and Microsoft's Fabric licensing documentation (read 23 September 2026) states that "A and EM SKUs only support Power BI items." Teams often come to us after multiplying a Pro seat price by their customer count, which prices the wrong model entirely.

Decide which model you're buying under before you price anything. A seat count and an hourly capacity rate don't convert into each other.

Power BI Pro and Premium per User: The Per-Seat Prices

Power BI Pro costs $14.00 per user per month and Premium Per User (PPU) costs $24.00 per user per month, both paid yearly, according to the list prices we read on Microsoft's Power BI pricing page on 23 September 2026. Microsoft's own footnote says that "Prices shown are for marketing purposes only and may not be reflective of actual list price due to currency, country, and regional variant factors." Treat both figures as the start of a quote, not the quote itself.

For the job they're built for, these are fair prices. If you run internal enterprise reporting inside a Microsoft estate, some of your people may already hold Pro seats through an existing agreement; Microsoft 365 E5, for example, includes Pro (Microsoft Learn). In that case the seat is sunk cost before anyone opens a report. We'd tell most teams in that position to use what they've already paid for, because Power BI is a strong internal business intelligence (BI) tool and per-seat licensing fits an employee population you already manage.

The limit is provisioning. A per-user licence assumes a named viewer you sign in and assign a seat to. It's also the wrong model once your viewers are your product's customers rather than named guests in your tenant.

Per-user is the only Power BI cost model with a simple number. External viewers aren't automatically excluded from it: Microsoft's user-owns-data model can extend Pro or PPU licensing to business partners and other B2B guests under Microsoft Entra B2B terms, so a per-seat licence can still apply once those viewers are provisioned as named users. App-owns-data embedding is a separate option built for exactly the case where you don't want to license your customers individually, and it's worth checking which of the two fits before you assume per-seat pricing is off the table.

Microsoft Fabric F SKUs: What Per-Capacity Pricing Costs per Hour and per Month

Fabric capacity is billed by the hour for a SKU size, not per user. The rates below are indicative pay-as-you-go prices for Central US in USD, read on azure.microsoft.com on 23 September 2026. The monthly column is our own arithmetic at 730 hours.

To price any size, multiply the hourly rate by 730 (Microsoft Learn). That gives you a month of always-on capacity. Microsoft Learn says Azure bills F capacities "per second with a one-minute minimum" and that pricing is regional (Microsoft Learn), so check your own region before you trust these rows.

The number moves most when you reserve. At F64, pay-as-you-go runs $11.52 an hour, or $8,409.60 a month (Azure). A yearly reservation of the same capacity lists at $6.853 an hour, about $5,002.67 a month, which is roughly 41% below pay-as-you-go (Azure). The trade-off is commitment: you pay for that capacity whether it's busy or idle. We think reserving is the right call once a workload is steady, and the wrong one while you're still guessing how big it needs to be.

Notice what's missing from every line of that table. There's no user count.

A Fabric bill comes from two inputs: the SKU size and whether you commit. Reserving cuts roughly 41% off the pay-as-you-go rate (Azure). Under app-owns-data, how many people open the reports adds no licence charge, but it still bears on the SKU size, because their usage and concurrency drive the compute load.

Power BI Embedded a SKUs: The App-Owns-Data Cost Model

Power BI Embedded A SKUs are hourly, Power BI-only capacity bought through Azure for embedding analytics in your own application. The figures below are dated Central US indicative rates in USD, read on azure.microsoft.com on 23 September 2026. Your region and currency will move them.

A SKUs bill hourly and are computed to the second. Azure's page also says that when the service is paused "the embedded content will not load, and you will not be charged for the service."

That's useful. It isn't unique to A SKUs.

This is where we see the comparison between A and F SKUs most often go wrong. Microsoft Learn says F capacities are billed "per second with a one-minute minimum". It also says Fabric "lets you pause and resume your capacity" on an F SKU, and notes that "Resuming your capacity also resumes billing." So neither per-second billing nor pausing separates the two models. Three other things do: workload scope, commitment and, for viewers who sign in, licensing.

Scope: Learn states that "A and EM SKUs only support Power BI items," while F SKUs run every Fabric experience.

Commitment: only F capacities come "with the option of a yearly capacity reservation to save costs" (Microsoft Learn). That's the roughly 41% discount we worked through in the Fabric section.

Licensing: for embed for your organization and Microsoft 365 apps, Learn's Fabric licensing documentation says "F SKUs smaller than F64 and all A SKUs require each consuming user to have a Pro, Premium Per User (PPU), or individual trial license to view Power BI content." An A4 matches an F64's compute, but only the F64 lets free Power BI users view shared content. Under app-owns-data, neither needs an end-user licence.

Our view is that A SKUs and F SKUs are both legitimate pay-as-you-go paths for customer-facing, app-owns-data embedding. Choose an A SKU because you want Power BI alone with no commitment. Don't choose one because you think it's the only capacity you can pause.

Do Your Viewers Need a Licence? The F64 Rule, in Full

It depends on your embedding scenario first, and on your SKU only when your viewers sign in. Microsoft attaches the F64 rule to a specific audience, and the sentence names that audience before it mentions capacity size (Microsoft Learn).

Here's the rule in full, from Learn's embedded capacity page (read 23 September 2026):

"For Embedding in Microsoft 365 apps such as Sharepoint online and PowerPoint, and Embedding for your organization (user owns data) customers: Only SKUs equivalent to a F64 or higher, allow free Power BI users to consume Power BI apps and shared content in Power BI service. If you have a SKU smaller than F64, then a Pro license or Premium Per User (PPU) is required for each user who will view the embedded content." (Microsoft Learn)

"Equivalent to a F64" doesn't take in an A4, even though Learn's equivalence table pairs the two. The same page's SKU table says: "Only P SKUs and F64 or higher, allow free Power BI users to consume Power BI apps and shared content in Power BI service. If you have a SKU smaller than F64 or an A SKU, then a Pro license or Premium Per User (PPU) is required for each user who will view the embedded content."

The same page gives the other branch: "For Embedding for your customers (app owns data) customers, there are no licensing requirements for the end users." That sentence doesn't name a capacity size, so it applies whether you run an A1 or an F256. Learn's embedded analytics overview draws the same line in its comparison table. Embed for your customers is "Aimed at external users" and "App users don't need a license"; embed for your organization is "Aimed at internal users" and "Each app user needs a Power BI license". Two pages, one rule.

Place your deployment in one branch before you open a price table:

• Your viewers are colleagues signing in with Power BI credentials (embed for your organization, or Microsoft 365 apps such as SharePoint Online and PowerPoint) (Microsoft Learn). On any A SKU, and on F capacity below F64, every viewer needs a Pro or PPU licence. On an F64-or-larger F SKU or a P SKU, free Power BI users can consume shared content.
• Your viewers are your own customers, served through your app (app-owns-data). End users need no licence on any SKU, so the F64 licensing threshold doesn't apply to you, but their usage and concurrency still size the capacity you buy.

We've seen the F64 sentence published without its opening clause far more often than with it. Read that way, the rule seems to require a SaaS team to buy an F64, which it doesn't.

If your deployment is in the second branch, your viewers add no per-user licence charge, but they still size the capacity, because their usage and concurrency drive its compute load. You're left with a capacity-sizing question, not a licence count.

What Happened to Power BI Premium P SKUs?

Power BI Premium per capacity SKUs were removed from the purchase flow on 1 July 2024, and existing customers without an Enterprise Agreement (EA) could renew only until 1 February 2025 (Microsoft Power BI blog).

That dates a lot of the internet. Search "Power BI Premium pricing" and much of what comes back still quotes P1, P2 and P3 monthly figures for a product you can't buy. Microsoft's footnotes still say "P1 and above" when describing per-capacity capability, which keeps the old names circulating. Learn's equivalence table now maps P1 to F64, and we treat F SKUs as the only per-capacity path worth modelling.

Our view is blunt. Any estimate built on P-SKU pricing budgets against a product that's gone, so check the date on every Power BI price you read, including ours.

Worked Example: Pricing Power BI When the Viewers Are Your Customers

Take a B2B product embedding reports for 400 customer users across dozens of tenants, under app-owns-data. What does each viewer cost in licences? Nothing. Microsoft attaches no licence to end users in that scenario. What they cost in capacity is a separate question, and the answer depends on how many are active at once and how heavy their queries are.

At Pro list ($14.00 per user/month, microsoft.com, checked 23 September 2026), those 400 people would be $5,600 a month. Under app-owns-data that licence line is zero, but the 400 users still size the capacity line, so size it before you compare ways of buying it.

Microsoft's capacity page says "Capacity is a distinct pool of resources. The size of the capacity determines the amount of computation power available." Its capacity planning guide says "The capacity you need depends on several parameters, some of which are hard to predict," including "The number and complexity of required queries" and "The hourly distribution of your application usage."

The guide gives no figure for how many viewers a SKU carries. It asks for a load test instead: "test with up to a few dozen concurrent simulated users and extrapolate for higher concurrent loads." If the measured CPU is "approaching the capacity limit," it says to consider a larger SKU. For these 400 users, that test is what picks the size.

Once the load test gives you a size, hold it fixed. Microsoft's capacity equivalence table (read 23 September 2026) lists F64 at 64 capacity units and 8 Power BI v-cores alongside P1/A4, and F8 alongside EM1/A1. The pairing is compute only: Learn's Fabric licensing page offers it "for comparing compute capacity, not as a statement of functional or licensing equivalence." Under app-owns-data that difference doesn't touch these 400 users. That gives three purchasing paths at each size:

Indicative Central US list rates in USD, read on azure.microsoft.com 23 September 2026; monthly figures assume 730 hours. Your region and agreement will differ.

At the F64/A4 size, a one-year reservation is the cheapest path if the capacity runs around the clock. A4 costs more per hour but carries no commitment and covers Power BI alone. F64 pay-as-you-go is the most expensive line, and it only earns its keep if you want other Fabric workloads on the same capacity.

At the small size, an A1 at roughly $736 a month (Azure) is a perfectly legitimate answer for a modest workload. We'd rather a team start at the size its query load actually needs and move up than budget an F64 because a licensing sentence mentioned it.

So the bill for customer-facing embedding is a capacity line, not a seat line — and the size of that line is set by how those viewers use the reports.

Size the capacity to your workload first, and your viewers are part of that workload: their concurrent use and query load are what the load test measures. Then choose A pay-as-you-go, F pay-as-you-go or F reserved at that size. Sizing and purchasing are separate decisions, and conflating them is how teams end up budgeting an F64 they never needed.

What the List Price Does Not Include

For a customer-facing deployment, the SKU is only part of the total you take to finance.

Microsoft documents Power BI Embedded and app-owns-data embedding explicitly, so this isn't a feature gap. It's about where the engineering sits. Under app-owns-data, your backend authenticates to the service and issues an embed token per tenant session, so your team owns the code that decides who sees what.

That code carries more weight than it looks. Tenant identity has to reach every query, with row-level security (RLS) enforced below the presentation layer, at the data, semantic, query or governed runtime layer. Metric definitions drift per tenant once enterprise customers want their own version of "active user." New dashboards need environment-aware promotion from dev to production, customer by customer. And when someone disputes a number, you have to show which definition and which permissions produced that response.

A common failure mode looks like this: one token minted with the wrong tenant claim, and a dashboard answers from another customer's rows.

We built Embeddable to sit under that work. Developers own the experience in code, while the platform handles row-level security, environments and per-tenant promotion and short-lived scoped embed tokens. Our pricing is public, and we've covered how Embeddable and Power BI differ on embedding architecture and multi-tenancy and how embedded analytics vendors price against each other separately.

Whichever cost model you land on, the list price is only part of the total, because governed multi-tenant delivery sits on top of every SKU.

Related Reading

• Embeddable vs Power BI
• Embedded Analytics Pricing and Benefit Comparison
• Power BI Embedded vs Looker Embedded
• Customer Facing Analytics
• Power BI vs Tableau