Wat is een semantische laag? Eén definitie van je KPI's voor dashboards en AI.

Wat is een semantische laag?

Het maandoverleg begint met twee omzetcijfers. Finance komt uit op het ene bedrag, sales op een ander. Niemand heeft een fout gemaakt. Finance rekent zonder btw en trekt creditnota's af in de maand van de oorspronkelijke factuur. Sales telt getekende orders, ook als die nog niet gefactureerd zijn. Beide cijfers kloppen, alleen beantwoorden ze een andere vraag.

Het eerste half uur gaat op aan uitzoeken waar het verschil vandaan komt. Dat gebeurt volgende maand weer, want de rekenregels staan op twee plekken: in een Excel-bestand bij finance en in een dashboardformule bij sales. Een semantische laag is het antwoord op precies dat probleem. In dit artikel leg ik uit wat het is, waar je zo'n laag kunt leggen en wanneer het de moeite loont.

Het probleem: rekenregels die overal en nergens wonen

In bijna elke organisatie die een paar jaar rapporteert, zijn de definities van de belangrijkste cijfers verspreid geraakt. Niet door slordigheid, maar omdat elke nieuwe rapportage zijn eigen rekenregel meekrijgt. Je ziet ze terug op een paar vaste plekken.

• In dashboardformules: een berekende kolom in Power BI of Looker Studio die net iets anders werkt dan die in het rapport ernaast.
• In Excel-bestanden: een draaitabel met een handmatige correctie die alleen de maker kent.
• In applicatiecode: een overzichtsscherm in je eigen software dat omzet op een derde manier optelt.
• In hoofden: "die klant tellen we niet mee, dat is een interne doorbelasting." Nergens opgeschreven.

Elke kopie van een rekenregel is een plek waar hij kan afwijken. En hoe meer kopieën, hoe groter de kans dat iemand er één aanpast en de rest vergeet. In het artikel over datawarehouses voor het MKB schreef ik al dat de meeste rapportageproblemen definitieproblemen zijn. Een datawarehouse brengt de data bij elkaar. Een semantische laag brengt de betekenis bij elkaar.

Twee verschillende omzetcijfers zijn zelden een technisch probleem. Het zijn twee definities die nooit met elkaar kennis hebben gemaakt.

Wat zit er in een semantische laag?

Een semantische laag beschrijft je data in de taal van je bedrijf in plaats van in de taal van je database. Waar de database spreekt over invoice_lines.amount_excl_vat en credit_notes.original_invoice_id, spreekt de semantische laag over "netto omzet". Grofweg leg je er vier dingen in vast.

1. Entiteiten: de dingen waar je bedrijf om draait, zoals klant, order, project en medewerker, en hoe ze in de verschillende bronnen aan elkaar gekoppeld zijn.
2. Maten: de getallen die je optelt of telt, zoals bedrag, aantal of uren, met de regel hoe ze samengevoegd worden (som, gemiddelde, aantal unieke).
3. Dimensies: de eigenschappen waarop je mag filteren en groeperen, zoals regio, productgroep, maand of accountmanager.
4. KPI's: de afgeleide cijfers die je bespreekt, zoals netto omzet, brutomarge, aantal actieve klanten of gemiddelde doorlooptijd, met een eenduidige formule en een omschrijving in gewone taal.

Het verschil met een losse query is dat de semantische laag de onderdelen apart kent. Vraag je om netto omzet per regio per kwartaal, dan stelt de laag zelf de juiste SQL samen: de juiste tabellen, de juiste koppelingen, de juiste filters. Wie de vraag stelt, hoeft niet te weten hoe de database in elkaar zit.

Een voorbeeld: wat is een actieve klant?

Neem het begrip actieve klant. Voor de één is dat iedereen met een lopend contract. Voor de ander iedereen die de afgelopen twaalf maanden iets heeft besteld. Een derde telt vestigingen van dezelfde organisatie apart. In een semantische laag kies je één definitie, schrijf je hem op ("een klant met minimaal één gefactureerde order in de afgelopen twaalf maanden, op organisatieniveau") en leg je de formule ernaast. Wil sales toch een andere variant, dan krijgt die een eigen naam. Twee begrippen met twee namen is prima. Eén naam met twee betekenissen is de bron van het probleem.

