What Is the Does Not Equal Sign in Power BI?

What Is the Does Not Equal Sign in Power BI?

Every Power BI report eventually needs to exclude something. One region that skews the totals. One product line that has been discontinued. One test account that nobody wants in the customer count. The natural way to express that is "give me everything that is not this" -- and the operator that does it is the one most people reach for second, after trying to remember whether Power BI uses the same symbol as Excel.

It does not, quite. Excel users reach for <> and get it right by accident. SQL users type != and get a syntax error. And a surprising number of reports end up with a filter that looks correct, returns a plausible number, and is quietly wrong because of how Power BI treats empty cells.

This guide covers the operator itself, the three different places in Power BI where you will need it, the step-by-step way to build an exclusion filter, and the blank-value behaviour that catches almost everyone the first time.

What Is the Does Not Equal Sign in Power BI? The Direct Answer

The does not equal sign in Power BI is <> -- a less-than symbol immediately followed by a greater-than symbol, with no space between them.

Microsoft's own DAX operator reference lists it plainly as "Not equal to", alongside =, ==, >, <, >= and <=. It is the only not-equal operator DAX recognises.

So a filter that excludes the West region is written like this:

'Sales'[Region] <> "West"

And one that excludes zero-value rows is written like this:

'Sales'[Amount] <> 0

Three things trip people up straight away. There is no != in DAX, even though it is the standard in SQL, Python and JavaScript -- typing it produces an error rather than a warning. There is no =/= or ≠ either. And the two characters must be adjacent: < > with a space is read as two separate operators and will not parse.

Not sure whether your reports are built on filters that actually hold up? Get a free SEO and analytics audit and find out what your numbers are really telling you.

Where the Not Equal Operator Actually Appears in Power BI

Power BI is really three tools stacked on top of each other, and each layer has its own filtering language. The symbol happens to be the same in two of them and absent from the third, which is why the question keeps coming up.

In DAX measures and calculated columns

This is where <> does most of its work. It appears inside FILTER, inside CALCULATE, and in the boolean conditions of IF and SWITCH.

A measure that sums everything except one region looks like this:

Sales Excluding West = CALCULATE(SUM('Sales'[Amount]), 'Sales'[Region] <> "West")

A calculated column that flags non-standard orders looks like this:

Flag = IF('Orders'[Status] <> "Complete", "Needs review", "OK")

In Power Query and the M language

Power Query uses <> too, but you will rarely type it. The Filter Rows dialog has a dropdown called "Does Not Equal" under Text Filters, Number Filters and Date Filters, and choosing it writes the M for you.

The generated step looks like this:

= Table.SelectRows(Source, each [Region] <> "West")

The practical difference between filtering here and filtering in DAX matters more than the syntax. A Power Query filter removes the rows before they ever reach the model, which makes the dataset smaller and every downstream calculation faster. A DAX filter keeps the rows in the model and hides them at calculation time, which means you can still reference them elsewhere. Exclude permanently unwanted data in Power Query; exclude context-specific data in DAX.

In visual, page and report filters

The filter pane does not use the symbol at all. Instead it offers a condition dropdown with "is not" and "is not blank" options, and a Basic filtering mode where you tick values to include or exclude. Right-clicking a data point in a visual and choosing "Exclude" does the same thing through the interface.

These produce the same result as a <> filter for simple cases. They are easier to audit, because anyone opening the report can see them, and harder to reuse, because they live on one visual rather than in a measure.

How to Build a Does Not Equal Filter, Step by Step

Here is the sequence for the most common case: a measure that excludes one value from a total.

1. Decide which layer the exclusion belongs in. If the rows are never wanted anywhere in the report, go to Power Query. If the exclusion applies to one number only, write a measure.
2. In Report view, right-click your table in the Data pane and choose New measure.
3. Name the measure something that says what it excludes, not how it works. Sales Excluding Internal is useful six months later; Measure 1 is not.
4. Wrap your aggregation in CALCULATE and add the condition as a second argument, separated by a comma.
5. Write the condition as TableName[ColumnName] <> "Value", with the value in double quotes for text and bare for numbers.
6. Check the result against an unfiltered version of the same aggregation. The difference between them should equal the total of the thing you excluded -- if it does not, something else is filtering too.
7. Decide explicitly what should happen to blank rows, which is covered in the next section, and adjust before you publish.

For a Power Query filter the path is shorter: select Transform data, click the dropdown arrow on the column header, choose Text Filters and then Does Not Equal, and type the value. Then open Advanced Editor and read the generated line, because the dialog sometimes adds a case-sensitivity wrapper you did not ask for.

Reports are only as good as the traffic reaching them. Request a free audit and see which pages are actually earning the sessions you are measuring.

The Blank Trap Every Not Equal Filter Hits

This is the part that costs people a day of debugging, and it is documented behaviour rather than a bug.

Microsoft's DAX operator reference states it directly: all comparison operators except strict equal to (==) treat BLANK as equal to the number zero, an empty string, the date 30 December 1899, or FALSE. The documentation gives the equality example -- [Revenue] = 0 is TRUE when Revenue is either zero or blank, while [Revenue] == 0 is TRUE only when it is actually zero.

Flip that round and you get the behaviour of <>, which is where reports go wrong in two opposite directions.

