THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

SQLBI - Marco Russo

SQLBI is a blog dedicated to building Business Intelligence solutions with SQL Server.
You can follow me on Twitter: @marcorus

The Cumulative Total #dax pattern

The first pattern published on is the Cumulative Total. Another common name of this calculation is Running Total, but the reason why we named the pattern in this way is that we identify all those scenarios in which you want to obtain a value, at a certain date, that corresponds to the result of a number of transactions executed in the past. Usually, this scenario is implemented using snapshot tables in the classical Kimball modeling. With a columnar table, you can afford avoiding the snapshot table even with a relatively large dataset.

You might want to implement the Cumulative Total pattern to reduce the volume of data stored in memory, transforming snapshot tables into dynamic calculation in DAX. The examples shown in the article represent an implementation of the Inventory Valuation at any point in time. Remember, I am not saying snapshot tables can be avoided in Tabular, but you have to consider the alternative, especially when the size of snapshot table is an order of magnitude (or more) larger than the original transactions table. Do some benchmark and find the better solution for your model!

Published Thursday, February 20, 2014 3:29 PM by Marco Russo (SQLBI)
Filed under: , ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



Rockey said:

Hi ,

thanks for share this information,

I have one question..

I am able to get cumulative value by using mentioned DAX measure... but its give me slow performance...

and my other measure also gives slow performance beacuse those measures are dependent on this cumulative measure...

have you any other idea..

March 4, 2015 5:56 AM

Marco Russo (SQLBI) said:

As usually, it depends. You might evaluate how to created aggregated data that speed-up access time by filtering only one date - the point is that the convenience between this traditional approach and the continuous calculation depends entirely on data distribution. Also consider possible optimizations of your DAX code and performance of the hardware you have. The right combination might depend on all of these factors.

March 4, 2015 6:04 AM

Germane said:

Hi Marco,

I have a table with 3 columns (Employee number / Date Worked / Hours worked). People have 10-day shifts and it is important for me to know on what day of each shift the person is (from 1 to 10). I do not need a running total of the hours worked.

Let's say that my columns are EmployeeNum and Date and HoursWorked, is there a calculated column to keep that order within the work hitch? The key is that when they go time off, the clock gets reset for that individual and starts counting again from 1 when he gets back to work after the 7 day rest period.

I am very familiar with the EARLIER function but outside of using it to know if the person worked on the day prior, I do not see how it can get me out of the bind?

Am I asking too much from PowerPivot and should look for my solution in SQL?

Thank you.

April 1, 2015 10:24 PM

Ben said:

Anyone know how to make this work with dynamic date arguments to get a rolling total for the past three months?


April 9, 2015 6:04 PM

Marco Russo (SQLBI) said:

Germane, I'm not sure about your requirements. I think you can do what you need in DAX, maybe that you

should use CALCULATE applying a correct filter argument to consider only the previous rows from the

same EmployeeNum and Date less than the current one. Something like:

CALCULATE ( SUM ( t[HoursWorked] ), ALLEXCEPT ( t, t[EmployeeNum] ),

    FILTER ( ALL ( t[Date] ), t[Date] < EARLIER ( t[Date] ) )


More logic should be added in order to identify when you want to reset the sum after the rest period.

I hope it helps.

April 10, 2015 7:11 AM

Marco Russo (SQLBI) said:

Ben: look at the Moving Annual Total in (just use 3 months instead of 1 year)

April 10, 2015 7:13 AM

Karen said:

Hi Marco,

We have an SSAS tabular model of survey data.  Survey data is tough, we have over 600 custom calculations to score the data into percentages and perform statistical testing.  We need to report scores over time by month, with each month actually containing the last three months of survey data.  I'd like to find a date table approach, where I could grab a month field from a date table to use in my pivot tables.  Is there a way to do this?


May 10, 2017 12:07 PM

Marco Russo (SQLBI) said:

Karen, you should use a date teble, if you don't have one, you can build one in DAX using calculated columns and the same excel functions that extract day/month/quarter from a date (look at MONTH/DAY/FORMAT functions, for example).

May 13, 2017 3:47 AM

Karen said:

Thanks for the reply.  Yes, we have several date tables, and each has several month fields.  But these just give us each month's data when used in the columns of a pivot table.  We are looking for rolling scores, so we need each column in a pivot to be a rolling three months of data.  For example, an "April" column would show data for Feb/Mar/Apr and then the next column labelled "May" would show data for Mar/Apr/May.  It seems like a many-to-many where each date belongs to more than one rolling period, but we're struggling with how to set it up. Because the columns use overlapping dates, we haven't been able to do this in one pivot, it takes a separate pivot for each time period in order to trend the rolling scores over time, thus making the report slow.  Any advice would be much appreciated!

May 15, 2017 1:03 PM

Marco Russo (SQLBI) said:

I would use a measure using DATESINPERIOD as a filter:

CALCULATE ( [Existing Measure], DATESINPERIOD ( Date[Date], -3, MONTH ) )

May 20, 2017 5:18 AM

Bharath Kumar said:

Hi Marco,

         I am trying to achieve the following functionality of MDX in DAX


Purpose : Calculate sum of Rolling 13 weeks data

Earlier() function in Dax would take me to previous week also I checked this article was not dynamic, I wish to dynamically calculate Sum over 13 weeks however it is not fitting into DAX expression. Kindly know the best alternative with using date related functions?

May 24, 2017 10:41 AM

Marco Russo (SQLBI) said:

Weeks are not supported in DAX time intelligence functions, so you should use a filter such as DATEADD ( 'Date'[Date], -13*7, DAY ), or use the alternative approach described in this article:

May 28, 2017 6:25 PM

Shivani said:

Hi Marco,

I am trying to use the below DAX:

Cumulative Count =


   SUM(tblCustomerMaster[Customer Count]),


       ALL ( tblCustomerMaster[Creation Date] ),

       tblCustomerMaster[Creation Date] <= MAX (tblCustomerMaster[Creation Date] )



But it is giving me just the sum basis the month and year. What i actually need is the cumulative sum.

Is it necessary to have a separate date table for carrying out this expression??

Please help me out with this.

September 12, 2017 2:46 AM

Marco Russo (SQLBI) said:

You should apply the filter to the date table if you have a Date table connected to Creation Date column.

September 17, 2017 10:49 AM

Shivani said:

I made the changes suggested by you

Cumulative Count =


   SUM(tblCustomerMaster[Customer Count]),


       ALL ( 'Date'[Date] ),

       'Date'[Date] <= MAX ('Date'[Date] )



Now its just giving me the value 27 against all the months and years

September 20, 2017 10:33 PM

Marco Russo (SQLBI) said:

It seems you do not have the relationship or you are not using the Date table in your report.

September 25, 2017 9:08 AM

Leave a Comment


About Marco Russo (SQLBI)

Marco Russo is a consultant, writer and trainer specialized in Business Intelligence with Microsoft technologies. He runs the SQLBI.COM website, which is dedicated to distribute resources useful for BI developers, like Integration Services components, Analysis Services models, tools, technical information and so on. Marco is certified as MCT, MCDBA, MCSD.NET, MCSA, MCSE+I.

This Blog



Privacy Statement