Power BI Embedded Pricing Explained

Your Embedded budget needs two figures: the cost of running the reporting and the cost of building it into your product. Capacity is one part of that budget. Authentication, customer data separation, reports, refreshes and support define the project around it.

Use the worked example below to calculate a capacity allowance, then gather the scoping inputs before commissioning a build.

Which embedding and licensing model are you budgeting for?

For your customers, using app owns data: an Azure A-SKU or Fabric F-SKU can provide the capacity behind your application. End users need no individual Power BI licences. Production embedding needs purchased capacity; development trial tokens serve testing.

For your organisation, using user owns data: viewers sign in with their Power BI identity. A-SKUs and Fabric capacities below F64 require viewers to have Pro, PPU or an eligible trial. Qualifying F64 and higher capacities support free viewers. Check the content and workspace requirements too. Microsoft documents these embedding capacity and licensing distinctions.

Pro and PPU are per-user licences, so compare them with capacity against your chosen scenario and features. A large registered-user count alone does not establish which option costs less. Our web app embedding guide covers the architecture and authentication choices.

Azure A-SKUs and Fabric F-SKUs

Azure A-SKUs provide dedicated Power BI Embedded capacity. Microsoft quotes an hourly rate, computes usage to the second and bills hourly. Pausing stops the capacity charge; embedded reports will not load while it is paused. Confirm the selected region, currency, SKU and purchasing agreement on Microsoft's Power BI Embedded pricing page.

Fabric F-SKUs also support Power BI embedding and can run other Fabric workloads. Include those workloads when assessing shared capacity. Fabric can be paused, but Microsoft bills outstanding smoothed usage and cumulative overages at that point. Content can become unavailable. Read the Fabric pause and resume rules before modelling scheduled hours.

A Fabric reservation commits spend for a term against eligible capacity usage. Pausing a resource does not cancel that commitment. Compare reservation utilisation with pay-as-you-go after your operating pattern is measured; keep storage and networking separate.

If Copilot is part of the brief, its baseline is paid Fabric F2 or higher, or Premium P1 or higher, plus administrator and region requirements. An A-SKU or a Pro/PPU licence alone does not establish eligibility. Verify the specific experience and embedding scenario against Microsoft's Copilot requirements.

A checked, illustrative monthly capacity calculation

Illustration only. The £1.00 hourly rate below is fictional, not a Microsoft price, a SKU recommendation or a Turing quote. Replace it with a dated rate for your chosen capacity, region, currency and agreement.

Assume one pay-as-you-go A-SKU stays at the same size throughout a 31-day month. Compare continuous availability with a scheduled customer portal running for ten hours on each of 22 working days. Assume all viewing, refresh and start-up time fits inside the scheduled hours.

The £524.00 difference corresponds to 524 fewer hours of availability. Reports on the paused capacity cannot load outside the schedule. This compares two service windows; it does not establish a saving for a product that requires access at all times. Any additional active hours or changes in capacity size change the calculation.

These are partial capacity figures. Keep the rest of the budget visible:

Record unpriced items as to be confirmed, rather than £0. The complete monthly running total remains open until its recurring inputs are priced. Keep the one-off implementation quote separate from that total. Our published pricing distinguishes project work from ongoing care.

The inputs needed to scope your Embedded project

You can start with estimates and mark unknowns. A useful first brief covers:

An anonymised report screenshot or a short list of the decisions your customers need to make can help define the first release. Keep passwords, tokens and customer records out of the initial enquiry.

Validate capacity against the intended workload

Choose a test capacity against model and feature requirements, then measure your own reports under representative simultaneous use and refreshes. Microsoft's Embedded capacity planning guide sets out optimisation, minimum capacity checks, load assessment and monitoring for A-SKUs. Registered-user counts and the arithmetic above do not validate a tier.

Watch report load times, refresh completion, resource use and overload events. Fabric's smoothing and throttling policy is specific to Fabric and can delay or reject new operations. It should not be applied as a blanket performance promise for A-SKUs.

For commissioning, agree the checks that make the build acceptable: a user sees the correct customer's data, totals match agreed source records, refreshes meet the chosen window, and report performance meets the agreed load target. Document who monitors the capacity and who can change its size or schedule.

Turn the budget into a project scope

Start your Embedded project enquiry with the product, availability window, reports and estimated simultaneous use. The project choice stays editable, and you can say which inputs still need checking. We use the brief to agree the implementation scope and quote the work.

See our Power BI Embedded implementation scope for the product integration service. If you already have reports or capacity to assess, the Trusted Numbers Review describes the review deliverables and fee terms.