Waar kun je de semantische laag leggen?

Een semantische laag is een concept, geen product. Je kunt hem op verschillende plekken leggen, elk met eigen voor- en nadelen.

In je dashboardtool

De meeste BI-tools hebben een eigen semantische laag. Microsoft heeft Power BI-datasets in november 2023 zelfs hernoemd tot semantische modellen, omdat ze meer zijn dan een verzameling data: ze bevatten relaties, berekeningen en definities. Looker werkt met LookML, een taal waarin je dimensies en maten vastlegt waarna Looker de SQL genereert.

Dat werkt goed zolang die tool de enige plek is waar mensen naar cijfers kijken. De definitie geldt alleen binnen de tool. Een export naar de accountant, een overzicht in je eigen applicatie of een AI-assistent die buiten Power BI om vragen beantwoordt, heeft er niets aan.

In de rapportagedatabase

De eenvoudigste vorm die buiten één tool werkt: views in je rapportagedatabase met duidelijke namen en de formules in versiebeheer. Een view kpi_netto_omzet_per_maand doet precies wat de naam zegt, en elke tool die SQL spreekt kan hem lezen. Je mist de flexibiliteit om vrij te combineren, want elke combinatie van KPI en dimensie is een eigen view. Maar voor een handvol vaste KPI's is dit overzichtelijk en goed te onderhouden.

In een aparte semantische-laagtool

Daarnaast bestaan tools die alleen dit doen en tussen je datawarehouse en al je kijktools in zitten. De dbt Semantic Layer bouwt voort op dbt, dat veel teams al gebruiken voor hun bewerkingsstappen. De onderliggende rekenmotor MetricFlow is sinds oktober 2025 open source onder de Apache 2.0-licentie. Cube is een ander voorbeeld: een laag die definities centraal beheert en ze via SQL en API's aanbiedt aan dashboards en applicaties. En ook de datawarehouses zelf schuiven op: Snowflake heeft semantic views, waarmee je definities direct in het warehouse legt.

Waarom AI de semantische laag ineens belangrijk maakt

Lang was de semantische laag iets voor grote organisaties met een datateam. Wat dat verandert, is AI. Steeds meer bedrijven willen een assistent die vragen beantwoordt als "welke klanten bestelden dit kwartaal minder dan vorig jaar?" Zo'n assistent kan op twee manieren aan het antwoord komen.

• Zelf SQL schrijven op de ruwe tabellen: het taalmodel bekijkt de tabelstructuur en verzint een query. Dat lijkt indrukwekkend, maar het model moet raden wat omzet betekent, welke tabellen bij elkaar horen en of creditnota's meetellen. Het antwoord ziet er altijd overtuigend uit, ook als het niet klopt.
• Een vastgelegde KPI opvragen: het model vertaalt je vraag naar "netto omzet, per klant, dit kwartaal versus hetzelfde kwartaal vorig jaar" en vraagt dat op bij de semantische laag. De rekenregel komt niet van het model, maar uit de definitie die finance heeft goedgekeurd.

De tweede route is controleerbaar en geeft hetzelfde getal als je dashboard. Dat de markt dit ook zo ziet, blijkt uit de Open Semantic Interchange: een initiatief dat Snowflake in september 2025 met onder meer Salesforce, dbt Labs en BlackRock startte om semantische definities uitwisselbaar te maken tussen tools, uitdrukkelijk met AI als aanleiding. dbt Labs noemt het openstellen van MetricFlow een bijdrage aan datzelfde initiatief.

Bouw je zelf een assistent op je bedrijfsdata, bijvoorbeeld via een MCP-server zoals ik beschrijf in praten met je data, dan is dit het belangrijkste ontwerpbesluit. Geef het model tools als "haal KPI op" met een vaste lijst KPI's en dimensies, in plaats van een open SQL-verbinding op je database.

