Power Apps and Power BI: the spend that doesn't look like spend

Ask an IT manager what Microsoft 365 costs and you get a number within a few percent. Ask what Power Platform costs and you get a pause. Not because the money is hidden — every euro of it is documented and itemised somewhere — but because it is itemised in four different places, on two different invoices, under names that don't obviously belong to the same product.

This is a teardown of that structure. Not a checklist of things to go turn off: an explanation of why the number is hard to assemble in the first place, and which part of it your existing reporting genuinely cannot see.

Four meters, and only two of them reach the bill you read

Per-user seats and capacity add-ons are bought through Microsoft 365 commerce, so they land on the invoice finance already receives. Pay-as-you-go meters and Fabric capacity are bought through an Azure subscription, so they land on a bill that in most organisations is owned by a different team and reconciled in a different month.

What /subscribedSkus can and can't tell you

The endpoint every licence tool is built on is deliberately narrow. The subscribedSku resource carries skuPartNumber, prepaidUnits, consumedUnits, capabilityStatus and the list of servicePlans. There is no price on it, no renewal date, no environment, and no consumption figure. It is an inventory of entitlements, not a bill — a distinction that matters more here than anywhere else in the tenant, because Power Platform is the one product family where the seat count and the invoice can diverge without either being wrong.

Two properties on that resource are worth reading carefully. The first is appliesTo, whose values are User and Company; only User-class SKUs are assignable. A capacity add-on is a tenant-level entitlement, so it appears as a row nobody is assigned to and no per-user report will ever attribute. The second is capabilityStatus, which distinguishes Enabled from Warning, Suspended and LockedOut — the states a lapsed trial passes through on its way to becoming a paid subscription nobody approved.

Trials are also why the SKU list can be startling on first inspection. If anyone in the tenant has signed up through the public Power Apps trial flow, Microsoft provisions a block of 10,000 free trial licences representing available capacity. They cost nothing. They also make the tenant look like it bought a fleet.

Premium is decided by the app, not by the purchase

This is the leak that produces the surprise. Nobody buys "premium". A maker builds an app, and the app's licensing designation is derived from what it touches. Standard connectors don't require special licensing; the features that flip an app to premium are, per Microsoft's own FAQ, premium connectors, Dataverse tables, on-premises data gateways and custom APIs. Model-driven apps are premium by default, because they use Dataverse.

So the purchasing decision is made in the maker portal, by someone who is solving a business problem, at the moment they pick SQL Server instead of SharePoint as a data source. Procurement isn't in that conversation. Two details make it stickier still: an app that had its premium connectors removed keeps the premium designation until it is republished, and apps grandfathered under the 2019 use-rights change still show as premium while continuing to run on Office-seeded licences.

The reason this matters in 2026 rather than eventually: the same FAQ states that from February 2027, areas where the requirement was applied leniently — managed environments, model-driven apps, apps used outside a Dynamics 365 context — require an appropriate licence, and users without one can't open the app. Every app currently running on leniency is a line item with a date on it.

Capacity is the meter that doesn't bill you until it blocks you

Dataverse storage behaves unlike anything else in the licensing estate, and the capacity documentation is worth reading in full. Four mechanics decide what it costs you:

• The default environment includes 3 GB database, 3 GB file and 1 GB log capacity. Everything above that draws on tenant entitlement.
• Every environment consumes 1 GB regardless of whether it has a database. Environment sprawl is storage spend even when the environments are empty.
• Trial, preview, support, developer and Teams environments don't count against capacity — which is exactly why they accumulate.
• Unused capacity flows one way only: database can offset log and file, log can offset file, and never the reverse.

The consequence is the interesting part. Exceeding capacity doesn't generate an invoice line; it generates a weekly email at 15% remaining, another at 5%, and then it blocks administrative operations. Creating an environment (minimum 1 GB free), copying one, restoring one, recovering one, converting a trial to paid — all unavailable when the required capacity type is short. The first symptom of Power Platform overspend is usually an ops ticket, not a bill.

The Azure half is the one you can actually chart

There is one genuinely good piece of news in this structure. When an environment is put on pay-as-you-go, a billing plan links it to an Azure subscription and creates a Power Platform account resource there. Usage charges for Power Apps, Power Automate, Dataverse and Power Platform requests appear under that resource on the Azure bill — which means they inherit resource groups, tags, and Azure Cost Management. Fabric capacity is the same story: F SKUs are purchased through Azure and billed per second with no commitment, unlike the P SKUs they replace, which sit on an Enterprise Agreement with a monthly commitment.

The half of Power Platform spend that feels least governed is, in practice, the half with the best cost tooling attached. It is simply attached to a portal that the person tracking Microsoft 365 licences never opens.

What this means for the monthly number

There is no single query that returns "what Power Platform costs us", and there won't be, because the four meters measure different things: seats, GB, app runs and capacity-seconds. What is achievable is knowing which of the four is moving. Seats and trial states come from the tenant's SKU inventory. Capacity and its overage warnings come from the Power Platform admin centre. Consumption comes from Azure Cost Management, filtered to the Power Platform account resource.

Three sources, watched monthly, is not elegant. It is, however, the honest shape of the product — and it beats the alternative, which is discovering the number when someone can no longer create an environment. GraphPaaS pulls the tenant's licence inventory and Azure spend into the same view precisely because those two halves are never on the same invoice.