--- title: "VAR: the DAX keyword that makes your measures readable" date: 2026-07-27T00:00:00Z updated: 2026-07-24T10:34:33Z tags: ["DAX", "Power BI", "Data Modeling", "Vertipaq", "VAR", "Getting Started"] canonical: https://bianca.codes/blog/var-the-dax-keyword-that-makes-your-measures-readable/ --- # VAR: the DAX keyword that makes your measures readable _A DAX measure that repeats the same subtotal three times isn't thorough, it's a maintenance problem VAR was built to fix._ A few weeks back I said LAMBDA was the day Excel let you stop retyping the same formula into every cell that needed it. DAX had its own version of that moment, years earlier, and if you learned Power BI by copying measures off forum posts, there's a good chance yours are still one enormous nested expression where the same subtotal gets calculated two or three times inside itself. VAR is DAX's answer to "give this step a name so I stop writing it out again." It's been in the language since the 2015 DAX update, which means there's no excuse for it not being in your toolkit, and every measure you've written the hard way is one you can rewrite in five minutes once the shape clicks. ## The mental model Think of a VAR/RETURN block as showing your working. Each VAR names one intermediate result, in the order you calculated it, and RETURN is where you finally answer the question using those names instead of the raw expressions. Nothing about what DAX computes changes, only how many times you have to type the same logic and how easy the formula is to read six months from now. That "computed once" part matters beyond readability. Reference a variable's name three times in RETURN and DAX evaluates the underlying expression once and reuses the stored result for the other two, not three separate recalculations. Write the same `CALCULATE ( ... )` three times without a VAR and the engine has no way to know they're identical, so it runs the calculation three times. ## The syntax Bare shape: ```vba MeasureName = VAR VariableName = RETURN ``` Chain more than one, each on its own line, and later VARs can use earlier ones: ```vba MeasureName = VAR Step1 = VAR Step2 = RETURN ``` The order only runs one direction. A VAR can reference anything defined above it in the same block, never anything below - there's no forward-declaring your way around that, and DAX won't even try. ## A year-over-year percentage without repeating yourself Say you're measuring year-over-year sales growth. Without VAR, the honest version of this formula needs the prior-year total twice, once for the numerator and once for the denominator: ```vba Sales YoY % = VAR CurrentSales = [Total Sales] VAR PriorYearSales = CALCULATE ( [Total Sales], SAMEPERIODLASTYEAR ( 'Date'[Date] ) ) RETURN DIVIDE ( CurrentSales - PriorYearSales, PriorYearSales ) ``` `PriorYearSales` is the one that actually earns its keep here. It gets calculated once and reused in both the subtraction and the `DIVIDE` denominator. Without the VAR, that `CALCULATE ( [Total Sales], SAMEPERIODLASTYEAR ( ... ) )` chunk would need to appear twice in the formula, which means two separate context transitions instead of one, and any future fix to the date logic has to be made in two places instead of one. ## What it doesn't do Three real limits worth knowing before you restructure half your model around VAR. A VAR is evaluated once, in the context that exists at the point it's defined, not the context that exists later when you reference it. This is the exact gotcha [DAX Context Demystified, Part 2: CALCULATE and Context Transition](/blog/dax-context-demystified-part-2-calculate-and-context-transition/) covers in full - write a VAR inside `CALCULATE` and reference that variable after the filter argument changes the context, and the variable does not recompute in the new context. It already locked in its value from the moment DAX walked past that line. You can't reassign one. VAR is single-assignment; write `VAR Total = ...` twice in the same block under the same name and DAX won't let you update it like a loop counter, because it isn't one - that's the same restriction it inherited from the functional side of the language. It's local to the block it's defined in. A VAR named inside one measure isn't visible from any other measure, and there's no way to promote it later without copy-pasting the definition. If two measures genuinely need the same intermediate result, that's the signal to pull it into its own separate measure instead of VAR-ing your way around it in both places. VAR didn't add a new capability to DAX the way `CALCULATE` or `SAMEPERIODLASTYEAR` did. It changed how much of your own logic you have to hold in your head while reading a formula back, the same trade LAMBDA made for Excel a decade later. A well-named VAR/RETURN block reads closer to a short paragraph than parsed algebra, and that's the actual point. ## Frequently Asked Questions ### **Does VAR work outside Power BI?** Yes. VAR/RETURN is core DAX, not a Power BI-only feature - it behaves the same way in Excel's Power Pivot and in Analysis Services or Fabric semantic models, because they all share the same DAX engine. ### **What's the difference between VAR and just writing a separate measure?** Scope. A VAR only exists inside the one measure it's defined in and can't be called from anywhere else. A separate measure is visible to every other measure and every visual in the model, the same way a named LAMBDA is callable from any sheet in a workbook. If more than one measure needs the same intermediate result, that's usually the sign to promote it to its own measure instead of duplicating a VAR. ### **Can I use CALCULATE inside a VAR?** Yes, and it's a common pattern for storing a prior-period or filtered total under a name. Just remember the VAR locks in whatever context existed at that point - see "What it doesn't do" above. ### **Does the order of VAR statements matter?** Yes. Each VAR can only reference VARs defined above it in the same block. Reference one defined further down and DAX won't resolve it - there's no hoisting. ### **Do VARs actually improve performance, or just readability?** Both, in the common case. An expression referenced more than once downstream gets calculated once and reused, rather than recalculated for every reference, which is exactly what happens if you paste the same `CALCULATE ( ... )` into a formula twice instead of naming it. ### **Can a VAR/RETURN block have more than one RETURN?** No, one block gets exactly one RETURN. You can nest a whole second VAR/RETURN block as the value of an outer VAR if you genuinely need to, but at that point the formula is usually asking to be split into two measures instead. For the context-transition gotcha VAR runs into with CALCULATE, see [DAX Context Demystified, Part 2: CALCULATE and Context Transition](/blog/dax-context-demystified-part-2-calculate-and-context-transition/). And for the same "stop repeating your logic" lesson from the Excel side, see [LAMBDA: the day Excel let you write your own functions](/blog/lambda-the-day-excel-let-you-write-your-own-functions/).