How to Multiply in Power BI DAX
Performing calculations in Power BI always feels a little different than it does in a spreadsheet, especially when it comes to something as basic as multiplication. While finding a product is straightforward, learning how DAX (Data Analysis Expressions) handles context is what separates a clean report from an incorrect one. This guide breaks down the simple and effective ways to multiply in Power BI, using the asterisk operator (*) along with the PRODUCT and PRODUCTX functions.
The Easiest Method: Using the Asterisk (*) Operator
The asterisk (*) is your go-to operator for multiplication, just like in Excel. You'll primarily use it in two scenarios: creating calculated columns and building measures that need to work row by row. While they look similar on the surface, how DAX evaluates them is quite different.
Multiplication in a Calculated Column
The most direct way to see multiplication at work is by creating a calculated column. In a calculated column, DAX has "row context," meaning it performs the calculation for each individual row of your table automatically.
Imagine you have a Sales table with the quantity of items sold and the price per item. You want to calculate the total revenue for each line item.
Here’s a sample Sales table:
OrderIDProductQuantityUnitPrice
To add a LineTotal column, you’d navigate to the Data View in Power BI, select your table, and click "New Column". Then, you would enter this super simple DAX formula:
LineTotal = Sales[Quantity] * Sales[UnitPrice]
Instantly, Power BI goes through every single row in the Sales table, multiplies the Quantity by the UnitPrice for that specific row, and populates the new LineTotal column with the result. It’s easy and intuitive because calculated columns are built to think row-by-row.
Multiplication Within a Measure (Using Iterators)
Things get a little more complex when you move from static calculated columns to dynamic measures. Measures don't have that built-in "row context" that columns do. A measure works on aggregated data based on the filters applied in your report (like a slicer for a date range or a specific product).
A common mistake beginners make is trying to multiply two aggregated measures:
Incorrect Revenue = SUM(Sales[Quantity]) * SUM(Sales[UnitPrice])
This formula will almost always give you the wrong answer. Why? It first adds up all the quantities in your filtered data, then adds up all the unit prices, and then multiplies those two giant sums together. That’s not how revenue works!
To get the correct total revenue, you need to tell DAX to multiply the price and quantity for each row first, and then sum up those individual results. To do this, you need to create your own row context using a special type of function called an "iterator." The most common one is SUMX.
The SUMX function takes a table and an expression as its arguments. It iterates over the table row by row, evaluates the expression for each row, and then sums the results.
Here's the correct way to write a Total Revenue measure:
Total Revenue = SUMX( Sales, Sales[Quantity] * Sales[UnitPrice] )
Here’s the step-by-step breakdown:
SUMX( Sales, ... ): This tells DAX, "Go to theSalestable and get ready to visit each row one by one."... Sales[Quantity] * Sales[UnitPrice]: This is the expression thatSUMXevaluates for every single row it visits. It multiplies the quantity and price for that specific row.SUM...(...): After calculating the line total for every row, the "SUM" part ofSUMXadds up all those individual results to give you the final, correct total.
This is one of the most important concepts to grasp in DAX. Iterators like SUMX let you control the order of operations, ensuring your calculations are accurate.
Advanced Multiplication with PRODUCT and PRODUCTX
While the asterisk and an iterator handle most business logic, DAX provides two dedicated functions for multiplying entire sets of numbers: PRODUCT and PRODUCTX.
Using the PRODUCT Function
The PRODUCT function is the DAX equivalent of Excel’s =PRODUCT(). It takes a single column as an argument and multiplies all the numbers in that column together.
Its use cases are more niche than SUMX. You might use it for financial models to calculate compound interest or growth factors. For example, if you have a table of monthly return rates and you want to calculate the total compounded growth factor, you could use PRODUCT.
Imagine a MonthlyReturns table with a column called GrowthFactor (which is calculated as 1 + Return Rate).
Your DAX measure would be:
Total Compounded Growth = PRODUCT(MonthlyReturns[GrowthFactor])
If your GrowthFactor column contained [1.05, 1.02, 0.98], this function would return 1.05 * 1.02 * 0.98, giving you approximately 1.049. You could then multiply your initial investment by this factor to find its final value.
Note: The PRODUCT function ignores any blank rows, which is quite helpful as it prevents multiplication by zero or an error.
Using the PRODUCTX Function
Just as SUMX is the iterated version of SUM, PRODUCTX is the iterated version of PRODUCT. It allows you to evaluate an expression for each row of a table and then multiply all the resulting values together.
The syntax is: PRODUCTX(<table>, <expression>)
Let's revisit our compound growth example. Instead of pre-calculating a GrowthFactor column, you might just have a ReturnRate column. With PRODUCTX, you can create the factor on the fly.
Using a table named Returns with a ReturnRate column:
Total Compounded Growth = PRODUCTX( Returns, 1 + Returns[ReturnRate] )
Here’s what’s happening:
PRODUCTX( Returns, ... ): DAX goes to theReturnstable to start iterating row by row.... 1 + Returns[ReturnRate]: For each row, it calculates the growth factor (e.g., if the return rate is 5% or 0.05, it calculates1.05).PRODUCT...(...): It then multiplies all of those calculated growth factors together to give you the final compounded result.
Common Mistakes to Avoid
Multiplying in DAX is powerful, but a few misunderstandings can lead to flawed reports. Keep these tips in mind.
1. Forgetting the Difference Between Calculated Columns and Measures
A calculated column is static. It's calculated once during data refresh and stored in your model, taking up space. It’s useful for values you want to see when browsing your raw data. A measure is dynamic. It’s calculated on the fly based on the user’s interactions with the report - slicing, filtering, etc. - and doesn’t permanently store any data. Always default to creating a measure unless you have a specific reason to need a physical column.
2. Multiplying Aggregates Instead of Iterating
This is the SUM(A) * SUM(B) mistake we covered earlier. To visualize the error, imagine this simplified sales table:
Row 1: Quantity = 10, Unit Price = $5 (Line Total = $50) Row 2: Quantity = 4, Unit Price = $20 (Line Total = $80)
- The Right Answer: $50 + $80 = $130
- The Wrong Method (
SUM(Quantity) * SUM(UnitPrice)): (10 + 4) * (5 + 20) = 14 * $25 = $350
A huge difference! Always use an iterator like SUMX to perform row-level calculations before aggregating the final results in a measure.
3. Handling Blanks and Zeros
DAX handles blanks and zeros in specific ways that can affect your results:
- Multiplying any number by zero results in
0. - Multiplying any number by
BLANK()results inBLANK(). Reports often ignoreBLANK()values, which can be useful for keeping your visuals clean.
If you need to treat blank values as 1 (for example, if a blank discount value should be ignored), you can use an IF statement or the COALESCE function within your iterator:
FinalPrice = LineTotal * (1 - COALESCE(Sales[DiscountPercent], 0))
In this formula, COALESCE checks if DiscountPercent is blank. If it is, it substitutes it with 0. This ensures the calculation doesn't error out or return unexpected blanks.
Final Thoughts
From the straightforward asterisk operator in calculated columns to powerful iterator functions like SUMX and PRODUCTX in measures, DAX gives you complete control over how you perform multiplications. The key is to always think about context: are you performing your calculation row-by-row before you aggregate, or after? Get that right, and your reports will be both impressive and accurate.
Learning these DAX functions properly is a major step, but it also shows why so many teams get stuck in the weeds of report building rather than focusing on strategy. Sometimes you just need to know which campaigns are profitable or how your sales pipeline is trending this quarter, not spend two hours figuring out the right iterator function to use. At Graphed we created a way to get answers without learning any DAX at all. We connect to an ever-growing list of apps like your Google Analytics, HubSpot, and Shopify, then let you create entire real-time dashboards just by describing what you need in plain English. That means you get accurate, live reports in seconds, so you can go back to analyzing insights instead of wrestling with formulas.
Related Articles
What SEO Tools Work with Google Analytics?
Discover which SEO tools integrate seamlessly with Google Analytics to provide a comprehensive view of your site's performance. Optimize your SEO strategy now!
Looker Studio vs Metabase: Which BI Tool Actually Fits Your Team?
Looker Studio and Metabase both help you turn raw data into dashboards, but they take completely different approaches. This guide breaks down where each tool fits, what they are good at, and which one matches your actual workflow.
How to Create a Photo Album in Meta Business Suite
How to create a photo album in Meta Business Suite — step-by-step guide to organizing Facebook and Instagram photos into albums for your business page.