Back to Blog

Power BI Visual Calculations - When They Save You and When to Stick With Measures

May 5, 2026•9 min read•Michael Ridland

Running sums in Power BI used to be a small horror. You'd start with an idea like "show me cumulative sales by month" and end up writing a measure with CALCULATE, FILTER, and ALL gymnastics that someone copied off a forum three years ago. It worked, kind of. Then someone added a slicer and it stopped working. Then you debugged for an hour and patched it with TREATAS. Then someone else opened the model six months later and had no idea what was going on.

Visual calculations exist to put an end to this. They're DAX that runs on the visual, not on the model. The classic running sum becomes one line:

Running sum = RUNNINGSUM([Sales Amount])

That's it. No CALCULATE, no FILTER, no ALL. The visual already knows what's on its axes, and the calculation operates on that aggregated data. It's the kind of feature that makes you go "why didn't this exist five years ago" and then remember that Microsoft is gradually walking us out of DAX hell one feature at a time.

I've been using these on client work since they shipped to general availability, and I want to share what's actually working, what's not, and where you should still reach for a regular measure.

The mental model

The thing to get straight upfront is that visual calculations live on the visual, not in the model. This changes a few things.

A visual calculation can only see what's on the visual. If you want to reference a column or measure, it has to be present on the visual first. You can hide it after if you don't want users seeing it, but it has to be there. This is a feature, not a bug. It's what makes visual calculations simple.

Compared to measures, you're working with aggregated values rather than detail-level data. The visual matrix is what you're operating on. Each row of the matrix represents a combination of values for the rows and columns on the visual. Your visual calculation runs over those, not over the underlying fact table.

This means a lot of the filter context wrestling that defines normal DAX writing just doesn't happen. You don't need to worry about whether ALL clears the right filter, or whether USERELATIONSHIP is active, or whether your CALCULATE is doing what you think. The visual is doing the heavy lifting.

It also means visual calculations are usually faster than equivalent measures. They run on already-aggregated numbers, not on full table scans. For things like running totals and moving averages where the equivalent measure has to do real work, the performance difference can be dramatic.

What's actually useful

The templates Microsoft ships with visual calculations cover most of the common patterns I see clients struggle with:

  • Running sum - cumulative totals down a column
  • Moving average - rolling N-period averages
  • Percent of parent / percent of grand total - hierarchical share calculations
  • Versus previous / versus next / versus first / versus last - period-over-period comparisons
  • Average of children - aggregate up to a parent level

These are the classics. The ones where you used to write a 40-line measure with comments explaining what each variable did. Now they're one function call.

A real example. We were doing a sales analytics build for a mid-sized retailer. They wanted year-over-year comparisons at category level, but also at sub-category level when drilled in, and they wanted percent-of-parent at each level. Previously this would have been a full afternoon of DAX work with calculation groups, sample tables, and four or five intermediate measures. With visual calculations, the COLLAPSE function does percent-of-parent automatically based on whatever's in the matrix hierarchy. Built it in twenty minutes.

The PREVIOUS, NEXT, FIRST, and LAST functions are the other quiet wins. Comparing rows to other rows in a visual used to require ranking, offset measures, and a lot of swearing. Now it's a one-liner. PREVIOUS([Sales]) gives you the previous row's value. Done.

The Axis parameter is where the magic happens

Most visual calculations functions take an optional Axis parameter. This is what makes them work properly when your visual has both rows and columns.

By default, calculations evaluate row-by-row, top to bottom. If you've got a matrix with months down the side and product categories across the top, your running sum will run down each column independently. That's usually what you want.

But you can switch to columns and have the running sum work across instead. Or you can switch to a hierarchical axis that respects drill levels. This is where visual calculations stop being a convenience feature and start being properly powerful. The Axis parameter is what lets the same calculation behave correctly in different visual layouts.

The parameter pickers (CTRL+SPACE) make this discoverable. When you're in the formula bar and you hit space after a function name that has an Axis parameter, you get a dropdown of valid options for that visual. This is genuinely well done. Power BI is not usually known for great IntelliSense, but the visual calculations editor is one of the better experiences in the product right now.

Where visual calculations don't fit

Honest assessment time. Visual calculations are not a replacement for measures. There are scenarios where you should still write a measure.

