DAX-fout "Column cannot be found" oplossen (2026)

De fout “Column '…' in table '…' cannot be found or may not be used in this expression” betekent dat DAX je verwijzing niet kan koppelen aan een geldige modelkolom voor die plek in de formule. Controleer eerst de exacte kolomnaam en eigenaarstabel en bepaal daarna of het functieargument werkelijk een bestaande kolom verlangt in plaats van een measure, expressie of virtuele alias.

Wat zegt de melding precies?

De fouttekst combineert twee mogelijke problemen:

1. Cannot be found: de benoemde kolom bestaat niet onder die naam in de opgegeven modeltabel.
2. May not be used in this expression: het object bestaat mogelijk wel, maar de functie of formulepositie vereist een ander soort argument.

Dit is meestal een bindingsfout. Power BI probeert tijdens het valideren van de DAX-formule vast te stellen naar welk modelobject iedere naam verwijst. De engine komt niet eens toe aan de inhoudelijke berekening als die koppeling mislukt.

Dat onderscheidt deze melding van drie verwante fouten:

• Bij “The syntax for … is incorrect” kan de parser de formulevorm niet lezen.
• Bij “A single value for column cannot be determined” is de kolom gevonden, maar zijn meerdere waarden mogelijk.
• Bij “Cannot convert value” is de waarde gevonden, maar past het datatype niet.

Zie je de fout alleen bij bepaalde Viewers in Power BI Service, controleer dan Object-Level Security. Zie je in de Power Query-editor Expression.Error: The column ... wasn't found, dan gaat het om een M-stap en niet om een DAX-verwijzing.

Controleer of de kolom werkelijk in het model staat

Power Query en DAX zien niet automatisch dezelfde tussenstappen. Een kolom kan in een vroege Power Query-stap bestaan en daarna zijn:

• hernoemd;
• verwijderd;
• samengevoegd in een andere kolom;
• uitgesloten doordat een query niet voor laden is ingeschakeld;
• niet doorgevoerd omdat wijzigingen nog niet zijn toegepast.

Open eerst de modelweergave of het gegevensvenster van Power BI en zoek daar naar de exacte tabel en kolom. De DAX-formule kan alleen verwijzen naar het uiteindelijke model, niet naar een tijdelijke naam uit een eerdere M-stap.

Stap voor stap de kolomfout oplossen

1. Kopieer de exacte tabel- en kolomnaam uit de melding

Let op spaties, accenten, enkelvoud en meervoud. DAX-objectnamen zijn niet hoofdlettergevoelig, maar een ontbrekende spatie of andere schrijfwijze verwijst wel naar een ander object.

2. Controleer het object in de modelweergave

Zoek de kolom onder de tabel die in de fout staat. Controleer ook verborgen velden. Verborgen kolommen mogen in DAX worden gebruikt, maar zijn minder makkelijk terug te vinden in het rapportvenster.

Bestaat de naam alleen in Power Query, ga dan naar de laatste toegepaste stap en controleer de geladen kolomnaam. Pas wijzigingen toe voordat je de DAX-formule opnieuw test.

3. Laat IntelliSense de verwijzing invoegen

Wis de verdachte verwijzing, typ de tabelnaam opnieuw en kies de kolom uit de suggestielijst. Verschijnt de kolom niet, dan is dat sterk bewijs dat de naam of het modelobject niet klopt.

4. Kwalificeer modelkolommen volledig

Schrijf een modelkolom als Sales[Bedrag]. Heeft de tabel spaties of speciale tekens, schrijf dan bijvoorbeeld 'Order Details'[Bedrag].

Microsoft adviseert in de best practice voor kolom- en measureverwijzingen om kolommen altijd volledig te kwalificeren en measures juist niet. Dit maakt direct zichtbaar welk soort object je bedoelt.

5. Lees het functietype van het verdachte argument

In Microsofts DAX-documentatie betekent:

• columnName: een bestaande kolomreferentie, geen berekening;
• tableName: een bestaande modeltabel, geen tabelexpressie;
• expression: een berekening die een scalar oplevert;
• table: een expressie die een tabel oplevert.

De DAX-conventies voor parameternamen maken dat onderscheid expliciet. Een geldige scalar is dus niet automatisch geldig op een positie met columnName.

6. Controleer rijcontext en relaties

Staat de verwijzing in RELATED, controleer dan:

• of er een bestaande relatie is;
• of je vanaf de many-kant naar één gerelateerde rij gaat;
• of er rijcontext is;
• of de relatie niet limited is.

Een losse measure heeft geen automatische huidige rij. Een berekende kolom heeft die wel, en iterators zoals SUMX maken rijcontext voor iedere gescande rij.

7. Isoleer en test de kleinste geldige formule

Vervang een lange formule tijdelijk door een eenvoudige test:

Kolomtest =
MAX(Sales[Bedrag])

Werkt dit, voeg functies dan één voor één terug. Werkt het niet, herstel eerst de modelnaam of tabel. Controleer na een hernoeming ook afhankelijke measures, berekende kolommen, berekende tabellen en RLS-regels.

Bekijk daarna het DAX-foutmeldingsoverzicht als een volgende validatiefout zichtbaar wordt.

Oplossing 1: gebruik de juiste eigenaarstabel

Deze measure zoekt Bedrag onder de verkeerde tabel:

Omzet =
SUM(Customer[Bedrag])

Als de kolom bij Sales hoort, is dit de geldige verwijzing:

Omzet =
SUM(Sales[Bedrag])

Verplaats de kolom niet alleen om de formule te laten werken. Feitentabelwaarden zoals aantallen en bedragen horen meestal bij de feitenrij, terwijl beschrijvende velden zoals productgroep of klantsegment vaak in een dimensietabel staan.

Is de kolom recent hernoemd, kies dan de nieuwe naam via IntelliSense. Een handmatig gekopieerde formule uit een ander model gebruikt vaak tabellen en kolommen die in je eigen model anders heten.

Oplossing 2: schrijf kolomnamen en tabelnamen correct

Volgens de officiële DAX-syntaxisregels staat een kolomnaam tussen rechte haken en komt de tabelnaam ervoor:

Sales[Bedrag]

Een tabelnaam met spaties staat tussen enkele rechte aanhalingstekens:

'Order Details'[Bedrag]

Gebruik geen typografische aanhalingstekens die uit een tekstverwerker zijn gekopieerd. Een ongeldige quote veroorzaakt vaak een syntaxisfout in plaats van de kolommelding, maar kan de oorspronkelijke naamfout maskeren.

Sommige functies vereisen altijd een volledig gekwalificeerde kolom. Microsoft noemt onder meer VALUES, ALL, ALLEXCEPT, filterargumenten van CALCULATE en tijdintelligentiefuncties. Volg daarom het veilige patroon Tabel[Kolom].

Oplossing 3: behandel een measure niet als modelkolom

Een kolom hoort bij één tabel. Een measure is modelbreed uniek en de home table is vooral organisatorisch. Stel dat [Omzet] en [Kosten] measures zijn:

Marge =
DIVIDE(
    Sales[Omzet] - Sales[Kosten],
    Sales[Omzet]
)

Een volledig gekwalificeerde measurereferentie kan geldig zijn zolang de measure in die home table staat, maar breekt wanneer je de home table wijzigt. Schrijf measures daarom zonder tabelkwalificatie:

Marge =
DIVIDE(
    [Omzet] - [Kosten],
    [Omzet]
)

Controleer het pictogram en de eigenschappen van het veld als je niet weet of de naam een kolom of measure is. Voeg niet zomaar SUM rond een measure toe. Microsoft documenteert dat SUM één kolom verwacht. Alleen wanneer je bewust een expressie per rij wilt evalueren, gebruik je een iterator zoals SUMX met een passende tabel.

