Guides

VAR and RETURN in Power BI DAX

By Ravindra Bagale, Power BI & Data Analytics trainer · LinkedIn · Published: 30 September 2026 · Last updated: 30 September 2026

VAR stores a named result inside a DAX measure, and RETURN is the one answer you hand back to the visual — so a long formula becomes a short story you can debug.

VAR SalesAmt = [Total Sales]
VAR OrdersN = [Orders]
RETURN DIVIDE ( SalesAmt, OrdersN )

Why VAR, why FILTER, what comes out

A variable does not filter rows. It remembers a number you already calculated.

Tiny sales table, City slicer = Pune (fictional FreshBasket):

Three rows are still in the visual. Sales are 200. Distinct orders are 2.

Why use VAR:

1. You need 200 and 2 more than once (the ratio, then a label).
2. Naming them beats copying SUM three times.
3. You can show one name on a card while you check your work.

Why FILTER is not inside the VAR line:

1. The slicer already kept Pune. Those rows go in.
2. SUM and DISTINCTCOUNT walk those rows and each return one number.
3. VAR SalesAmt = [Total Sales] stores 200. It does not store the three rows.
4. A later CALCULATE does not reopen that variable and filter it again.

When FILTER is needed with a variable:

1. The question cuts rows by a test, for example Amount above 50.
2. FILTER keeps the rows that pass. Here that is 100 and 60, not 40.
3. COUNTROWS or SUM turns that smaller table into one number.
4. You may store that number in a VAR. The filter did the cutting. The variable only remembers the result.

What the AOV formula does, in order:

1. Rows in: the three Pune rows.
2. SalesAmt out: 200.
3. OrdersN out: 2.
4. RETURN divides. The card shows 100.
5. Change the slicer to another city and the same steps run on that city's rows.

Real example: two shops and the phone bill

Picture one small shop, FreshBasket, with a counter in Mumbai and a counter in Pune. March sales slips:

The same owner also pays a phone bill for each shop. That bill is not a sale. It is money going out.

Why VAR here: you will say "average sale" and "average phone bill" more than once. Name the pieces.

1. City slicer = Mumbai. Sales rows in: rice, oil, atta. Number out of [Total Sales]: 1000. Store it as VAR SalesAmt.
2. Three slips, so VAR BillsN = 3 if each slip is one order. RETURN DIVIDE ( SalesAmt, BillsN ) shows about 333 on the card.
3. Phone-bill rows in, same slicer: 499, 499, 699. VAR BillAmt becomes 1697. VAR MonthsN becomes 3. Average bill out: about 566.
4. VAR did not choose Mumbai. The slicer did. The variable only remembers the number after the rows were already kept.

Why FILTER joins this story: "months where the phone bill is above 500" is a test. FILTER keeps only March (699). COUNTROWS then returns 1. You may store that 1 in a VAR. The filter cuts rows. The variable does not.

What you should see: click Pune on the slicer and both cards must drop (sales 200, phone bill 399). If they stay on Mumbai, the variable was frozen too early, before the city filter.

What do I need before this guide?

• A base measure from SUM vs SUMX or the DAX beginner guide.
• IF and SWITCH if the return value is a label.
• DIVIDE if the return value is a ratio.
• Course: VAR and RETURN.

Before and after (look at the tables first)

Why variables exist

1. A measure that repeats [Total Sales] four times is hard to read out loud.
2. If you change the definition, you must hunt every copy.
3. VAR gives the piece a name. RETURN is the only line the visual receives.
4. You can return a middle name on purpose while you are learning the measure.

Write AOV with names

Assume these base measures already exist:

Total Sales = SUM ( Sales[Amount] )

Orders = DISTINCTCOUNT ( Sales[Order ID] )

Now the ratio:

AOV =
VAR SalesAmt = [Total Sales]
VAR OrdersN = [Orders]
RETURN
    DIVIDE ( SalesAmt, OrdersN )

Read it vertically:

1. SalesAmt calls the sales measure in the current filter context (City slicer, visual, and so on).
2. OrdersN calls the orders measure in that same context.
3. RETURN divides them safely.
4. Format AOV as a decimal or currency. DIVIDE does not format the measure for you.

A label that uses the names

FreshBasket (fictional) wants a simple band for the ops review. Thresholds below are practice numbers, not a company rule.

AOV Band =
VAR SalesAmt = [Total Sales]
VAR OrdersN = [Orders]
VAR AovValue = DIVIDE ( SalesAmt, OrdersN )
RETURN
    SWITCH (
        TRUE (),
        ISBLANK ( OrdersN ), BLANK (),
        AovValue >= 800, "Strong",
        "Watch"
    )

1. The third variable may use the first two. Order matters: a name must be defined before you use it.
2. SWITCH ( TRUE () ) still takes the first true test. Variables do not change that.
3. ISBLANK on the order count avoids a band when there is nothing to average.

The rule students miss

A variable is evaluated where it is defined. It does not wake up again inside a later CALCULATE.

Sales Frozen =
VAR SalesAmt = [Total Sales]
RETURN
    CALCULATE ( SalesAmt, Sales[Channel] = "Online" )

1. SalesAmt is already a number from the outer context.
2. The CALCULATE that follows does not recompute that variable under the Online filter.
3. If you wanted Online sales, call the measure inside CALCULATE, or define the variable there.
4. This is useful when you mean to freeze a value. It is a bug when you expected the filter to apply.

Debug without guessing

1. Change RETURN to RETURN OrdersN.
2. Put the measure on a card and slice City.
3. Confirm the count matches the table.
4. Change RETURN to RETURN AovValue if you are in the band measure.
5. Put the real SWITCH or DIVIDE back when the middle looks right.

Ghabru naka — a wrong band is usually a wrong middle number, not a mysterious visual.

Mistakes and calm fixes