The big one is when the same calculation needs to appear across multiple visuals. A visual calculation lives on its visual. If you want "Sales YTD" available across thirty visuals in twelve reports, you write it once as a measure and use it everywhere. Writing the same visual calculation thirty times is just creating future maintenance work.

The other big one is when the calculation needs to operate on detail-level data, not aggregated visual data. Anything that involves iterating over rows in the fact table, or applying filter context manipulations to access specific records, has to be a measure. Visual calculations can't see the underlying data, only what's been aggregated to the visual.

Functions like USERELATIONSHIP, RELATED, and RELATEDTABLE don't work in visual calculations either. If your calculation depends on model relationships, you're back to writing measures.

And there's a subtler trap. Visual calculations can make it tempting to do business logic at the report layer rather than the semantic model layer. This is fine for one-off calculations but bad as a default approach. If a calculation represents a business concept that multiple reports will care about, it belongs in the model. If it's a presentation concern specific to this visual on this report, visual calculation is great. The discipline of "where does this logic belong" matters and is worth thinking about deliberately.

This is one of the things we work through with clients during Power BI consulting engagements. The line between report-layer and model-layer logic is one of those decisions that has long-term implications for maintainability.

The hide-from-visual trick

One of the underrated features is the ability to hide fields from the visual while keeping them on the visual matrix. Why does this matter?

Sometimes you need intermediate values for a visual calculation but you don't want users to see them. Say you've got a calculation that compares profit to a budget figure. You need profit and budget both on the visual for the calculation to reference them, but you only want users to see the variance.

The hide feature lets you bring profit and budget onto the visual, hide them, and show only the variance. The calculation still works because the values are technically present on the visual matrix. Users just see the clean result.

Use this carefully. It's tempting to bring lots of columns onto a visual just so you can reference them in visual calculations. But every additional column potentially affects the query performance. Bring on what you need, hide what users shouldn't see, and don't over-engineer it.

My current practice

After a year or so of using these, here's how I approach them on client work.

For anything table or matrix based where the calculation is row-relative (compare to previous, running totals, moving averages, percent of parent), I default to visual calculations. They're simpler, faster, and easier to maintain.

For anything that's a fundamental business measure (Total Sales, Profit Margin, Customer Count), I write a regular measure. These belong in the model.

For complex hierarchy-aware calculations like percent of parent in a hierarchy that supports drill-down, visual calculations are dramatically easier than the alternative. The COLLAPSE and EXPAND functions handle the drill levels automatically.

For visualisations that aren't tables or matrices (line charts, bar charts), visual calculations are still useful but the use cases are narrower. The axis structure is simpler, so the calculations are simpler. Running sums and period comparisons work nicely.

The one thing I always remind clients about. Visual calculations don't apply any of the styling or theming you've set on the visual. They show up in the visual matrix editor with no formatting, then they inherit the visual's formatting once you save. If a calculation looks wrong in the editor, save it and check the actual visual before concluding it's broken.

A few practical tips

A few things that took me a while to figure out:

  • The formula bar supports multi-line entries. Don't try to cram complex calculations onto one line. Format them like you would a normal DAX measure.
  • The visual matrix updates live as you type. Use this for fast iteration. Type, see the result, adjust.
  • You can refer to other visual calculations from a visual calculation. Build up complex logic in steps. The order they appear in the field list is the order they evaluate.
  • Hidden fields show up greyed out in the matrix editor but still on the actual visual matrix for calculation purposes. Don't get confused if you can't see something you've referenced.

For data and analytics consulting, I think visual calculations have become a default tool. The right answer for the right kind of problem. The Microsoft documentation on visual calculations covers the full function reference if you want to go deeper.

The bigger picture

Visual calculations are part of a broader trend in Power BI. Microsoft is gradually moving common patterns from being expert-level DAX problems to being beginner-friendly features. Calculation groups did it for time intelligence. UDFs are doing it for reusable logic. Visual calculations are doing it for row-relative calculations on visuals.

The net effect is that the bar to building useful Power BI reports has come down significantly. Things that used to require an expert can now be done by an analyst with a few hours of training. This is good. It also means experts are spending less time on plumbing and more time on actual business problems, which is what they should be doing.

If your team is still writing 40-line CALCULATE measures for running sums, give them an hour with visual calculations. You'll probably find a few hours of work per week disappear into something you didn't have to write.