DAX-fout "Cannot convert value" oplossen (2026)

De fout “Cannot convert value … of type Text” betekent dat DAX tekst gebruikt op een plek waar een getal of booleaanse waarde nodig is. Zoek eerst de kolom en probleemwaarde, corrigeer daarna het bron- of modeldatatype, of herschrijf de vergelijking zodat beide kanten hetzelfde betekenisvolle type hebben.

Welke conversiefout zie je?

Deze foutfamilie verschijnt meestal in een van drie vormen:

• Cannot convert value '…' of type Text to type Number: een berekening verwacht een getal, maar krijgt tekst die niet als getal kan worden gelezen.
• Cannot convert value '…' of type Text to type True/False: een logische positie krijgt losse tekst in plaats van een expressie die TRUE of FALSE oplevert.
• DAX comparison operations do not support comparing values of type Text with values of type Integer: de twee kanten van een vergelijking hebben onverenigbare typen.

De formule kan hierbij syntactisch geldig zijn. Power BI begrijpt de functies en haakjes, maar loopt pas tijdens de evaluatie tegen een verkeerd datatype aan. Krijg je een parsermelding voordat de formule wordt geaccepteerd, gebruik dan de decoder voor “The syntax for … is incorrect”.

Verwar de Text-to-True/False-variant ook niet met “A True/False expression does not specify a column”. Die tweede melding gaat specifiek over een ongeldig filterargument van CALCULATE of CALCULATETABLE, niet over tekst die naar Boolean moet worden omgezet.

Controleer eerst of de fout uit DAX of Power Query komt

De plek van de melding bepaalt welke taal je moet repareren:

• Zie je de fout in de DAX-formulebalk van een measure of berekende kolom, dan herstel je een DAX-expressie of het modeldatatype.
• Zie je de fout bij Toegepaste stappen in Power Query, vaak als Expression.Error: We cannot convert ... to type Number, dan herstel je de M-query, de locale of de brondata.
• Zie je foutwaarden pas na vernieuwen, open dan de eerste Power Query-stap waar ze ontstaan en controleer vervolgens het geladen modeltype.

VALUE, CONVERT en FORMAT zijn DAX-functies. Ze horen niet in Power Query M. Omgekeerd zijn Number.FromText, Logical.FromText en Table.TransformColumnTypes M-functies en geen DAX.

Stap voor stap de DAX-conversiefout oplossen

1. Noteer de volledige melding en probleemwaarde

Neem de tekst tussen de aanhalingstekens letterlijk over. Een waarde als N/B, -, 2026Q2, een lege tekenreeks of 1.234,56 vertelt vaak direct welke bronrij afwijkt. Controleer ook of onzichtbare spaties of een afwijkend scheidingsteken aanwezig zijn.

2. Bepaal welk type de expressie verwacht

Zoek de eerste operator of functie rond de verdachte kolom:

• rekenoperatoren zoals +, -, * en / verwachten numerieke waarden;
• ||, &&, IF en voorwaarden in SWITCH(TRUE(), ...) verwachten booleaanse expressies;
• een vergelijking hoort typen te vergelijken die samen geldig zijn;
• FORMAT retourneert altijd tekst, ook als de invoer numeriek was.

Microsoft documenteert in de DAX-operatorreferentie dat Numeric met Numeric, Boolean met Boolean en String met String kunnen worden vergeleken. Andere gemengde vergelijkingen kunnen een fout geven, waaronder het voorbeeld "1" > 0.

3. Isoleer de eerste plek waar de typen samenkomen

Splits een lange formule tijdelijk op in variabelen:

Controle waarde =
VAR Bronwaarde =
    SELECTEDVALUE(Orders[BedragTekst])
VAR Grenswaarde =
    100
RETURN
    Bronwaarde > Grenswaarde

Vervang voor de diagnose tijdelijk de laatste regel door RETURN Bronwaarde en zet de measure op een kaart. SELECTEDVALUE retourneert standaard BLANK() wanneer nul of meerdere onderscheidende waarden zichtbaar zijn. Dat kan op een probleem met de filtercontext wijzen; de single-value-decoder helpt je dan verder. Bekijk daarnaast het datatype van Orders[BedragTekst] in de modelweergave.

4. Bepaal de betekenis van de kolom

Een waarde met cijfers is niet automatisch een getal:

• 00123 als productcode is tekst, omdat een voorloopnul betekenis heeft;
• 2026 als kalenderjaar kan een geheel getal zijn;
• 2026Q2 is een tekstlabel;
• 1.234,56 is getaltekst die alleen met de juiste locale betrouwbaar wordt geïnterpreteerd;
• Ja en Nee zijn tekstcodes, geen booleaanse waarden.

De semantiek bepaalt de conversierichting. Maak een code niet numeriek alleen om één formule groen te krijgen.

5. Controleer de hele kolom op afwijkingen