Oplossing 4: geef LOOKUPVALUE echte kolomargumenten

De tweede parameter van LOOKUPVALUE is search_columnName. Dit moet een bestaande modelkolom zijn:

Gekozen categorie =
VAR GekozenProduct =
    SELECTEDVALUE(Sales[ProductKey])
RETURN
    LOOKUPVALUE(
        Product[Categorie],
        Product[ProductKey] + 0,
        GekozenProduct
    )

Product[ProductKey] + 0 is een expressie en geen kolomreferentie. Daardoor mag deze berekening niet op de positie van search_columnName staan. Gebruik de kolom zelf en zorg dat beide sleutels al het juiste datatype hebben:

Gekozen categorie =
VAR GekozenProduct =
    SELECTEDVALUE(Sales[ProductKey])
RETURN
    LOOKUPVALUE(
        Product[Categorie],
        Product[ProductKey],
        GekozenProduct
    )

De officiële documentatie voor LOOKUPVALUE vermeldt dat zowel result_columnName als search_columnName bestaande kolommen moeten zijn en geen expressies kunnen zijn. Corrigeer een sleuteltype bij voorkeur in Power Query of de bron.

Als meerdere rijen bij dezelfde zoeksleutel verschillende resultaten hebben, krijg je een andere fout. Gebruik dan de decoder voor een tabel met meerdere waarden en herstel de sleutelkwaliteit.

Oplossing 5: gebruik RELATED alleen met relatie en rijcontext

Deze measure probeert zonder rijcontext één gerelateerde productgroep op te halen:

Productgroep =
RELATED(Product[Productgroep])

RELATED heeft volgens Microsoft een bestaande many-to-one-relatie en rijcontext nodig. Als dit een berekende kolom op de many-kant van Sales is en de relatie geldig is, kan dezelfde expressie juist wel werken:

Productgroep =
RELATED(Product[Productgroep])

In een measure moet je eerst bepalen welke uitkomst in de actuele filtercontext hoort. Als precies één productgroep zichtbaar moet zijn:

Zichtbare productgroep =
SELECTEDVALUE(Product[Productgroep])

Gebruik SELECTEDVALUE niet als automatische vervanger als meerdere groepen inhoudelijk geldig zijn. Kies dan een lijst, telling of andere businessregel.

Oplossing 6: kwalificeer een tabelvariabele niet als modeltabel

Deze measure maakt een virtuele kolom met ADDCOLUMNS:

Omzet som =
VAR PerProduct =
    ADDCOLUMNS(
        VALUES(Product[ProductKey]),
        "Omzet per product",
        [Omzet]
    )
RETURN
    SUMX(
        PerProduct,
        PerProduct[Omzet per product]
    )

PerProduct is een variabele met een tabelwaarde, geen geregistreerde modeltabel. Microsoft vermeldt bij VAR expliciet dat kolommen in tabelvariabelen niet met TableName[ColumnName] kunnen worden aangesproken. Gebruik de nieuwe kolom daarom binnen de rijcontext van SUMX zonder de variabelenaam als kwalificatie:

Omzet som =
VAR PerProduct =
    ADDCOLUMNS(
        VALUES(Product[ProductKey]),
        "Omzet per product",
        [Omzet]
    )
RETURN
    SUMX(
        PerProduct,
        [Omzet per product]
    )

De oorspronkelijke modelkolom blijft wel Product[ProductKey] heten. Microsoft beschrijft bij ADDCOLUMNS dat de functie de oorspronkelijke kolommen plus benoemde berekende kolommen retourneert en iedere toegevoegde expressie per rij evalueert.

Oplossing 7: controleer Object-Level Security

Werkt het rapport voor jou, maar zien sommige Viewers in Power BI Service kapotte visuals met precies deze kolomfout? Controleer dan de modelrollen en Object-Level Security, afgekort OLS.