Een AI-assistent op je cijfers is precies zo betrouwbaar als de definities waar hij op aansluit. Zonder semantische laag krijg je snellere antwoorden op een vraag die niemand eenduidig heeft gesteld.

Zo begin je met een semantische laag

Je hoeft niet te beginnen met een tool. Je begint met een lijst.

1. Verzamel de cijfers die besproken worden: pak de agenda's en rapportages van de afgelopen kwartalen en noteer welke KPI's terugkomen. Meestal zijn dat er minder dan twintig.
2. Zoek de dubbele definities: vraag per KPI aan finance, sales en operations hoe zij hem berekenen. Waar de antwoorden verschillen, zit je eerste winst.
3. Wijs per KPI een eigenaar aan: iemand die besluit wat de definitie is. Dat is een bedrijfsbesluit, geen technische keuze.
4. Schrijf de definitie op in gewone taal: één zin die iedereen begrijpt, plus de uitzonderingen. Pas daarna de formule.
5. Leg de formule op één plek vast: als view in je rapportagedatabase, of in een semantische-laagtool, met versiebeheer zodat je kunt terugzien wanneer een regel veranderde en waarom.
6. Laat tools alleen nog daar lezen: dashboards, exports en AI-assistenten halen hun KPI's uit de laag. Formules in de kijklaag bouw je af.

Valkuilen

• Beginnen met de tool: een semantische-laagtool installeren voordat de definities zijn afgesproken, levert dezelfde discussie op in een nieuw systeem.
• Te veel tegelijk: honderd KPI's modelleren in de eerste maand. Begin met de vijf waar nu ruzie over is.
• Geen omschrijving bij de formule: een KPI zonder uitleg in gewone taal wordt over een jaar weer anders geïnterpreteerd. En een AI-assistent heeft die omschrijving nodig om de juiste KPI te kiezen.
• Wijzigingen zonder historie: als de definitie van omzet verandert, moet je kunnen uitleggen waarom het cijfer van vorig jaar ineens anders is. Versiebeheer is geen luxe; zie ook audit trails in software.

Mijn kijk op de semantische laag

Ik merk dat het woord semantische laag mensen afschrikt. Het klinkt als iets voor een datateam met een eigen budget en een architectuurplaat aan de muur. Terwijl de kern heel gewoon is: spreek af wat je cijfers betekenen en zet die afspraak op één plek. Bij de meeste klanten waar ik dit doe, is het eerste resultaat geen nieuwe tool maar een document met vijftien definities waar finance en sales allebei hun handtekening onder zetten. Dat gesprek is het waardevolste deel van het hele traject.

Technisch kies ik bijna altijd voor de eenvoudigste vorm die werkt: views in een PostgreSQL-rapportagedatabase, met de SQL in Git en een korte omschrijving per KPI. Pas als er meerdere tools en teams op aansluiten, of als we een AI-assistent bouwen die vrij moet kunnen combineren, kijken we naar een aparte laag. Dan is de overstap klein, omdat de definities al bestaan.

Wat ik wel stellig vind: wie nu een AI-assistent op zijn bedrijfscijfers wil, moet eerst deze stap zetten. Een model dat zelf bedenkt hoe je omzet berekent, is een spreadsheet met een vriendelijke stem. Een model dat je vastgelegde KPI's opvraagt, is een collega die je cijfers kent.

— Jasper

Zo helpt Coding Agency hierbij

Wij helpen bij het hele traject: de definities boven tafel krijgen, ze vastleggen als views of in een semantische laag op je rapportagedatabase, en de tools erop aansluiten. Dat kan een dashboard op maat zijn, een koppeling met Power BI of een AI-assistent die via een MCP-server je vastgelegde KPI's opvraagt in plaats van zelf queries te verzinnen. Ligt er nog geen nette basis onder, dan begint het bij een rapportagedatabase. Meer over onze aanpak lees je op de pagina over dashboards en rapportages.

Liggen er in jullie overleg ook twee cijfers op tafel die allebei kloppen? Neem contact op voor een vrijblijvend gesprek.