When you exclude a number, blanks disappear with it. 'Sales'[Amount] <> 0 evaluates to FALSE for a blank amount, because blank is being treated as zero. Every row with a missing amount is silently dropped alongside the genuine zeroes. If those blanks represent orders awaiting invoicing, your count just lost them.

When you exclude a text value, blanks survive. 'Sales'[Region] <> "West" evaluates to TRUE for a blank region, because blank is being treated as an empty string and an empty string genuinely is not "West". Every row with no region at all is quietly included in your "everything except West" total.

Both of those are defensible defaults. Neither is usually what the person writing the filter had in mind, and nothing in the interface warns you.

The fix is to say what you mean about blanks instead of inheriting a default. To exclude a value and keep the blanks, write OR('Sales'[Amount] <> 0, ISBLANK('Sales'[Amount])). To exclude a value and also drop the blanks, write AND('Sales'[Region] <> "West", NOT ISBLANK('Sales'[Region])). And if you want a genuinely strict comparison that treats blank as its own thing, negate the strict operator: NOT('Sales'[Revenue] == 0) is not the same filter as 'Sales'[Revenue] <> 0, and the difference is exactly the blank rows.

Make a habit of running COUNTROWS(FILTER('Table', ISBLANK('Table'[Column]))) on any column you are about to filter. If it returns zero, none of this matters. If it returns anything else, you need to make a decision rather than let the operator make it for you.

When to Use the Operator and When to Use Something Else

<> is the right tool for excluding a single known value from a single column. Past that, other patterns read better and break less.

For several values, use NOT with IN rather than chaining conditions. NOT 'Sales'[Region] IN {"West", "Central"} is clearer than two <> conditions joined with AND, and it is far easier to extend when a third region gets added next quarter.

For "everything except the current selection", use ALLEXCEPT or REMOVEFILTERS instead of a hard-coded exclusion. A <> filter with a literal value in it stops being true the moment somebody renames that value in the source system.

For excluding on a pattern rather than an exact match, <> cannot help you at all -- it is an exact comparison. Use NOT CONTAINSSTRING('Sales'[Product], "sample") or build a flag column in Power Query.

For excluding rows that fail a relationship, such as orders with no matching customer, filter on ISBLANK of a related column rather than on <>. The blank is the signal there, not an inconvenience.

Measuring the wrong thing is expensive. Book a free audit and get a clear picture of which channels are worth building a dashboard for.

Limitations and Common Mistakes

A few failure modes come up again and again.

Case sensitivity is inconsistent across layers. DAX text comparison is case-insensitive, so 'Sales'[Region] <> "west" excludes "West" as well. Power Query is case-sensitive by default, so the same filter there will not match a differently-cased value. Data that arrives from more than one source system is where this bites.

Trailing spaces defeat exact comparison entirely. "West " is not "West", and the two look identical in every visual. Trim text columns in Power Query before you filter on them.

Data types have to match. Comparing a text column against a number, or a date column against a text date, produces either an error or a silently empty result depending on context. Check the column's type icon in the Data pane rather than assuming.

Hard-coded values age badly. Every literal string inside a <> filter is a dependency on the source system's spelling. A rename upstream turns a working exclusion into a filter that excludes nothing, and the report keeps rendering without complaint.

Filters stack rather than override. A <> condition inside CALCULATE combines with whatever filter context the visual already applies. If a slicer has already narrowed to one region and your measure excludes that same region, you get blank -- not an error, just an empty cell that looks like missing data.

Finally, <> cannot express "not equal to another column" safely in a calculated column without row context awareness. It works, but it compares within the current row only, which is usually right and occasionally not what somebody expects from a measure.

Not Equal vs the Alternatives in Power BI

A quick comparison of the exclusion options, and when each one earns its place.

• <> in a DAX measure: best for one known value, context-specific, reusable across visuals. Vulnerable to blanks and to renames upstream.
• NOT ... IN { } in DAX: best for two or more values. Same blank caveats, much better readability.
• <> in Power Query: best for rows that should never enter the model. Reduces file size and refresh time. Cannot be varied per visual.
• Filter pane "is not": best for one-off exploration and for filters a report consumer should be able to see and change. Does not travel with a measure.
• Right-click Exclude on a visual: fastest for ad-hoc analysis. Creates a visual-level filter that is easy to forget about and hard to find later.
• ISBLANK and NOT ISBLANK: the correct tool whenever the thing you are excluding is absence itself rather than a value.

The general rule: exclude as early in the chain as the business logic allows. Power Query beats DAX, and DAX beats a visual-level filter, because each step earlier is one fewer place for the rule to be forgotten.

Final Thoughts

The does not equal sign in Power BI is <>, and knowing the symbol is the easy part. The part that determines whether your report is trustworthy is knowing that <> treats blank as zero, as an empty string, and as FALSE -- so an exclusion filter will either swallow your blank rows or quietly keep them, depending on whether you are comparing against a number or a string.

Write the operator, then check the blanks, then name the measure after what it excludes. Those three habits turn a filter that happens to work into one that still works after somebody renames a region.

If you are writing more than the occasional exclusion, it is worth getting fluent in the surrounding syntax too -- our guide on how to write DAX functions in Power BI covers measures, filter context and the handful of functions that do most of the work in a real model.

Getting the data right is half the job; getting found is the other half. Start with a free audit and see where your organic growth is actually going to come from.