Two people can read the same Fabric Planning documentation and walk away with opposite numbers in their heads. Some read the pricing as seat licensing in capacity-unit clothing: a Planner commits 58% of an F2 (the smallest Fabric capacity you can buy) for a month, whether that person works one minute or three hundred hours. Others expect a consumption meter, where the bill climbs while people work and drops when they stop. Both are half right, which is the tell that this pricing model needs a plain explanation.
This piece is my attempt to put it in one place, cleanly. Microsoft published the billing model in June 2026, ahead of anticipated general availability in July 2026, so the mechanics are on the record. What follows reflects the published preview terms, and I will update this piece if GA moves any of them. I am saving the sizing method and my opinions for Part 2.
One naming note before we start. Microsoft’s product name is Planning in Microsoft Fabric IQ, most of us say Fabric Planning, and I have seen it called Microsoft Plan in the wild. One product (the engine is built by Lumel), one pricing model, whichever name you heard.
The short answer: how Fabric Planning pricing works
Fabric Planning uses session pricing, a third model that sits between per-seat licensing and pay-per-use. Each user’s role holds a slice of your Fabric capacity for 30 days at a time, and a dormant month costs nothing. Three costs draw from one Fabric capacity: the people (priced by role), the overhead (the database and processing underneath), and the automation jobs. The session is the billing unit, and it exists only when someone shows up. Everything below is the detail.
Start with the roles
Every user lands in one of three roles, and the roles form a ladder. Each tier includes everything below it.
Viewer is read-only: open the plan, sort, filter, bookmark. Executives and anyone who consumes the result.
Stakeholders enter data. They write back numbers, create scenarios, approve, and comment. They work inside the model’s structure without changing it: they can enter numbers, but they cannot alter the model itself. Department heads, budget owners, and every bottom-up contributor live here.
Planner is in edit mode: build models, configure planning logic and rules, administer security and permissions. Your FP&A team, and almost nobody else.
You do not assign these roles up front. Everyone opens as a Viewer, and actions upgrade the role: enter a number and the system makes you a Stakeholder, touch the model and you are a Planner. Anyone holding multiple roles in the same capacity is billed once, at the highest role. You do not assign the cost; your users’ actions do. Governance is about controlling who can take which action. The full capability list sits on the roles page at fabricplanning.io/resources/roles.
Figure 1. The role ladder: who each role is, what each can do, the sustained CU each holds, and what that prices out to per active month at US list rates, all drawing from one Fabric capacity.
Cost One: your people, priced by role and session
The unit Microsoft prices in is the capacity unit, CU. Each role, while active, holds a sustained slice of your Fabric capacity:
Sustained means held: a continuous slice of capacity for the length of the session, like a reserved seat. Microsoft counts a session as 730 hours, an average month. The rates above come from Microsoft’s preview session materials and product-team confirmations; the billing post defines the model and publishes no rates.
Microsoft publishes no dollar price per role. It does publish dollar prices for capacity, so you can derive what a role costs: at US pay-as-you-go list rates, a Planner’s slice prices out ~ $152/$90 (PAYG/Reservation), a Stakeholder near ~$30/$18 (PAYG/Reservation), a Viewer under $7/$4 (PAYG/Reservation) for an active month.
Those three numbers are the per-person economics of the whole product, and the gap between $7, $30 and $150 is who is creating or editing the Planning Artifact vs entering data/comments/simulations vs someone who is only viewing.
How the 30-day session works
Now the session, because it settles the confusion this piece opened with. A session starts when a user opens or meaningfully engages with a planning item, and once it starts, its full 30 days are committed. The two readings from the top describe the same mechanics from different ends. Within an active month it behaves like a seat: the Planner’s slice is held for the window whether the work took a minute or a month, and closing the session early refunds nothing. Across the year it behaves like consumption: the off-season is free because dormant months never open a session. The windows chain by engagement, too: when one ends, the next touch opens the next one. So a Planner who works every month pays for every month they work, about $150 at list, and a user who goes quiet opens nothing until they return.
Two more mechanics matter. An upgrade mid-window (a Stakeholder who touches the model, say) opens a fresh 30-day window at the higher role from that day, and the lower role’s window stops accruing. A downgrade does the opposite of what people hope: the open window runs to its end at the higher rate. Both mechanics come from direct product-team confirmation, since the billing post does not spell them out. Activating a user is a 30-day decision. Know that going in, and it never surprises you.
Cost Two: the overhead
Every planning system I have deployed had two cost lines. The software was one. The other was everything underneath it: hosting, compute, storage, the database the system ran on. Fabric Planning has the same second line, and here that second line is your Fabric capacity.
The plan item’s data lives in OneLake. The moment a number is committed, it writes back to a SQL table in Fabric. The processing behind refreshes, calculations, and writeback draws CU from the same capacity your roles draw from. Microsoft’s billing post covers this in one line: planning “runs on Fabric Capacity, consumes existing Fabric CUs,” one unified pricing model in their words. It does not itemize the overhead further. So the honest way to carry it: the overhead is real, it lands on capacity you already own rather than on a separate invoice, and nobody outside Microsoft can hand you its exact size for your workload today. In preview you can already watch planning’s draw in the Microsoft Fabric Capacity Metrics app, so a pilot can measure the overhead directly.
Until GA hardens the numbers, treat overhead as headroom. The calculator I built at fabricplanning.io models it as a buffer percentage you set yourself. I default to 30%: an assumption, and one you can adjust. A pilot on your own data is the only measurement that counts.
Cost Three: the automation jobs
The third line covers work no human is present for: data syncs across models, updates to connected planning sheets, the scheduled machinery. These run as jobs, and Microsoft bills them at a fixed cost per successful job. As I understand it today, each job draws about 2 CU-hours from the same capacity everything else uses (call it thirty-odd cents a job at the same US list rate, derived); treat that figure as informational until GA, because the preview materials it comes from were labeled illustrative. The wording is per successful job, so a failed run should not bill; I have not seen that tested.
The number nobody can give you yet is job count. How many jobs does a real deployment run in a month? It depends on how much syncing your model does, and the only good answer comes from counting them in a pilot. Ask that question early: it is the one line of the three your org chart cannot tell you.
One capacity pays for all three
Everything above lands on one meter: a Fabric capacity, sold as F-SKUs. (The F number is the CU total, so F2 = 2 CU, F4 = 4, on up through F64, F128, and beyond.) The capacity is the invoice. There is no separate planning bill and no license key. You buy CU; roles, overhead, and jobs draw from it; whatever planning does not use stays available to your notebooks, pipelines, and Power BI.
Capacity prices are public. At Microsoft’s US pay-as-you-go list rates:
Two notes on buying capacity. Reserved capacity bills every month whether planning runs or sleeps, at a lower rate, so a free dormant month shows up as freed headroom rather than a smaller invoice; pay-as-you-go costs more per CU and can scale down between cycles, which is where the off-season saving becomes cash. And if you already run Fabric, planning is a slice added to your existing peak, not a second capacity to buy alongside it.
The fine print that moves
Two facts to check before you plan a deployment, because both keep changing. Regions: a meaningful list of Azure regions does not support Fabric Planning yet (East US and East US 2 among them as of this writing), so check Microsoft’s live list for your region. And AI: whether Copilot draws from the same CU pool or bills separately has not been published (a polite way of saying nobody has told me yet). When Microsoft speaks, this paragraph changes.
The questions I keep getting about Fabric Planning pricing
Someone opened a plan just to look. What did that cost?
A Viewer session: 0.05 CU held for 30 days, under $7 at US list rates. The peek is cheap. The upgrade is what to govern, because entering one number turns that Viewer into a roughly $30 Stakeholder window, and touching the model opens a roughly $150 Planner window. (Microsoft’s wording, opens or meaningfully engages, leaves the bare peek slightly ambiguous; I treat any open as billable until told otherwise.)
I’m a Stakeholder at 0.23 CU (~$30/$18 PAYG/Reserved). Can I do unlimited stakeholder things?
No cap. Within the 30-day session the role charge is fixed no matter how much you do, dozens of PowerTables, a hundred scenarios, thousands of edits, and the rate doesn’t move. What scales with usage is the overhead (Cost two): the compute underneath draws from the Fabric capacity you already own. The seat is fixed; the compute beneath it flexes. Whatever role you’re in, that one charge covers every artifact and unlimited activity across Planning Sheets, PowerTable Sheets, and the Intelligence (visual) Sheets.
Can we lower a bill by closing sessions or downgrading roles?
The window runs out either way. Cost control happens before the click.
Do users also need Power BI or Fabric per-user licenses on top of this?
The billing post prices planning roles and is silent on per-user licenses. Fabric’s standard workspace access rules still apply (below an F64, viewing Power BI content generally requires a per-user license; at F64 and above, free users can view). How that intersects with plan items is not yet documented; confirm it with Microsoft for your tenant before rollout, and I will update this answer when it is written down.
We run more than one capacity. Does the same user bill on both?
Sessions key on the user plus the capacity, so yes: one user active on two capacities opens two sessions, one on each. Confirmed by the product team.
Can a small team run this on the smallest SKU?
One Planner alone holds 58% of an F2’s two CU, the number from the top of this piece. Add a few Stakeholders and an overhead buffer and the F2 is oversubscribed. F4 is the practical floor.
Will planning starve the capacity our reports run on?
They share the pool, so size for the planning peak on top of your existing peak.
Where this leaves you
That is the model. Three roles priced by session, overhead on capacity you own, jobs billed per successful run, one F-SKU paying for all of it. What your number comes to depends on who does what in your planning cycle, and that is a sizing exercise: put your own user mix into the calculator at fabricplanning.io/calculator and it recommends an F-SKU with the mechanics above built in. Part 2 walks a real 2,200-person organization through the math in dollars. My opinion of this pricing model is a short one, and it is coming in Part 2.
The meter is readable. What it reads is your org chart.
Fabric Planning is in preview until GA. Everything here reflects Microsoft’s published billing post and product documentation as of July 2026, plus direct confirmations from the product team where noted; preview terms move, so verify with Microsoft before committing budget. Per-role dollar figures are derived from Microsoft’s published US pay-as-you-go capacity list prices, which vary by region; Microsoft publishes no per-role dollar rate. Buffers and scenarios are planning assumptions, not Microsoft-published sizing. fabricplanning.io, including the calculator and the roles page, is my own companion site for this publication; everything there is free to use.
Sources: Billing for Microsoft Fabric Planning (Preview), Microsoft Fabric Updates Blog, June 2026. Introducing Planning in Microsoft Fabric IQ, Microsoft Fabric Updates Blog. Microsoft Fabric capacity pricing, Azure. Role rates per Microsoft’s preview session materials, with session mechanics confirmed directly by the product team (July 2026), tracked in the Fabric Planning Knowledge Base. fabricplanning.io/calculator and fabricplanning.io/resources/roles.