Waarom datakwaliteit in Power BI bij Power Query begint
Power BI kan pas betrouwbare informatie tonen wanneer de aangeleverde gegevens voldoende compleet, consistent en controleerbaar zijn. Power Query is de omgeving waarin bronnen verbonden en tabellen getransformeerd kunnen worden voordat zij in het gegevensmodel worden gebruikt. Binnen Power BI Desktop is de Power Query-editor bereikbaar via de functie voor het transformeren van gegevens. Daar worden bewerkingen als afzonderlijke stappen bewaard, zodat een transformatie bij latere gegevensverversingen opnieuw kan worden uitgevoerd.
De grootste fout is Power Query uitsluitend te beschouwen als een hulpmiddel om kolommen te verwijderen. In werkelijkheid vormt het vaak een belangrijk deel van de gegevenskwaliteitsketen. Een verkeerd geïnterpreteerde datum, een ontbrekende orderregel of een onjuiste koppeling kan iedere volgende DAX-measure beïnvloeden. Een rapport dat snel laadt en er professioneel uitziet, blijft onbetrouwbaar wanneer de onderliggende records niet kloppen.
Wat gebeurt er tussen bron en rapport?
Een Power BI-rapport heeft doorgaans een verbinding met brongegevens, een reeks transformaties, een semantisch model en visualisaties. Power Query bevindt zich vooral in de fase van ophalen en transformeren. De volgorde van stappen is relevant. Een kolom kan bijvoorbeeld eerst worden hernoemd, daarna als datum worden geïnterpreteerd en vervolgens worden gebruikt om op boekjaar te filteren. Wanneer de bron plotseling een andere kolomnaam levert, kan een afhankelijke stap mislukken.
Niet iedere kwaliteitscontrole hoort in Power Query thuis. Een controle op het totale aantal ingekochte producten kan in het bronsysteem worden uitgevoerd, terwijl een validatie op dubbele klantnummers in de datatransformatie plaatsvindt. Een afwijking tussen gerapporteerde omzet en het grootboek vraagt bovendien om een inhoudelijke controle van definities. Een goede gegevensketen bevat daarom controles op meerdere plaatsen, niet slechts één scherm met groene vinkjes.
Datatypen en regionale instellingen
Datatypen zijn essentieel voor een correcte analyse. Een getal dat als tekst is ingelezen kan in berekeningen onbedoelde problemen veroorzaken. Een datum in de notatie 03/04/2026 is zonder expliciete locale ambigu: afhankelijk van de interpretatie kan maart of april bedoeld zijn. In Power Query kan een kolom worden omgezet naar het gewenste type, eventueel met een geselecteerde landinstelling wanneer de bronnotatie daarom vraagt.
Bij een bronstap Source kan een transformatie in M er bijvoorbeeld als volgt uitzien: Table.TransformColumnTypes(Source, {{"Orderdatum", type date}, {"Bedrag", type number}}). Deze bewerking zet kolomtypen om, maar is niet automatisch een garantie dat iedere tekstwaarde volgens de juiste cultuur wordt geïnterpreteerd. Test daarom waarden die bewust verwarrend zijn, zoals 01/02/2026, en bedragen met decimale komma’s en punten. Controleer de gegevens vóór en na de omzetting en leg vast welke bronnotatie officieel geldt.
Kolomkwaliteit, profiel en distributie
De Power Query-editor kan informatie tonen over geldige waarden, fouten en lege waarden. Deze hulpmiddelen ondersteunen het opsporen van afwijkingen, maar de profielweergave kan afhankelijk van instellingen zijn gebaseerd op een deel van de gegevens. Een kolom die in de eerste records geen fouten heeft, kan verderop alsnog afwijkende waarden bevatten. Voor een echte acceptatiecontrole moet duidelijk zijn of de beoordeling op de volledige dataset of op een steekproef is uitgevoerd.
Een eenvoudige casus is een veld Orderstatus dat alleen ‘Open’, ‘Geleverd’ en ‘Geannuleerd’ hoort te bevatten. Wanneer daarnaast ‘Gereed’, ‘Afgerond’ en een lege waarde voorkomen, moet worden bepaald of die varianten correct zijn. Het blind vervangen van alle onbekende waarden door ‘Open’ vervalst de bronbetekenis. Een betere oplossing is een expliciete vertaal- of controletabel, met een apart signaal voor waarden die nog niet in de definitie voorkomen.
Omgaan met ontbrekende waarden
Een lege waarde kan verschillende betekenissen hebben. Bij Einddatum kan leeg betekenen dat een contract nog actief is; bij Klantnummer kan hetzelfde betekenen dat een essentiële relatie ontbreekt. Het is onjuist om iedere nullwaarde automatisch door nul of een standaardtekst te vervangen. Bepaal per kolom wat een ontbrekende waarde betekent en welk effect dit op rapportages mag hebben.
Maak kritieke velden expliciet. Een order zonder ordernummer kan bijvoorbeeld worden afgewezen of apart in een foutenoverzicht terechtkomen. Een niet ingevulde opmerking kan probleemloos blijven ontbreken. Documenteer deze beslissingen. Een dashboard dat stilzwijgend records met ontbrekende waarden wegfiltert, kan een te rooskleurig beeld van de datakwaliteit geven.
Duplicaten zijn niet altijd fouten
Power Query biedt mogelijkheden om dubbele regels te verwijderen. Toch is een duplicaat alleen te definiëren met kennis van het gegevensmodel. Twee orderregels met hetzelfde ordernummer kunnen legitiem zijn wanneer het verschillende producten betreft. Twee regels met dezelfde combinatie van ordernummer en regelnummer kunnen daarentegen mogelijk dubbel zijn. Een deduplicatiestap die alleen op Ordernummer kijkt, kan daarom echte omzet verwijderen.
Bij financiële gegevens verdient het de voorkeur de identificerende sleutel vooraf vast te leggen. Maak een overzicht van het aantal records vóór en na het verwijderen van duplicaten. Analyseer welke records verdwijnen en laat een inhoudelijke eigenaar bevestigen of deze terecht zijn verwijderd. Het aantal verminderde rijen is een controlepunt, geen bewijs van succes.
Fouten registreren in plaats van verbergen
Een conversiefout is informatie. Een datumwaarde als ‘onbekend’ die niet naar een datum kan worden geconverteerd, moet worden beoordeeld. Het volledig verwijderen van rijen met fouten kan de uiteindelijke cijfers vertekenen. In sommige processen is het juist verstandig een apart foutenoverzicht te maken en de betrokken bronrecords terug te koppelen aan de eigenaar. Een rapport krijgt dan niet alleen een ververstijdstip, maar ook een controle op de kwaliteit van wat is verwerkt.
Bij terugkerende verwerking hoort een drempelwaarde. Een enkel record met een onjuist telefoonnummer heeft een ander effect dan honderd onbruikbare omzetregels. Definieer daarom welke fouten publicatie blokkeren en welke waarschuwingen zijn. Maak zichtbaar wie besluit dat gegevens ondanks een geconstateerde afwijking toch voor analyse mogen worden gebruikt.
Tabellen samenvoegen: sleutels eerst beoordelen
Bij samenvoegen worden rijen uit verschillende tabellen op basis van een of meerdere kolommen gekoppeld. In Power Query komt dit overeen met een merge-operatie. Het is belangrijk vooraf te onderzoeken of de sleutelwaarden uniek zijn waar dat wordt verwacht. Wanneer dezelfde klant tweemaal in de klantenbron voorkomt, kan het koppelen aan transacties tot onverwachte vermenigvuldiging van rijen leiden.
Controleer daarom eerst aantallen, unieke sleutels en ontbrekende matches. In een orderbestand met duizend regels hoort een koppeling met een unieke klantentabel niet zonder verklaring het aantal orderregels te verdubbelen. Houd onderscheid tussen een inner join, die niet-gematchte regels kan uitsluiten, en een left outer join, die de regels uit de linkertabel behoudt. De juiste keuze hangt af van de vraag en het gewenste foutenbeleid.
Toevoegen van tabellen en schemawijzigingen
Bij maandelijks aangeleverde CSV-bestanden kan het toevoegen van tabellen, oftewel append, handig zijn. De bronbestanden moeten dan vergelijkbare kolommen en betekenissen hebben. Wanneer in een nieuwe maand een kolom ‘Prijs’ wordt gewijzigd naar ‘Verkoopprijs’, kan een append twee afzonderlijke kolommen opleveren of kan een latere stap onverwacht werken. Test daarom schemawijzigingen en gebruik herkenbare velddefinities.
Bij grotere processen is een expliciet bronschema nuttig: vereiste kolommen, datatypen, toegestane waarden en betekenis. Bewaar informatie over de aanleverdatum en bronbestandsnaam zodat afwijkende records herleidbaar blijven. Dit maakt correctie van een foutieve maandexport mogelijk zonder het volledige rapportageproces handmatig te reconstrueren.
Query folding en verwerkingsprestaties
Bij geschikte bronnen kan Power Query transformaties terugduwen naar de bron, bijvoorbeeld een relationele database. Dit wordt query folding genoemd. Hierdoor hoeft minder data onnodig te worden opgehaald. Niet iedere stap ondersteunt dezelfde vorm van folding; dat hangt af van de connector, de bron en de gebruikte transformatie. De volgorde van stappen kan daarom invloed hebben op de prestaties.
Een praktische controle is om eerst onnodige kolommen te verwijderen en bronfilters tijdig toe te passen waar dat logisch en ondersteund is. Let er wel op dat vroeg filteren geen relevante historie uitsluit. Prestatieoptimalisatie mag niet ten koste gaan van de betekenis van het resultaat. Meet de feitelijke verwerking en controleer met broncijfers of na optimalisatie dezelfde gegevens beschikbaar blijven.
Praktijkvoorbeeld: verkooprapportage met retouren
Een organisatie levert wekelijks een export met verkooporders en retouren. De rapportage bevat soms te hoge omzetcijfers doordat geretourneerde orders als positieve verkopen worden meegenomen. De eerste stap is het vastleggen van een duidelijke omzetdefinitie: zijn retouren negatieve verkoopbedragen, worden creditnota’s apart opgenomen en welke boekingsdatum geldt voor het rapport? Power Query kan de bestanden vervolgens inlezen, noodzakelijke velden controleren en de gegevens naar een consistente structuur transformeren.
Na verwerking vergelijkt de financiële afdeling het totaal per week met het bronsysteem. Er wordt daarnaast gekeken naar het aantal orders, retourregels en ontbrekende klantrelaties. Wanneer de verschillen groter zijn dan een afgesproken grens, wordt het rapport niet zonder waarschuwing vrijgegeven. De kwaliteit blijkt niet uit een snelle refresh, maar uit het aantoonbaar aansluiten van de cijfers op de afgesproken bron en definitie.
Verversen en gegevensgateway
Een rapport dat lokaal correct ververst, hoeft dat in de Power BI Service niet automatisch te doen. De gebruikte bronverbinding, identiteiten en eventueel een on-premises datagateway kunnen invloed hebben op geplande verversingen. Controleer rechten, beschikbare bronnen en foutmeldingen in de service. Een ontbrekende gatewayverbinding is een technisch probleem; een verkeerd geboekt orderbedrag is een inhoudelijk probleem. Beide moeten afzonderlijk zichtbaar zijn.
Registreer bij een productieproces wanneer voor het laatst succesvol is ververst en wat de verwachte aanlevertijd van de bron is. Een rapport met gisteren als laatste succesvolle verwerking kan voor maandrapportages bruikbaar zijn, maar voor een operationeel voorraadproces onacceptabel. De vereiste actualiteit is daarmee een zakelijke afspraak die in het beheer moet worden opgenomen.
Controlelijst voor een betrouwbare Power Query-keten
Controleer per bron de eigenaar, verversfrequentie en het verwachte schema. Leg kritieke datatypen en unieke sleutels vast. Meet hoeveel records binnenkomen, worden verwijderd, worden samengevoegd en als fout worden aangemerkt. Vergelijk minimaal één inhoudelijke totaalsom met het bronsysteem. Test een ongeldige datum, een ontbrekende verplichte waarde en een onverwachte extra kolom. Controleer tot slot de geplande refresh met een account en verbinding die geschikt zijn voor productie.
Power BI, AI en gerichte scholing
AI en Copilot kunnen helpen bij het verkennen van M-transformaties of het formuleren van mogelijke datakwaliteitscontroles. Automatisch voorgestelde code verdient beoordeling op de betekenis van bronkolommen en het effect op records. De kern van dit onderwerp is Power Query en betrouwbare data engineering, niet generatieve AI. Daarom is een Power BI Basis- of verdiepende Power Query-training de natuurlijke vervolgstap. Bekijk de cursus Power BI Basis →
Conclusie
Betrouwbare Power BI-rapportages beginnen met een herhaalbaar, controleerbaar transformatieproces. Datatypen, ontbrekende waarden, sleutels, samenvoegingen en foutafhandeling verdienen evenveel aandacht als de uiteindelijke visualisaties. Power Query maakt de bewerkingen reproduceerbaar, maar de organisatie moet nog steeds bepalen welke gegevens en uitkomsten correct zijn.