Cubes Are Back - What Fabric IQ Planning Cubes Mean for Your Budgeting Process

If you've been in data long enough, the word "cube" does something to you. For some people it triggers warm memories of Analysis Services multidimensional models that ran a whole company's reporting off one well-tended structure. For others it triggers flashbacks to week-long processing jobs and MDX expressions that only one person in the building could read. Either way, you probably filed cubes under "things we moved on from" somewhere around the time tabular models and then Power BI took over.

Well. Microsoft Fabric IQ has a planning concept called cubes, and it's worth paying attention to, because it's not nostalgia. It's Microsoft acknowledging something that finance teams have known all along: for planning, budgeting, and forecasting, the multidimensional model never actually stopped being the right shape. It just stopped having a good home in the Microsoft stack.

The problem cubes are coming back to solve

Here's the thing analytics people sometimes forget. Reporting and planning are different workloads that happen to look similar.

Reporting is read-only. You take what happened, you slice it, you present it. Power BI and the tabular semantic model are genuinely excellent at this, and nothing about Fabric IQ changes that.

Planning is read-write. A budget owner opens next year's numbers, types a value into the intersection of "Queensland," "Q3," "Marketing," and "Salaries," and expects that number to be stored, spread down to months, rolled up to the national total, and visible to the CFO five minutes later. That intersection-of-dimensions structure, with write-back and aggregation logic built in, is a cube. It has always been a cube. Every serious planning tool on the market, whatever it calls its internal structures, is a cube engine wearing a nice interface.

And here's what we see in practically every Australian mid-market organisation we work with: the actual planning process lives in Excel. Not because anyone loves it, but because Excel is the only tool the budget owners have that lets them type numbers into a grid. So the "planning system" is forty spreadsheets emailed around every August, consolidated by one heroic finance analyst, with version control by filename and audit trail by memory. The reporting side got modernised. The planning side never did, or it got outsourced to a dedicated planning product with its own licensing, its own consultants, and its own copy of all your dimensional data.

That last point is the one that matters. If you bought a dedicated planning tool, you now maintain your organisational hierarchy, your chart of accounts, and your product dimensions in two places: once in your data platform, once in the planning tool. They drift. They always drift. And reconciling budget versus actuals across two systems that disagree about what the org structure looked like in March is a special kind of misery.

What a Fabric IQ cube actually is

Fabric IQ sits above the data layer in Fabric and works with business concepts - entities, relationships, semantics - rather than raw tables. Within its planning capability, the cube is the core structure: a multidimensional space defined by dimensions, holding the measures you plan against, at the intersections you care about.

The interesting part isn't the cube itself. Anyone who's touched TM1, Essbase, or Analysis Services multidimensional will recognise the concept in about four seconds. The interesting part is where it lives. The cube is built inside Fabric, next to your lakehouse and your semantic models, drawing on the same dimensional data your reporting already uses. Your actuals and your plan share a platform, a security model, and - this is the big one - the same definition of your dimensions.

That single-platform story is the entire pitch, in my view. Not any individual feature. The moment your planning structure and your reporting structure share dimensions natively, a whole category of reconciliation work simply stops existing. Budget versus actuals stops being an integration project and becomes a query.

Planning sheets then give business users the grid experience for entering and adjusting numbers, backed by the cube handling storage, spreading, and rollups. The budget owner still gets to type into cells, which after twenty years of trying to take Excel away from finance teams is the only approach that has ever worked. You don't beat the grid. You put something trustworthy underneath it.

Where I think this lands well, and where I'd be careful

The honest position first: Fabric IQ is new, and planning inside it is newer still. This is the part of Fabric where the paint is still wet. If your organisation runs a complex, high-stakes planning process - driver-based models across dozens of entities, workforce planning with award interpretation, long-range capital planning - the established planning platforms have a decade of depth that a new capability can't match yet. I'm not going to tell a listed company to rip out its planning tool this year, and you should be suspicious of anyone who does.

But there's a huge band of organisations below that level, and this is where it gets interesting. If your planning process is currently the forty-spreadsheets-and-a-hero pattern, the comparison isn't "Fabric IQ versus a mature planning platform." It's "Fabric IQ versus Excel chaos." That's a much easier bar to clear, and the economics are different too, because you may already be paying for Fabric capacity for your analytics. For the mid-market Australian companies we spend most of our time with through our Microsoft Fabric consulting practice, this is the segment I'd be watching closely.

A few specific things to be careful about, from watching planning implementations succeed and fail over the years:

Dimension governance becomes urgent, not optional. The shared-dimensions benefit only materialises if your dimensions are actually clean. If your product hierarchy is a mess in the lakehouse, the cube inherits the mess, and now budget owners are staring at it during planning season. A lot of organisations will discover their data quality problems the week the CFO starts using the numbers to allocate money. Do that discovery earlier, on purpose.

The cube design decisions are the same old decisions. Which dimensions, at what grain, with what spreading logic - these questions predate Fabric by decades, and getting them wrong is just as painful now. Planning at the wrong grain is the classic error: too fine and budget owners drown in cells they can't sensibly estimate, too coarse and the plan is useless for accountability. This is design work, and it's business design more than technical design.

Don't confuse the planning model with the reporting model. It's tempting, since they now live side by side, to make one giant structure serve both. Resist it. Planning cubes want fewer dimensions, coarser grain, and stable structures across a cycle. Reporting models want detail. Related, sharing dimensions, but not the same object.

What to actually do about it

If you're an Australian organisation with a painful planning process, here's the pragmatic play as I see it in mid-2026.

If you're already on Fabric, or heading there for analytics reasons, put Fabric IQ planning on your evaluation list for the next budget cycle - not this one. Run a shadow process: pick one department, build the cube, run their budget in parallel with the existing process, and compare the experience. A shadow cycle costs you a few weeks of effort and tells you more than any feature comparison document ever will.

If you're not on Fabric and planning pain is your main driver, the calculus is different, and honestly a dedicated planning tool might still be your answer. Fabric IQ planning makes sense as part of a platform decision, not as a point solution you adopt in isolation.

Either way, start on your dimensions now. Clean hierarchies, agreed definitions, one owner per dimension. That work pays off regardless of which tool you land on, and it's the work everyone defers until it blocks a go-live. We spend a lot of time on exactly this in our business intelligence engagements, and it is never wasted effort.

The cube spent fifteen years being unfashionable while nothing better arrived for the write-back planning workload. Microsoft putting it back at the centre of a planning capability isn't a step backwards. It's an admission that the industry took a long detour around a problem the cube had already solved. The detour is over. Just walk back onto the road carefully.