Fabric Planning or Jedox: which tool fits which plan

Late August, and the 2027 budget round is about to start. IT reports that Planning in Microsoft Fabric has been generally available for a few weeks and runs on the capacity the company already pays for Power BI. The same day, a Jedox partner's proposal arrives, with balance sheet planning, workforce planning and consolidation. The CFO now has two offers that are both called «planning» and no basis for comparing them. The answer is uncomfortable for both vendors: it depends on what the plan has to calculate.

What Planning in Fabric IQ can do today

Microsoft announced Planning at FabCon in March 2026, co-engineered with Lumel, the company behind the Power BI extensions Inforiver and ValQ. It has been generally available since 28 July and billed since 1 August. It rests on four building blocks: planning sheets for budgets, forecasts, scenarios and rolling forecasts, with versions, comments and approval flows; PowerTable for master and reference data that today lives in Excel lists; intelligence sheets for variance reporting; and planning cubes, in which a value is entered at an aggregated level and allocated downwards by a driver such as prior-year revenue.

The decisive difference from a separate planning system is where the planning happens. Fabric Planning works directly on the semantic model that already feeds the actuals reports, and writes plan values back into a SQL database in Fabric. Revenue in the plan is therefore, by definition, the same revenue as in the monthly report. Egle and Keimer described the principle for Swiss companies back in 2018: a single point of truth for all ERP, plan and forecast data makes manual or Excel-based reconciliation largely redundant (Egle/Keimer 2018, p. 24). With Fabric Planning, Microsoft customers can reach that point for the first time without an add-on product.

Billing is not per licence but per role and 30-day session, drawn from the Fabric capacity: planners build models, stakeholders enter and approve, viewers read. Cost therefore follows the number of budget owners, not the headcount. A Fabric capacity is required; Power BI Pro or Premium Per User on their own will not do.

Where Fabric Planning is enough

Fabric Planning is strong where the plan needs the same definitions as the report. The cost centre budget every department head enters in October. The sales plan by customer and product group, spread by prior year and corrected by hand where a key account drops away. The headcount plan at FTE level. The rolling forecast, in which the statistical proposal is the starting value and the controller only explains the deviations. And scenarios for the management team, for example a price two per cent below plan.

In all of these cases, the most expensive part of a traditional budget round disappears: reconciling the planning system with the reporting system. No mapping table, no second chart of accounts, no export the day after approval. Plan versus actual sits in the same report, in the same notation, with prior year, actual and budget in the same order as in the monthly report. The planning sheets come from the Inforiver line and support scenario notation according to IBCS®; if your reports already follow it, there is nothing new to learn for planning.

The billing model also rewards a lean process. Langmann explains why planning in most companies produces a lot of effort and little satisfaction: missing tools, excessive planning depth and rounds of negotiation instead of clear top-down targets (Langmann 2019, p. 21 f.). How far this can be cut back is shown by a Swiss case in the volume edited by Keimer and Egle: with a top-down budget built on a handful of target figures, the number of people involved fell from around fifty to six (Keimer/Egle 2020, p. 259). In Fabric Planning, fewer budget owners translate directly into less capacity. That is a cost argument, and at the same time an argument for a better process.

One limit shows up even in simple plans. When we tried to spread a sales plan by prior year, the cells for new products stayed empty: no prior-year revenue means no weight, and the allocation stops. Microsoft now documents this as a rule – allocate only onto populated driver values. New products, new branches or new customers therefore need their own input row with their own logic. It can be solved, but it is modelling work that someone has to do and maintain.

Where Jedox and other EPM tools are better

Dedicated planning systems such as Jedox, Lucanet, IBM Planning Analytics, Board or, for large organisations, Anaplan and Pigment are better where the plan needs its own financial logic that does not exist in the actuals model. We see four situations again and again.

The first is integrated financial planning. The bank wants a planned balance sheet and a cash forecast with the budget, and the board asks what payment terms ten days longer would do to the cash position in December. That requires P&L, balance sheet and cash flow to be linked so that a change in revenue flows through receivables and payment terms all the way into liquidity. Jedox ships ready-made models for balance sheet, P&L, cash flow, sales, workforce and cost centres; Lucanet has the same strength. In Fabric Planning, you build this logic yourself with formula rows, and you maintain it yourself.

The second is the group. Several entities in several currencies, intercompany deliveries that have to be eliminated, minority interests: this is the core business of Jedox, Lucanet or Tagetik. For Fabric Planning, Microsoft documents neither currency translation nor intercompany elimination. There is also a practical limit that quickly matters in groups and portfolio companies: guest users from another Microsoft tenant are not supported. The fiduciary who looks after a subsidiary, or the investor who wants to take part in planning, cannot work in Fabric Planning unless they are set up in your own tenant.

The third is rule-heavy models. Per-head workforce planning with pay bands, start dates, social charges and a thirteenth monthly salary, or production planning via bills of materials, needs a rules engine that calculates across many dimensions. Jedox and IBM Planning Analytics were built for this. Fabric Planning has formulas and automations, but with documented limits, such as two levels for chained triggers and 1.2 million cells per write-back.

The fourth is maturity. Jedox has been on the market for years, has an Excel add-in that finance teams value, and partners in Switzerland with ready-made templates. Fabric Planning has been generally available for a few weeks. BARC's user reviews are a useful counterweight to vendor marketing, though: the same users who praise Jedox for its flexibility and closeness to Excel name the complexity of implementation and performance with large data volumes as weaknesses (BARC 2026). A dedicated system solves the financial logic, but it brings a second model that has to be reconciled with the actuals model.