Filter in Power Query op waarden die niet bij het beoogde type passen. Controleer lege tekst, spaties, labels, foutwaarden, decimaaltekens en bronwijzigingen. Eén afwijkende rij kan genoeg zijn om een berekende kolom met VALUE te laten falen.

6. Herstel structureel of lokaal

Kies:

• Power Query of de bron als de hele kolom altijd hetzelfde type hoort te hebben;
• een expliciete DAX-vergelijking als de kolom bewust tekst blijft;
• VALUE of CONVERT als een lokale expressie aantoonbaar geldige invoer krijgt;
• een expliciete mapping voor domeinwaarden als Ja/Nee, Y/N of statuscodes.

Lees bij een volgende, andersoortige melding ook het overzicht van DAX-foutmeldingen.

7. Test meer dan één voorbeeldrij

Test minimaal:

1. een normale waarde;
2. een lege waarde;
3. de genoemde probleemwaarde;
4. een waarde met een komma of punt;
5. een detailrij en een totaal;
6. een handmatige en geplande refresh;
7. een waarde met een voorloopnul als je codes gebruikt.

Een oplossing is pas betrouwbaar als dezelfde datacontracten na vernieuwen blijven gelden.

Oplossing 1: vergelijk tekst en getal niet door elkaar

Deze berekende kolom vergelijkt een tekstcode met een geheel getal:

Is product 123 =
Product[Productcode] = 123

Als Productcode een identificatiecode is, houd je beide kanten tekst:

Is product 123 =
Product[Productcode] = "123"

Zo blijven waarden als 00123 intact. Is de kolom inhoudelijk werkelijk numeriek, wijzig dan bij voorkeur het datatype in de bron of Power Query. Alleen wanneer alle relevante waarden geldig zijn, kun je lokaal converteren:

Is product 123 =
VALUE(Product[Productcode]) = 123

De officiële VALUE-documentatie waarschuwt dat onherkenbare tekst een fout geeft. Wanneer je VALUE op een kolom met zowel getaltekst als andere tekst toepast, kan de hele berekende kolom als fout worden gemarkeerd.

Oplossing 2: maak een structurele getalkolom in Power Query

Hoort iedere waarde in Bedrag een getal te zijn, dan is één conversie vóór het laden beter dan dezelfde omzetting in meerdere measures:

Table.TransformColumnTypes(
    Source,
    {{"Bedrag", type number}},
    "nl-NL"
)

Het cultuurargument bepaalt hoe tekst wordt geïnterpreteerd. In dit voorbeeld past nl-NL bij een komma als decimaalteken. De officiële documentatie voor Table.TransformColumnTypes bevestigt dat de functie een optionele culture accepteert.

Wil je eerst ontdekken welke rijen niet converteren, voeg dan tijdelijk een diagnosekolom toe:

Table.AddColumn(
    Source,
    "Bedrag controle",
    each try Number.FromText([Bedrag], "nl-NL")
)

Een try-expressie levert een record met onder meer HasError, Value en Error. Vouw dat record uit en herstel de afwijkende bronwaarden. De Microsoft-uitleg over foutafhandeling in Power Query laat zien hoe je zulke records onderzoekt.

Je kunt try Number.FromText([Bedrag], "nl-NL") otherwise null gebruiken wanneer null een bewuste businessregel voor ongeldige invoer is. Gebruik dit niet als snelle manier om datakwaliteitsproblemen onzichtbaar te maken.

Oplossing 3: gebruik VALUE en CONVERT alleen gericht

VALUE converteert herkenbare getaltekst naar een decimaal getal:

Bedrag numeriek =
VALUE(Orders[BedragTekst])

CONVERT maakt het doeltype expliciet:

Aantal numeriek =
CONVERT(Orders[AantalTekst], INTEGER)

Volgens Microsoft ondersteunt CONVERT onder meer BOOLEAN, DOUBLE, INTEGER en STRING. De functie geeft nog steeds een fout wanneer een waarde niet kan worden geconverteerd. Een berekende kolom moet bovendien één datatype hebben.

Zet daarom niet gedachteloos iedere verdachte expressie in IFERROR(VALUE(...), BLANK()). Daarmee verdwijnen ongeldige rijen uit je uitkomst zonder dat de bron is hersteld. Microsoft adviseert in de best practices voor DAX-foutfuncties om ongeldige waarden waar mogelijk in Power Query op te schonen en het juiste datatype in te stellen.

In DirectQuery zijn CONVERT en IFERROR niet ondersteund in berekende kolommen en RLS-regels. Deze vermelding geldt niet automatisch voor iedere measure, maar een correct brontype blijft de veiligste basis.

Oplossing 4: schrijf iedere logische voorwaarde volledig uit

Hier ontstaat Text-to-True/False doordat alleen de eerste status wordt vergeleken:

Statusgroep =
IF(
    Orders[Status] = "Open" || "In behandeling",
    "Actief",
    "Gesloten"
)

De operator || verwacht links en rechts een expressie die TRUE of FALSE oplevert. "In behandeling" is alleen tekst. Herhaal daarom de vergelijking:

Statusgroep =
IF(
    Orders[Status] = "Open"
        || Orders[Status] = "In behandeling",
    "Actief",
    "Gesloten"
)

Voor een vaste lijst is IN compacter:

Statusgroep =
IF(
    Orders[Status] IN { "Open", "In behandeling" },
    "Actief",
    "Gesloten"
)

Hetzelfde geldt voor &&: iedere operand moet een complete booleaanse voorwaarde zijn.

Oplossing 5: geef IF een echte voorwaarde

Deze formule gebruikt de tekstkolom zelf als logische test:

Statusgroep =
IF(
    Orders[Status],
    "Actief",
    "Gesloten"
)

Het eerste argument van IF moet naar TRUE of FALSE kunnen worden geëvalueerd. Maak de businessregel expliciet:

Statusgroep =
IF(
    Orders[Status] = "Open",
    "Actief",
    "Gesloten"
)

Bevat de bron een vlag met Ja en Nee, zet die dan bij voorkeur in Power Query om naar het type True/False. Moet de mapping bewust in een berekende DAX-kolom blijven, behandel onverwachte waarden apart:

Is actief =
VAR Vlag =
    LOWER(TRIM(Orders[ActiefTekst]))
RETURN
    SWITCH(
        Vlag,
        "ja", TRUE(),
        "nee", FALSE(),
        BLANK()
    )

BLANK() maakt een onbekende invoer zichtbaar als ontbrekende uitkomst. Controleer zulke rijen in plaats van ze automatisch als FALSE() te behandelen.

Oplossing 6: houd numerieke resultaten numeriek

Deze measure vermengt een getal en een tekstlabel:

Omzet resultaat =
IF(
    [Heeft omzet],
    [Omzet],
    "N/B"
)

Een measure kan in sommige gevallen een variant retourneren, maar een tekstvertakking maakt vervolggebruik en visualisaties onnodig kwetsbaar. Houd de uitkomst numeriek:

Omzet resultaat =
IF(
    [Heeft omzet],
    [Omzet],
    BLANK()
)

Gebruik FORMAT niet om een rekenfout te repareren. Microsoft vermeldt bij FORMAT dat het resultaat altijd tekst is. Een oorspronkelijk numerieke measure kan daardoor niet meer op een numerieke waarde-as worden gebruikt. Gebruik modelopmaak of een dynamische opmaakreeks als alleen de presentatie moet veranderen.

Power Query: een tekstvlag naar True/False omzetten

Power Query gebruikt het type logical. Logical.FromText accepteert de teksten "true" en "false", ongeacht hoofdletters:

Logical.FromText([Actief])

Waarden als Ja, Nee, Y en N hebben een expliciete mapping nodig:

if Text.Lower(Text.Trim([Actief])) = "ja" then true
else if Text.Lower(Text.Trim([Actief])) = "nee" then false
else null

Typ de uiteindelijke kolom als True/False en controleer de null-rijen. Zo komt één consistente booleaanse kolom in het model terecht.

Veelgemaakte fouten

• FORMAT gebruiken om tekst numeriek te maken. FORMAT doet het omgekeerde en levert tekst op.
• VALUE om de hele kolom zetten zonder afwijkingen te zoeken. Eén label of verkeerd scheidingsteken kan de berekende kolom laten falen.
• Iedere fout met IFERROR(..., BLANK()) verbergen. Je verliest dan informatie en totalen kunnen ongemerkt te laag worden.
• Een identificatiecode als getal modelleren. Voorloopnullen en vaste tekenlengtes kunnen betekenisvol zijn.
• "TRUE" behandelen als TRUE(). De eerste waarde is tekst, de tweede booleaans.
• Alleen de eerste OR-voorwaarde uitschrijven. Beide kanten van || moeten een complete logische expressie zijn.
• Een localeprobleem met losse SUBSTITUTE-stappen omzeilen. Een expliciete culture is veiliger wanneer punt en komma verschillende rollen hebben.
• Alleen in Power BI Desktop testen. Controleer ook refresh, Power BI Service en nieuwe bronwaarden.

Zo voorkom je nieuwe datatypefouten

Leg per bronkolom vast wat de betekenis en het toegestane datatype zijn. Typ kolommen expliciet in Power Query, gebruik een vaste locale voor tekstconversie en houd foutregels zichtbaar tot je de oorzaak kent.

Geef measures daarna consistente resultaattypen en vergelijk codes alleen met codes. Komt de formule uit Excel, controleer dan ook de verschillen in impliciete conversie via Excel-formule naar DAX. Bekijk voor de overige foutdecoders en praktische handleidingen de Power BI-hub.