Planning where your people already work.
Microsoft Fabric Planning puts planning in a separate Fabric item. accoTOOL puts it inside the Power BI report your finance and business users already open every day.
accoTOOL adds planning, master data and commenting to Power BI as visuals approved on AppSource, writing every entry to your own SQL database, from $6.7 per user per month.
Fabric Planning, Lumel and Inforiver
Planning in Microsoft Fabric is co-engineered by Microsoft and Lumel, the company behind Inforiver, the planning and reporting visual for Power BI. If you are comparing accoTOOL with Inforiver, this page is the comparison: Fabric Planning is where that technology now runs as a native Fabric workload.
The difference in approach stays the same. Fabric Planning and Inforiver bring a planning application to your data. accoTOOL adds focused writeback visuals for planning, master data and comments to the Power BI reports you already have, and writes every entry to your own Azure SQL, Fabric or on-premise SQL Server database.
The honest side by side
Both write back. The difference is where the planning happens, and who can actually use it.
Planning where your people already work, in the Power BI report, not in a separate Fabric item.
No new place to go
Budget owners plan in the report they already know. No separate item, no new tool to learn, no context switch.
Transaction Keys, natively
Every entry writes back against its transaction key, traceable line by line, straight into your own database.
From $6.7 per user/month
Every feature, free reporting users, no capacity upgrade required to let the business plan.
Fabric Planning isn't multi-dimensional, so you duplicate
A Fabric planning sheet holds one slice. Every additional combination of dimensions needs its own sheet, the same trap Excel put finance in, just hosted somewhere new.
And it doesn't stop at the grid. Each sheet writes back to its own table, so those 2,000 sheets become 2,000 separate writeback tables, none of which share a transaction key.
One sheet per dimension combination, one writeback table per sheet. Consolidating them means stitching thousands of unkeyed tables back together every cycle, and re-doing it whenever a project or cost center is added. Reconciliation chaos, by construction.
One multi-dimensional visual, one keyed writeback table. Slicers pick the org level and the project; the grid follows. 2,000 combinations are 2,000 rows, not 2,000 artefacts to maintain, and nothing to reconsolidate.
A budget number is only as good as the key behind it
Most planning tools only store what you typed. A transaction key stores what you meant—the complete coordinate of every figure—allowing your plan to behave like data rather than a static snapshot. This creates a coherent and robust data model that aligns seamlessly with your actuals from the data warehouse. No additional processes are required, and your data remains valid, usable, and consistent at all times.
What a transaction key actually is
A transaction key is the unique combination of dimensions that identifies a single planned amount: entity, cost center, account, product, project, customer, scenario, version, period, and the user and timestamp that produced it. Instead of writing back a lonely value into a cell, accoTOOL writes back a fully-qualified row. The number carries its own address. That single design choice is what separates a budget you can report on from a budget you can only look at.
Why it matters for the structure of your plan
Budgets are rarely built at the level they are consumed. Sales plans by customer, HR plans by employee, operations plan by project, finance consolidates all of it into the P&L. When every entry is keyed, aggregation is a query, not a rebuild. Add a cost center mid-cycle and it simply appears; restructure a hierarchy and the history follows the key rather than the row position it happened to occupy. Plans stop being fragile spreadsheets held together by cell references and start behaving like a dimensional model, the same one your actuals already live in.
"Marketing, Q3, 480." Who changed it, from what, under which assumption, against which product line? Reconciliation becomes archaeology, and variance analysis stops at the department level.
Every 480 is a row: entity, cost center, account, campaign, scenario, version, period, author, timestamp. Variance drills to the driver, and last year's plan is queryable evidence for this year's.
Context becomes an asset, not a memory
Keys are also where the qualitative layer attaches. A comment, an assumption, an approval or a rejected scenario can be pinned to the exact same coordinate as the number it explains. Next cycle, the question "why did we plan 12% growth in the Nordics?" has an answer that lives in the model rather than in an inbox. Over two or three cycles this accumulates into forecast-accuracy history you can actually measure, bias by planner, by cost center, by product, which is the foundation any AI-assisted forecasting is going to need anyway.
Why this is decisive in a Power BI budgeting cycle
Power BI is dimensional by nature: your semantic model already knows the keys your actuals use. If plan data arrives keyed the same way, budget and actual meet in one model with no bridge tables, no mapping sheet, no monthly reconciliation ritual. Slicers work across both. Time intelligence works across both. Row-level security applies to plan data the moment it is written, because the key carries the entity. And because accoTOOL writes back to your own database at that grain, the audit trail is a table you own, every version retained, every change attributable, restatements handled by adding a version rather than overwriting a cell.
When Microsoft’s own option is the right choice
Fabric Planning is a good product, and for some teams it is the right answer. Here is how we would decide, honestly.
How Fabric Planning is priced
Fabric Planning has no per-seat licence. It consumes capacity units (CU) from your Fabric capacity, the same pool that runs Power BI and your other Fabric workloads. Each user is metered by role in a 30-day session: once a session starts, it meters for the full 730 hours, whether the user works in the plan once or every day. Automation jobs such as data syncs are billed per job. Billing started when the product reached general availability in 2026.
Microsoft publishes the CU rate per role, not a dollar price. Converted at list prices for Fabric capacity in US regions and in West Europe, one 30-day session costs approximately:
| Role | CU per hour | CU per session (730 h) | US pay-as-you-go | US reserved | West Europe pay-as-you-go | West Europe reserved |
|---|---|---|---|---|---|---|
| Planner (author, modeller and admin) | 1.16 CU | 847 CU | ~$152 | ~$90 | ~€160 | ~€95 |
| Stakeholder (enters data, approves, comments, writes back) | 0.23 CU | 168 CU | ~$30 | ~$18 | ~€32 | ~€19 |
| Viewer (views and interacts locally) | 0.05 CU | 37 CU | ~$7 | ~$4 | ~€7 | ~€4 |
A user is billed once per capacity, at their highest role in that session. Opening a plan in reading view starts a Viewer session. Capacity prices differ by region; check the price list for yours.
Example: 200 budget owners and 10 planners
The Fabric Planning capacity estimator recommends adding 30% on top of the planning sessions for the other Fabric resources a plan uses. For a month in which all users are active:
| Fabric Planning (US) | West Europe | |
|---|---|---|
| Planning sessions (10 × 1.16 + 200 × 0.23) | 57.6 CU per hour | 57.6 CU per hour |
| +30% for Fabric SQL, OneLake and other Fabric resources | ~75 CU per hour | ~75 CU per hour; needs at least an F128 if dedicated |
| Cost of that CU, pay-as-you-go | ~$9,840 per month; reserved ~$5,850 | ~€10,340 per month; reserved ~€6,150 |
| A dedicated F128 capacity | ~$16,800 per month; reserved ~$10,000 | ~€17,680 per month; reserved ~€10,510 |
| accoTOOL, 210 writeback users | $1,680 per month ($8 per user) | Same price (USD); no Fabric capacity required; report viewers free |
If the plan shares an existing capacity, you pay for the CU it uses, as long as there is headroom during the budget cycle. If it needs its own capacity, you pay for the whole capacity size. accoTOOL is billed per writeback user per month and runs on your existing SQL database.
What to check before you choose Fabric Planning
- Capacity headroom: one Planner session uses 1.16 CU around the clock, more than half of an F2 capacity. Budget cycles add load to the same capacity as your reports, so size for the busiest weeks.
- Session length: a session meters for 30 days once it starts, so occasional users cost a full month each time they take part.
- Viewer licences: below F64, people who view Power BI content generally still need a Power BI Pro or Premium Per User licence.
- Other Fabric usage: Fabric SQL, OneLake, Power BI XMLA operations and other Fabric items are metered on top of the planning sessions.
- Product maturity: Fabric Planning was introduced in March 2026. Check that the features you need are generally available, and run a pilot on a real budget cycle before you commit.
- Regional availability: confirm that Planning is available in the Fabric region your capacity runs in, and use your region’s capacity prices.
Sources: Microsoft Learn: billing and usage for planning in Fabric; Microsoft Fabric Updates Blog: Billing for Microsoft Fabric Planning; role rates and the 30% guideline from the Fabric Planning capacity estimator; dollar estimates from the Fabric Planning newsletter, calculated at list prices of about $0.18 per CU-hour pay-as-you-go and $0.107 reserved in US regions, and about €0.189 and €0.113 in West Europe (F64 at €8,840 and €5,257 per month, Agilytic, July 2026), which vary by region. Checked October 2026. Verify current terms with Microsoft.