Start free
Back to blog

Power BI Percent of Total Is Wrong? ALL vs ALLSELECTED

A selected violet paper segment lifted from a layered circular total and connected back to the whole by a hand-drawn measuring arc

A Power BI percent of total is usually wrong because the denominator
removes too many filters, too few filters, or the wrong filter. Before
choosing ALL, ALLSELECTED, or
REMOVEFILTERS, write down what “total” means: the entire
model, the current report selection, the current parent group, or the
visible rows in one visual.

The formula is the easy part:

Percent of Total =
DIVIDE ( [Sales Amount], [Chosen Total] )

The hard part is defining [Chosen Total].

Start with a base measure

Keep the numerator simple and reusable:

Sales Amount =
SUM ( Sales[SalesAmount] )

Do not repeat SUM ( Sales[SalesAmount] ) inside every
denominator. A base measure makes it easier to compare the numerator and
denominator under the same filter context.

Add these temporary measures to a table or matrix:

Visible Sales Rows =
COUNTROWS ( Sales )
Visible Products =
COUNTROWS ( VALUES ( Product[ProductKey] ) )

If those counts do not change when a slicer changes, the problem is
probably the model or visual interaction—not the percentage formula.

Pattern 1:
Percent of the absolute grand total

Use this when every product row should be divided by sales across all
products, even when a product slicer is active:

Percent of All Products =
DIVIDE (
    [Sales Amount],
    CALCULATE (
        [Sales Amount],
        REMOVEFILTERS ( Product )
    )
)

REMOVEFILTERS ( Product ) clears category, brand, color,
and every other filter on the Product table. Filters from Date,
Customer, Geography, and other tables remain.

This is narrower than clearing the entire model:

-- Usually too broad
CALCULATE ( [Sales Amount], REMOVEFILTERS () )

The no-argument version removes all filters it can remove. That may
erase the year, customer segment, or region that the reader expected to
keep.

Pattern 2: Percent of
the selected total

Use ALLSELECTED when the denominator should respect
outside selections—commonly slicers—but remove the current visual’s row
or column:

Percent of Selected Products =
DIVIDE (
    [Sales Amount],
    CALCULATE (
        [Sales Amount],
        ALLSELECTED ( Product[Category] )
    )
)

If a slicer restricts the report to Bikes and Accessories, the two
visible categories can add to 100%. A category row is divided by the
total for that selected set.

Microsoft
describes ALLSELECTED
as retaining explicit filters and
context outside the current query while removing row and column filters
inside the query. That is why it is often useful for visual totals—and
why its result depends on where the measure is evaluated.

Do not treat ALLSELECTED as a magic “make it 100%”
function. Test it in the actual visual, with its actual axes and
slicers.

Pattern 3: Percent
of parent in a hierarchy

A matrix with Category and Subcategory needs a different denominator
at each level:

Percent of Parent =
SWITCH (
    TRUE (),
    ISINSCOPE ( Product[Subcategory] ),
        DIVIDE (
            [Sales Amount],
            CALCULATE (
                [Sales Amount],
                ALLSELECTED ( Product[Subcategory] )
            )
        ),
    ISINSCOPE ( Product[Category] ),
        DIVIDE (
            [Sales Amount],
            CALCULATE (
                [Sales Amount],
                ALLSELECTED ( Product[Category] )
            )
        ),
    1
)

At subcategory level, the measure removes the current subcategory
while keeping the category context. At category level, it removes the
current category. At the grand total, it returns 1.

The official
ISINSCOPE example
uses this same idea for percentage of
parent. If your hierarchy totals still behave unexpectedly, compare HASONEVALUE vs
ISINSCOPE
.

Why the
denominator stays equal to the numerator

This formula looks reasonable but often changes nothing:

Wrong Percent =
DIVIDE (
    [Sales Amount],
    CALCULATE (
        [Sales Amount],
        ALL ( Sales )
    )
)

The visual may be grouped by Product[Category]. Clearing
filters on the Sales fact table does not necessarily remove the category
filter already propagating from Product. The relationship can apply that
dimension filter again.

Remove the filter at its source:

CALCULATE (
    [Sales Amount],
    REMOVEFILTERS ( Product[Category] )
)

This is one of the most useful DAX debugging rules: clear the
dimension column that owns the filter, not whichever fact table is
closest to the numeric value.

Why every row shows 100%

If numerator and denominator are identical on every row, inspect
three things:

  1. The denominator did not remove the row-axis filter.
  2. The axis uses a column from a different table than the one you
    cleared.
  3. A relationship does not propagate the expected filter.

Expose the denominator as its own measure:

Selected Product Total =
CALCULATE (
    [Sales Amount],
    ALLSELECTED ( Product[Category] )
)

Add [Sales Amount],
[Selected Product Total], and the percentage side by side.
The denominator should remain constant across category rows when that is
the intended business rule.

If the base measure itself repeats on every row, use the same-value-on-every-row
checklist
.

Why the percentages do
not add to 100%

That is not automatically a bug.

  • Hidden categories may still be in the denominator.
  • A Top N visual filter may show five rows while the denominator
    contains twenty.
  • Categories may overlap when the numerator is a distinct count.
  • The displayed values may be rounded.
  • Subtotals may be evaluated at a different hierarchy level.
  • Blank categories may be counted but not displayed.

First calculate the visible sum:

Visible Percent Sum =
SUMX (
    VALUES ( Product[Category] ),
    [Percent of Selected Products]
)

If this returns 100% while the manually visible labels appear not to,
investigate hidden rows, blank labels, and formatting.

For non-additive measures such as unique customers, 100% may require
a business definition about overlap. The DISTINCTCOUNT totals
guide
explains why category values can overlap.

A five-state
test for percent-of-total measures

Test the measure in these contexts:

  1. No slicers, detail rows visible.
  2. One slicer selection.
  3. Multiple slicer selections.
  4. A hierarchy subtotal.
  5. The grand total.

For each state, write down the expected numerator, expected
denominator, and expected percentage before looking at Power BI. This
separates a DAX problem from an unclear definition.

Which
filter-removal function should you use?

  • Use REMOVEFILTERS when you want the clearest statement
    that a named filter should be cleared.
  • Use ALL when you need its table-returning behavior or
    are working with an established pattern.
  • Use ALLSELECTED for a visual total that retains outside
    selections.
  • Use ALLEXCEPT when you deliberately want to clear a
    table except for named grouping columns.

See ALL vs
ALLSELECTED vs ALLEXCEPT
for the broader comparison. For a measure
that should ignore exactly one report choice, use the one-slicer
pattern
.

Frequently asked questions

Should percent
of total use ALL or ALLSELECTED?

Use ALL or REMOVEFILTERS for an absolute
total that ignores the named selection. Use ALLSELECTED
when the denominator should keep outside report selections and represent
a visual total.

Why is my Power
BI percentage greater than 100%?

The numerator and denominator are probably evaluated over different
sets. Display both as separate measures, then count visible dimension
keys and fact rows for each context.

Why does the total row show
100%?

At the grand-total row, the numerator and denominator usually
represent the same set, so 100% is correct. If the total should show
blank instead, wrap the display rule in ISINSCOPE.

Where can I test these
patterns?

Build the base measure, denominator, and percentage separately in the
DAX
playground
. Change one filter at a time and verify the denominator
before formatting the result as a percentage.

Done reading?

Put it into reps — pick a challenge.

Start practicing More posts