Solving the problem by using SQL
T-SQL has two functions that are helpful in such scenarios:
- TRY_CONVERT()
- This one tries to convert a value to a target data type. If it fails, it returns NULL.
- ISNUMERIC()
- Checks if a value is a numeric value. If yes, it returns 1. Otherwise, 0.
Based on this knowledge, I wrote a query to separate the values into two columns. One with the numbers and one with the text:
SELECT [Values]
,TRY_CONVERT(decimal(18, 5), [Values]) AS [Number]
,IIF(ISNUMERIC([Values]) = 0, [Values], NULL) AS [Text]
FROM [dbo].[MixedValues];
The result is the following table:

If you look carefully, you see that row 17 is recognized as a text.
This is because the number contains a blank.
I will come back to this later on.
Switching to Power Query – Trying IsNaN()
Now, I loaded the Excel into Power Query.
I defined the column as Text and started working on this challenge.
The first attempt uses the Number.IsNaN() function.
This function returns true if the value is NaN. “NaN” is a placeholder for not applicable, for example, because of a division by 0.
I tried this to determine whether a text is equivalent to NaN.
This is the M-Code for the calculated column:
if Number.IsNaN([Value]) = true
then [Value]
else null
The result surprised me:

Strangely, the result is that it cannot convert a number to a number.
I suppose this happens because the column’s data type is text.
Then, I tried converting the column to a number and applying the IsNaN() function to the result:
if Number.IsNaN(Number.From([Value])) = false
then Number.From([Value])
else null
Now, the numbers are converted to numbers, but the text values result in an error:

Now the logic works for numbers.
But the conversion fails for the rows containing text. This results in rows with errors.
Trying Value.Is() in Power Query
Let’s try another function: Value.Is()
This function checks whether a value is compatible with a data type.
This should be equivalent to the ISNUMERIC() function shown above:
if Value.Is([Value], Number.Type) = true
then Number.From([Value])
else null
Unfortunately, this function failed to return the expected result as well:

When I tried the same approach as above, by converting the value to a number first, I got the same result as before:

Therefore, I suspect that the function Value.Is() expects a number data type, but this makes no sense to me.
At this point, I didn’t have time for deeper research, as I was running short on time.
It was time to switch the approach.
Switching concept
Now I explored how to catch errors in Power Query.
My idea was: What if I could catch the conversion error and use this information?
I found this page with useful information: Errors – PowerQuery M | Microsoft Learn
From this, I deduced this expression:
try Number.From([Value]))
After adding a calculated column with this expression, I got this result:

I was optimistic, as I didn’t get an error.
Next, was to expand the Records:

I didn’t need the Error columns—only the Value column.
This is the result after the expansion:

Notice that I renamed the columns directly in the ExpandRecordColumn() function.
Otherwise, I would have gotten a column named [Value.1].
This result was the first where I didn’t get any errors.
Now, I added a calculated column to check if the new column is empty. If yes, then the original Value column contained a text:
if [Numeric Value] = null then [Value] else null
Here, the result:

After setting the correct data types and removing the original Value column, I got this table:

Handle the number with blanks
But we still have row 17, which contained a number with a blank.
How did I handle this?
The most straightforward approach was to remove any Blank from the column Value:

But I had to add this step before starting the steps for separating the two value types:

After adding this step, row 17 is recognized as a number and stored correctly.
Here is the data after loading it into Power BI:

But this only worked if the text values were single words. It didn’t work when sentences or multiple words were stored there.
Conclusion
This was a fascinating excursion into how Power Query, or the M-language, works with data types.
I’m still unsure about the causes of the errors.
But I learned how to handle errors, or how to use the try call and handle the output.
This was very helpful.
Anyway, as you see with the original value in row 17, data quality is paramount.
I have another client where users from different countries are working on the same Excel file with their own number formats.
This is a nightmare because Excel is highly tolerant of data types. It accepts everything, even when the column is formatted as a number.
In that situation, I must force users to use Excel’s formatting options to ensure that numbers are consistently recognized as such.
Without this, I have no chance to import this data into Power BI without a lot of effort to clean up the numbers.
And stay assured that users always find a way to mess up with numbers in Excel.
References
The Data is created with random numbers and words.
Here is the reference for the M-Language: Power Query M formula language reference – PowerQuery M | Microsoft Learn