Running Total in Power BI Using the DAX WINDOW Function

Running Total in Power BI

Running totals are a common requirement, especially when analyzing sales, finance, inventory and other values that accumulate over time. In this tutorial, I’ll focus on the Running Total in Power BI using DAX WINDOW function.

Although, there are several ways to calculate running totals; window function provides a flexible way to define where the calculation begins, where it ends, and how the rows should be ordered.

I’ll also demonstrate why this approach becomes particularly useful when report users apply date filters or slicers. By the end, you’ll understand how to build a running total that accumulates only across the selected and visible periods.

Also, there is a bonus tip toward the end, so don’t miss it!!

What Exactly Is a Running Total?

Before getting into the DAX logic, let’s quickly understand what we expect from a running total.

Whenever I interview Power BI professionals, running totals are one of the topics I like to discuss. The reason is simple: the calculation tests both your understanding of the expected business result and your ability to translate that requirement into the right DAX logic.

Running totals, also commonly called cumulative totals, show how a value builds up over time. It keeps adding the value from each row to the total from the previous rows.

For example,:

Month	Sales	Running total
January	100	100
February	150	250
March	200	450

For each month, the running total includes the current month’s sales and all preceding months within the defined calculation window.

The important part is that the calculation needs to know three things:

1. Where should the calculation begin?
2. Where should it stop for the current row?
3. In what order should the rows be evaluated?

This is where the WINDOW function becomes useful.

Running Total Using DAX Window Function

With the introduction of window functions in DAX, several calculations have become easier and more relatable, especially for people coming from a SQL background.

One such function is the WINDOW function.

The WINDOW function allows us to return a subset of rows from a table based on the starting position, ending position, and sorting rules that we define. Once that subset is available, we can perform a calculation over those rows to produce the running total.

For the complete syntax and supported arguments, refer to Microsoft’s official WINDOW function documentation.

In the screenshots below, you can see the table displaying the running total created using the WINDOW function, highlighted in pink, along with the corresponding DAX code.

Running Total in Power BI using DAX Window Function

DAX Code Snippet For Running Total

Running Total WINDOW =
CALCULATE (
    [Total Sales],
    WINDOW (
        1,
        ABS,
        0,
        REL,
        SUMMARIZE (
            ALLSELECTED ( 'Datedim' ),
            'Datedim'[Date]
        ),
        ORDERBY ( 'Datedim'[Date], ASC )
    )
)

As shown in the example, we can use either CALCULATE or SUMX together with the WINDOW function to calculate the running total.

Both approaches can produce the required result, so the choice ultimately depends on your personal preference and how you want to structure the measure.

Now let’s understand how the WINDOW function is actually working behind the scenes.

Understanding the WINDOW Function Logic

The WINDOW function defines a set of rows using a start position, an end position, a relation table, and a sorting rule.

1, ABS: Start at the first row

ABS means that the position is absolute. Therefore, 1, ABS starts the window at the first row available in the current relation.

In the example, the first row is September 2013. Therefore, every subset created by the WINDOW function begins from September 2013.

0, REL: End at the current row

The next two arguments define its ending position:

REL means that the position is relative to the current row. A value of zero represents the current row.

As Power BI evaluates each month, the starting point remains fixed while the ending point moves forward:

• September: September only
• October: September through October
• January: September through January

This expanding window creates the running total.

The starting position remains fixed at the first row, while the ending position keeps moving with the current row.

Defining the Relation Table

The next argument defines the relation. In simple terms, the relation is the table that the WINDOW function uses as a reference while creating the required subset of rows.

In my example, I’m using the SUMMARIZE function together with ALLSELECTED to generate a table containing the dates available in the current report context.

For example, if the table visual contains dates from September 2013 to December 2014, those dates become part of the relation used by the WINDOW function.

In this calculation, ALLSELECTED removes the individual row context created by the visual while preserving explicit selections made through external filters and slicers. This allows the measure to accumulate across the set of dates selected by the report user rather than restarting independently on every visible row.

This behavior becomes very useful in the bonus scenario that we’ll explore shortly.

Finally, ORDERBY defines the sequence in which WINDOW evaluates the relation. For a chronological running total, the date must be sorted in ascending order so that each result includes the current date and all preceding dates in the selected range.

At first glance, the WINDOW syntax may look a little overwhelming, especially if you’re new to DAX. There are several arguments, and terms such as ABS, REL, relation, and ORDERBY can take some time to understand.

However, you can simplify the logic by connecting each argument with a basic question:

• Where should the window begin?
• Where should the window end?
• Which rows should be considered?
• In what order should those rows be evaluated?

Once you become comfortable answering these four questions, the WINDOW function becomes much easier to use.

And honestly, once you get used to it, there’s no turning back!

Bonus: Running Total Based on Selected Dates

Now consider a more dynamic requirement: the report user wants the running total to include only the dates selected through external filters or slicers.

This is a perfectly valid and fairly common business requirement.

Let’s add Year and Month slicers to the report. Now suppose the user selects only the months from July 2014 to December 2014, excluding all dates from 2013 and the months from January through June 2014.

The screenshot below shows the resulting table after applying the slicer selection.

Running Total Based on Filtered Rows

When we examine the results closely, we notice something interesting.

Among the approaches compared in the above example, the WINDOW measure is the one that matches our specific business requirement. It starts with July 2014, the first month in the slicer selection, and accumulates only across the selected months through December 2014.

It’s important to understand that these results are not necessarily incorrect. They’re simply answering a different business question.

A year-to-date measure answers:

What is the cumulative value from the beginning of the year?

The WINDOW-based measure in this example answers:

What is the cumulative value across the rows currently selected and visible?

For this requirement, the DAX WINDOW function provides a clear and flexible way to create a selection-aware running total across the rows visible to the report user.

Conclusion

Running totals may look simple, but the correct DAX pattern depends on the business question you need to answer.

In this tutorial, we used the WINDOW function to create a running total that begins with the first selected row and accumulates through the current row. We also explored how ABS, REL, ALLSELECTED, and ORDERBY work together to make the calculation responsive to report filters and slicers.

The key takeaway is that the WINDOW measure is not replacing every running-total pattern. It is particularly useful when the requirement is to calculate a cumulative value across the rows currently selected and visible to the report user.

Have you used WINDOW for running totals, or do you prefer a traditional DAX approach? Share your experience in the comments, especially if you have encountered a scenario where another method was more suitable.

Connect with me through my social media handles; I look forward to hearing from you!

1. LinkedIn
2. Gumroad
3. Topmate

You may also find my guide on TMDL view in Power BI & reducing Power BI data model size useful when optimizing semantic-model performance. 

Also, do read my latest blogs: Previous Row in Power BI using DAX INDEX, Pareto Chart in Power BI using DAX and Why Power BI is the Best BI Tool in 2026.

Explore more tutorials on Power BI with Akshay.