Microsoft legt in de documentatie over Object-Level Security uit dat een beveiligde tabel of kolom voor een gebruiker zonder de vereiste toegang lijkt alsof die niet bestaat. Visuals die dat veld gebruiken tonen dan de melding dat de kolom niet kan worden gevonden of niet in de expressie mag worden gebruikt.

Test met Weergeven als of met een account dat uitsluitend de betrokken Viewer-rol heeft. OLS geldt niet voor workspacebeheerders, Members en Contributors met bewerkrechten, waardoor een beheerder het probleem zelf mogelijk niet ziet. Verwijder de beveiliging niet als snelle reparatie. Pas de visual, het semantische model of de rol bewust aan zonder gevoelige metadata vrij te geven.

Als een measure een met OLS beveiligde kolom gebruikt, kan ook de visual met die measure breken. Inventariseer daarom de volledige afhankelijkheidsketen en test iedere beveiligingsrol na een modelwijziging.

Let op bij DirectQuery en RLS

Een ontbrekende kolom wordt niet opgelost door van opslagmodus te wisselen. DirectQuery kan wel extra beperkingen zichtbaar maken. De functiepagina’s voor onder meer ADDCOLUMNS, LOOKUPVALUE en SELECTEDVALUE noemen beperkingen voor gebruik in DirectQuery-berekende kolommen of RLS-regels. Controleer de ondersteuning per gebruikte functie en trek die beperking niet automatisch door naar measures.

Controleer daarom:

• of de kolom uit de bronquery wordt teruggegeven;
• of een hernoeming in de bron nog overeenkomt met het model;
• of de gekozen functie in je objecttype en opslagmodus wordt ondersteund;
• of een typeconversie en berekening naar de bron kan worden vertaald.

Houd de naamfout en de opslagbeperking apart. Los eerst de objectverwijzing op en beoordeel daarna de DirectQuery-ondersteuning.

Veelgemaakte fouten

• Alleen in Power Query naar de kolom zoeken. DAX gebruikt de uiteindelijke geladen modelkolom.
• Een kolom bij de verkeerde tabel kwalificeren. Dezelfde naam kan in een ander model of voorbeeld bij een andere tabel horen.
• Spaties in een tabelnaam zonder enkele aanhalingstekens schrijven. Gebruik bijvoorbeeld 'Order Details'[Bedrag].
• Een measure als kolom behandelen. Verwijs bij voorkeur naar [Measure] zonder home table.
• Een expressie doorgeven waar columnName staat. Een berekening als Product[Key] + 0 is geen bestaande kolomreferentie.
• RELATED zonder relatie of rijcontext gebruiken. De functie kan dan niet vanaf een huidige rij navigeren.
• Een tabelvariabele als modeltabel kwalificeren. PerProduct[Alias] verwijst niet naar een geregistreerde tabel.
• Alleen als workspacebeheerder testen. OLS geldt voor Viewers, niet voor rollen met bewerkrechten.
• Objectbeveiliging uitschakelen om de visual te herstellen. Daarmee kun je gevoelige metadata onbedoeld vrijgeven.
• Blind een andere functie kiezen. Een gevonden kolom kan daarna nog een context-, cardinaliteits- of datatypeprobleem hebben.

Zo voorkom je gebroken kolomverwijzingen

Gebruik vaste, betekenisvolle modelnamen en hernoem velden via modelbewerkingen die afhankelijkheden kunnen bijwerken. Schrijf modelkolommen volledig gekwalificeerd, measures ongekwalificeerd en laat IntelliSense namen invoegen.

Leg ook vast welke functies een echte kolomreferentie vereisen. Test na bron- of modelwijzigingen niet alleen visuals, maar ook berekende tabellen, RLS en verborgen helpermeasures. Voor verdere praktische DAX-uitleg ga je naar de Power BI-hub.