Fabric Planning and dedicated EPM tools compared, as of September 2026
Criterion	Planning in Fabric IQ	Jedox and other EPM tools
Plan on the same definitions as actuals	Built in: plans on the semantic model	Via interface and mapping
Cost centre, sales and headcount plans	Well suited	Well suited
P&L, balance sheet and cash flow linked	Build and maintain yourself	Templates and financial logic included
Multiple entities, currencies, elimination	Not documented	Built in (Jedox, Lucanet, Tagetik)
Rule-heavy models (per-head workforce, BOMs)	Limits on automation and write-back	Rules engine across many dimensions
External planners (fiduciary, investor)	No guest users from another tenant	Own user management
Prerequisite and cost logic	Fabric capacity, billed by role	Own platform, own licence
Maturity	Generally available since July 2026	Established for years, partners with templates

Our own assessment based on Microsoft documentation (Planning overview, known limitations, billing) and vendor information; not a complete feature list. The table shows where the logic lives, not which tool is better.

The plan starts with the decision it has to carry

The tool question can only be answered once it is clear what the plan is for. It is the same purpose question we start every report with: what should these numbers say, and what are they meant to achieve? A budget that commits department heads to their costs and lets the management team check plan versus actual every month serves a different purpose from a budget the bank requires before renewing the credit line. Our framework "From decision to KPI" applies to planning in exactly the same way: first the decision, then the planning figure, then the tool.

In practice, four questions separate the cases reliably:

Does the plan need to produce a balance sheet and a cash flow, or is a P&L by cost centre, customer and product enough?
How many entities, currencies and intercompany charges have to be combined?
Who takes part in planning, and are they all in your own Microsoft tenant?
Are the actuals already in a clean semantic model that reconciles with the books?

No to the first two questions and yes to the last two: then Fabric Planning is in most cases the leaner solution. A yes to the first or second question moves the decision towards a dedicated planning system. A no to the fourth question moves it back in time, because planning on a model that does not match the books means planning on sand. As long as the plan speaks the same language as the report, it belongs on the data model. As soon as it has to tie together P&L, balance sheet and cash flow, it belongs in a planning system.

Often the answer is a combination: Jedox or Lucanet for integrated financial planning and consolidation, Fabric for the reporting on top, with plan values as a separate source in the model. That works well as long as it is clear which system holds the truth for which number. And for many SMEs, Excel remains for the first input round, because planning is negotiation and negotiation happens in spreadsheets. What should move out of Excel is the job of merging thirty files into one version.

From practice

At a wholesaler with two entities, I put budget input directly on the Power BI model: cost centres and sales regions, with write-back to the database and plan versus actual the day after approval. The first round went better than any Excel round before it. In November, the bank asked for a planned balance sheet and a cash forecast before renewing the credit line, and the model had not been built for that. I made the mistake at the start: I asked what the management team would decide with the plan, but not who else would read it. We then rebuilt the balance sheet logic in Excel next to the model, with payment terms and stock coverage as drivers, and set it up properly the following year. Since then, the question about every recipient of the plan comes up in the first conversation.

A principle from controlling practice helps with both tools. Dirk Fischer lists «simplicity before precision» as his tenth rule for successful controlling and warns against detailing plans further than the explanatory model behind them can carry (Fischer in Mehlfeld et al. 2018, p. 18). A plan at item level is built just as quickly in Fabric Planning as in Jedox. Whether anyone can justify it is not decided by the tool.

What you can do tomorrow

Take the documents from your last budget round and answer the four questions above. Count the people who actually enter or approve plan values, and check whether they all sit in your Microsoft tenant. With those answers you will know whether your plan needs its own financial logic or belongs on the model your reports already run on.

If you already have proposals on the table, a second opinion before signing is worth it. Our project review takes a few days at a fixed price and checks which decisions the plan has to carry, whether your actuals model is ready for it and which tool fits your planning; the result is a written second opinion with a recommendation. Once the build is agreed, a scoping sprint defines the target picture for plan and report together in two to three weeks.

Sources

Microsoft (2026): What is Planning in Fabric?; Known limitations in Planning; Planning in Fabric billing and pricing model; Create a multi-dimensional planning cube. Microsoft Learn, learn.microsoft.com/fabric/iq/plan.
Microsoft Fabric Blog (2026): Introducing Planning in Microsoft Fabric IQ: From historical data to forecasting the future. blog.fabric.microsoft.com.
Lumel (2026): Lumel enters into strategic first-party alliance with Microsoft to launch enterprise planning in Microsoft Fabric. Press release, 18 March 2026, lumel.com.
Jedox (2026): Planning in Power BI; Heyde AG: Jedox models (balance sheet, P&L, cash flow, sales, workforce, cost centres). jedox.com, heyde.ch.
BARC (2026): Jedox reviews. barc.com/de/review/jedox.
Egle, U., Keimer, I. (2018): Digitaler Wandel im Controlling. Schriften aus dem IFZ, vol. 37. Verlag IFZ, Lucerne University of Applied Sciences and Arts.
Keimer, I., Egle, U. (eds.) (2020): Die Digitalisierung der Controlling-Funktion. Springer Gabler.
Langmann, C. (2019): Digitalisierung im Controlling. Springer Gabler essentials.
Mehlfeld, T., Schneider, C., Stahl, K.-U., Wiener, A. (eds.) (2018): Reporting- und Business-Intelligence-Werkzeuge für den Controller – including Fischer, D.: Ten rules for controlling success.