Power BI is een krachtig rapportage-instrument, maar wie ooit heeft ontdekt dat de cijfers in een dashboard niet overeenkomen met de brondata, weet hoe frustrerend dat kan zijn. Beslissingen worden genomen op basis van die getallen, dus een discrepantie is nooit een klein probleem. Gelukkig zijn de meeste oorzaken van Power BI-datadiscrepantie goed te traceren en op te lossen, als je weet waar je moet kijken. In dit artikel behandelen we zeven veelvoorkomende redenen waarom Power BI-cijfers niet kloppen en wat je eraan kunt doen.
Wanneer Power BI-rapportages afwijken van de werkelijkheid
Afwijkingen tussen Power BI en de brondatabase ontstaan zelden door toeval. Er zit bijna altijd een technische oorzaak achter: een instelling die niet klopt, een transformatie die onbedoeld data weggooit, of een datamodelkeuze die verkeerde berekeningen oplevert. De zeven oorzaken hieronder zijn de meest voorkomende schuldigen. Door ze systematisch te controleren, kom je snel tot de kern van het probleem.
1: Verouderde data door onjuiste vernieuwingsschema’s
Een van de meest voor de hand liggende oorzaken is simpelweg dat de data in Power BI niet actueel is. Als het vernieuwingsschema niet goed is ingesteld, laadt Power BI nog steeds gegevens van gisteren, vorige week, of zelfs een maand geleden, terwijl de brondatabase al lang is bijgewerkt.
Dit probleem speelt met name bij geplande vernieuwingen via de Power BI-service. Als een vernieuwing mislukt, bijvoorbeeld door een time-out of een verbindingsfout, geeft Power BI standaard geen prominente foutmelding in het dashboard zelf. Gebruikers zien dan verouderde cijfers zonder dat ze dat doorhebben.
Controleer altijd de tijdstempel van de laatste succesvolle vernieuwing, die zichtbaar is in de dataset-instellingen van de Power BI-service. Stel daarnaast foutmeldingen per e-mail in, zodat je direct op de hoogte bent als een vernieuwing mislukt. Voor omgevingen waar realtime data cruciaal is, is het de moeite waard om de BI-infrastructuur te evalueren op DirectQuery of hybride verbindingen.
2: Tijdzoneproblemen in datum- en tijdfilters
Tijdzoneproblemen zijn een verraderlijke bron van Power BI-datadiscrepantie, omdat de afwijking klein en inconsistent lijkt. Een rapport toont andere dagcijfers dan de bron, maar alleen voor de eerste of laatste uren van de dag. De oorzaak ligt dan bijna altijd in een verschil in tijdzone-interpretatie.
Power BI slaat datums en tijden intern op in UTC. Als de brondatabase werkt met lokale tijd (bijvoorbeeld CET of CEST), kan er een verschil van een of twee uur ontstaan. Dat klinkt onschuldig, maar bij dagelijkse aggregaties betekent dit dat transacties die om 23:30 lokale tijd plaatsvinden, in Power BI op een andere dag worden geboekt.
De oplossing zit in het expliciet converteren van tijdzones in Power Query of in de bronquery, zodat beide systemen dezelfde tijdreferentie hanteren. Documenteer deze keuze goed, want tijdzone-instellingen zijn makkelijk over het hoofd te zien bij toekomstige aanpassingen aan het datamodel.
3: Wat doet een verkeerde relatie in het datamodel?
Een onjuiste relatie in het datamodel is een van de meest impactvolle oorzaken van afwijkende cijfers, en tegelijk een van de moeilijkst te spotten. Power BI werkt met een sterschema of sneeuwvlokschema, waarbij relaties tussen tabellen de basis vormen voor alle berekeningen.
Veelgemaakte fouten zijn: een veel-op-veel-relatie waar een een-op-veel-relatie bedoeld is, een relatie die in de verkeerde richting filtert, of een actieve relatie die de verkeerde tabel als basis neemt. Het gevolg is dat filters niet correct doorwerken en aggregaties onjuiste resultaten geven, zonder dat er een foutmelding verschijnt.
Gebruik de modelweergave in Power BI Desktop om alle relaties visueel te controleren. Kijk specifiek naar de filterrichting (enkelvoudig of bidirectioneel) en de kardinaliteit. Bij complexe modellen is het aan te raden om een BI-consultancy te betrekken om het datamodel te reviewen voordat het in productie gaat.
4: DAX-formules met onverwachte filtercontext
DAX is de formuletaal van Power BI en biedt enorme flexibiliteit, maar diezelfde flexibiliteit maakt het ook een bron van subtiele fouten. Een DAX-meting die op het eerste gezicht correct lijkt, kan in een andere filtercontext een heel ander resultaat opleveren dan verwacht.
Een klassiek voorbeeld is het gebruik van CALCULATE zonder bewust rekening te houden met de bestaande filtercontext. Of het gebruik van ALL en ALLEXCEPT op manieren die meer filters verwijderen dan de bedoeling was. Het resultaat: een getal dat in het rapport klopt voor de totaalregel, maar afwijkt op rijniveau.
Test DAX-metingen altijd in een eenvoudige tabelvisualisatie met alle relevante dimensies zichtbaar. Vergelijk de uitkomst stap voor stap met de brondata. Tools zoals DAX Studio maken het mogelijk om de queryuitvoer direct te inspecteren en de filtercontext te analyseren, wat het debuggen aanzienlijk versnelt.
5: Afwijkende aggregatielogica tussen bron en rapport
Soms kloppen de ruwe gegevens in Power BI wel degelijk overeen met de bron, maar wijkt de samengevatte waarde af. Dit duidt op een verschil in aggregatielogica: de bron en het rapport tellen, sommeren of middelen op een andere manier.
Een concreet voorbeeld: de brondatabase berekent een gemiddelde verkoopprijs als de totale omzet gedeeld door het totale aantal eenheden. Power BI berekent standaard het gemiddelde van de gemiddelde prijzen per rij, wat bij ongelijke aantallen een ander resultaat geeft. Beide methoden zijn technisch correct, maar ze meten iets anders.
Stem de aggregatielogica expliciet af met de business-eigenaar van het rapport. Leg vast welke definitie leidend is en implementeer die consequent in DAX. Dit is ook het moment om te kijken of de data-integratie tussen systemen uniform is ingericht, zodat definities niet per databron verschillen.
6: Datatypemismatches bij het importeren
Power Query detecteert automatisch datatypes bij het importeren van data, maar die automatische detectie gaat regelmatig mis. Een kolom met orderaantallen wordt als tekst geïmporteerd, een datumkolom als geheel getal, of een decimaal getal wordt afgekapt door een verkeerd type.
Het gevolg van datatypemismatches is dat aggregaties mislukken, filters niet werken, of dat getallen stilzwijgend worden afgerond of afgekapt. Omdat Power BI in veel gevallen geen foutmelding geeft maar gewoon een resultaat toont, is dit type fout lastig te ontdekken zonder gerichte controle.
Controleer in Power Query de datatypes van alle kolommen handmatig, in plaats van te vertrouwen op de automatische detectie. Wees extra alert bij kolommen die alfanumerieke codes bevatten, zoals artikelnummers of klant-ID’s die soms beginnen met nullen. Een verkeerd type kan ervoor zorgen dat koppelingen tussen tabellen stilzwijgend mislukken.
7: Gefilterde rijen door Power Query-transformaties
Power Query is het ETL-hart van Power BI: hier worden gegevens geladen, getransformeerd en gefilterd voordat ze het datamodel bereiken. Juist die transformatiestappen zijn een veelvoorkomende bron van Power BI-datadiscrepantie, omdat rijen kunnen worden verwijderd zonder dat dit direct zichtbaar is in het eindrapport.
Denk aan een stap die lege waarden verwijdert, een filter op een statuskolom die ook geldige records uitsluit, of een samenvoegstap (merge) die rijen laat vallen omdat de sleutels niet overeenkomen. Het totaal in Power BI is dan lager dan in de bron, maar de reden is verborgen in de transformatiegeschiedenis van Power Query.
Gebruik de stap-voor-stap preview in Power Query Editor om te controleren hoeveel rijen er na elke transformatie overblijven. Vergelijk het eindaantal rijen met het verwachte aantal uit de bron. Bij complexe transformaties is het ook de moeite waard om te kijken naar data engineering als structurele oplossing, zodat transformatielogica beter beheerd en gedocumenteerd wordt.
Hoe DBA helpt bij Power BI-datadiscrepanties
Afwijkende cijfers in Power BI zijn bijna nooit een probleem van het rapport zelf, maar van de laag eronder: de database, de data-integratie, of het datamodel. Precies daar ligt onze expertise. Wij combineren diepgaande kennis van Oracle, Microsoft SQL Server en PostgreSQL met geavanceerde Power BI-ervaring, waardoor we discrepanties snel traceren tot op de bron.
- Wij analyseren de volledige dataketen, van brondatabase tot Power BI-dashboard, en identificeren waar afwijkingen ontstaan
- We ontwerpen en implementeren maatwerk Power BI-rapportages met correcte datamodellen, betrouwbare DAX-metingen en gedocumenteerde transformatielogica
- We zorgen voor naadloze integratie tussen databronnen via Microsoft Fabric, Azure Data Factory en andere moderne platforms
- Onze database administrators bewaken de performance en betrouwbaarheid van uw data-omgeving, met 24/7 ondersteuning
- We begeleiden teams met on-the-job coaching, zodat uw eigen mensen discrepanties voortaan zelf kunnen voorkomen en oplossen
Wilt u zeker weten dat uw Power BI-rapportages kloppen met de werkelijkheid? Neem contact met ons op en we kijken samen naar een betrouwbare oplossing voor uw situatie.
Gerelateerde artikelen
- Hoe bouw je pipelines met Data Factory in Microsoft Fabric?
- Wanneer moet je overstappen naar Microsoft Fabric?
- Is Microsoft Fabric geschikt voor de zorgsector in Nederland?
- Hoe controleer je welke SQL Server-versie is geïnstalleerd?
- Wat zijn de TCO-verschillen tussen Fabric en een klassiek datawarehouse?
- Welke fouten worden het vaakst gemaakt bij een Microsoft Fabric-implementatie?
- Wat is het verschil tussen Microsoft Fabric en Synapse?
- Wat zijn veelgemaakte fouten bij de start met Power BI?
- Is Power BI de moeite waard voor een klein bedrijf?
- Kan iedereen Power BI leren?
