De ‘eerste 8 weken’ van het jaar: wanneer verschijnen nieuwe WOZ-waarden en waarom dat je dashboards breekt

Elk jaar, grofweg tussen nieuwjaar en begin maart, schuift het WOZ-landschap onder je voeten. Nieuwe peildata, verstuurde beschikkingen, updates in landelijke registers en portalen: niks gaat in één klap live. Voor product- en datateams in vastgoed/fintech/proptech zijn dit de “eerste 8 weken” waarin dashboards haperen, KPI’s schommelen en integraties ineens “oude” en “nieuwe” jaren door elkaar halen. In dit artikel leggen we uit waarom dat gebeurt, wat je wel en niet mag verwachten van de verschillende bronnen, en hoe je hier technisch robuust mee omgaat.

Wat bedoelen we met “de eerste 8 weken”?

WOZ-waarden worden jaarlijks vastgesteld met peildatum 1 januari van het voorafgaande kalenderjaar. Die nieuwe waarden komen niet in één keer online. Gemeenten ronden hun waarderingen en controles gefaseerd af en leveren aan de Landelijke Voorziening WOZ (LV WOZ, beheerd door het Kadaster). Daarna volgen validaties, terugkoppelingen en publicatie naar loketten.

In de praktijk zie je dat tussen begin januari en eind februari (soms doorlopend in maart) de volgende dingen parallel plaatsvinden:

• Gemeenten finaliseren waarderingen en sturen WOZ-beschikkingen, wettelijk binnen 8 weken na de start van het kalenderjaar (artikel 24 Wet WOZ), met een dagtekening per gemeente.
• Geleidelijke aanleveringen aan LV WOZ en correcties op eerdere aanleveringen.
• Updates van het WOZ-waardeloket (openbare waarden voor woningen op adresniveau) en van gemeentelijke dataportalen.

Voor gebruikers voelt dat als “acht weken van verandering”: jouw queries van eind januari leveren net iets anders op dan begin maart, en dat is geen bug: het is de keten die bijwerkt.

Hoe lopen de processen tussen januari en maart?

De kern is de peildatum: 1 januari van het voorgaande jaar. Die datum zegt iets over de economische situatie waartegen de waarde is bepaald. Maar jij als developer werkt met “vandaag beschikbare” waarden, en daar spelen andere datums:

• Beschikkingsdatum/dagtekening: de datum op het WOZ-beschikkingsdocument voor de belastingplichtige.
• Publicatiedatum in een loket: wanneer een waarde zichtbaar is op het WOZ-waardeloket of in gemeentelijke open data.
• Stand- of extractiedatum: wanneer een dataset of API-snapshot is opgebouwd of ververst.

Omdat gemeenten gefaseerd aanleveren, bevat het loket op elk moment een mix van “nieuw jaar” en “vorig jaar”. Hetzelfde geldt voor gemeentelijke open data (bijv. Amsterdam Datapunt). Daardoor loopt de complete “dekking” van het nieuwe jaar vrijwel nooit vóór eind februari gelijk op.

Hoe strak die keten loopt, meet de Waarderingskamer: in 2025 was 97,8% van de woningen tijdig beschikt (2023: 93,7%) en haalde 94% van de gemeenten de norm van 95% per 1 maart. Bij niet-woningen was het 91,2%, en haalde maar 41% van de gemeenten die norm. Voor dashboards op commercieel vastgoed is de staart dus structureel langer.

Publicatiekanalen: waarom ze onderling kunnen verschillen

Wie WOZ-data gebruikt, ziet grofweg drie werelden terug:

1) LV WOZ (Kadaster)

De landelijke voorziening is de bron waar gemeenten aanleveren. Hier vindt kwaliteitsbewaking en gegevensuitwisseling plaats. Niet alles wat in LV WOZ zit, is openbaar op individueel niveau; het juridisch kader bepaalt wat wél/niet getoond mag worden.

2) WOZ-waardeloket

Het publieke loket toont adresniveau-waarden van woningen. Updates komen in batches. Tijdelijk kunnen er inconsistenties zijn met lokale publicaties of recent aangeleverde correcties die nog niet zijn doorgezet.

3) Gemeentelijke open data

Een lappendeken: sommige gemeenten publiceren tijdig, met goede documentatie en versiestanden; anderen niet of later. Amsterdam is vaak een positief voorbeeld, maar ook daar lopen extractiedata en kolomdefinities per jaar weleens uiteen.

Daarbovenop bestaan er afgeleide diensten (zoals WOZ+) en PDOK-kaarten die je combineert met BAG/BGT. Elk kanaal kent eigen releasecycli, validaties en juridische randvoorwaarden.

Waarom dit je dashboards breekt

Tijdens de eerste weken van het jaar zie je vijf terugkerende failure modes:

1. Gemengde vintages: je dataset bevat zowel vorig-jaar- als dit-jaar-waarden. Als je “actuele WOZ” zonder peildatum/context toont, krijg je schijnbare outliers.
2. Incompleetheid per gemeente: sommige gemeenten zijn al om, andere nog niet. Percentages, gemiddelden en YoY-berekeningen vertekenen.
3. Caching en TTL: agressieve caching (CDN, app-cache) houdt oude waarden vast, terwijl onderliggende bronnen verschuiven. Dezelfde query kan op maandag en woensdag verschillende antwoorden geven, en dat is terecht.
4. Identificatiemismatch: wijzigingen in adressen of objectstatus (bijv. BAG mutaties) leiden tot nieuwe of vervallen combinaties, waardoor joins breken of dubbeltellingen ontstaan.
5. Semantische verwarring: peildatum (economische referentie) wordt verward met publicatiedatum (beschikbaarheid). Je eindgebruiker denkt “dit is 2026-data”, terwijl het waarderingsjaar 2025 is.

Dit is geen bug-hunting-oefening maar ketenrealiteit. Verzacht de klap door je product expliciet “tijdsvast” te maken: laat zien hoe recent de stand is, welk waarderingsjaar je toont, en hoe volledig je dekking is.

Datatijdlijnen ontrafeld: peildatum, beschikkingsdatum, stand-datum

Het helpt om vast te leggen welke datum waarvoor staat:

• Peildatum: 1 januari van het voorgaande jaar. Dit is het referentiemoment waartegen de waarde is bepaald; de waarde voor belastingjaar 2026 heeft dus peildatum 1 januari 2025.
• Toestandsdatum: is een object in de tussentijd verbouwd, gesplitst of opgeleverd, dan telt de staat aan het begin van het belastingjaar, gewaardeerd tegen het prijspeil van de peildatum. Twee datums op hetzelfde object is dus geen fout maar een feature van de wet.
• Beschikkingsdatum: de dagtekening van het aanslagbiljet, per gemeente verschillend en meestal eind februari. Vanaf die datum loopt de bezwaartermijn van 6 weken.
• Stand-datum: het moment waarop jouw bron, extract of API-snapshot is opgebouwd. De enige datum in dit rijtje die jij zelf bepaalt, dus leg hem vast.

Sla minimaal peildatum en stand-datum op bij elke waarde die je systeem binnenkomt. Daarmee kun je elk verschil tussen twee metingen verklaren zonder te gissen of het aan de bron, je cache of je eigen pipeline ligt.

Zo bouw je het robuust: 5 concrete maatregelen

1. Toon peildatum en stand-datum in je UI, ook als het klein is. Het voorkomt de terugkerende supportvraag waarom een waarde afwijkt van het aanslagbiljet.
2. Gate jaar-op-jaar-vergelijkingen totdat de dekking van het nieuwe belastingjaar boven een vaste drempel ligt, bijvoorbeeld 95% van je portefeuille. Tot die tijd toon je het vorige jaar als meest recente complete jaargang.
3. Versioneer je datasets per week in het eerste kwartaal. Een verschil tussen week 4 en week 9 is dan een diff die je kunt tonen, in plaats van een mysterie.
4. Monitor dekking per gemeente, niet alleen landelijk. Landelijk 80% kan betekenen dat jouw belangrijkste gemeente nog op 0 staat.
5. Verkort je cache-TTL in januari en februari. De rest van het jaar is een WOZ-waarde vrijwel statisch; juist in deze weken is een dag oude cache soms al achterhaald.

Samengevat

Nieuwe WOZ-waarden verschijnen niet op 1 dag maar in batches tussen januari en begin maart, omdat honderden gemeenten elk in hun eigen tempo aanleveren aan de LV WOZ en de loketten daarna bijwerken. Dashboards breken in die weken niet door bugs maar door gemengde jaargangen, wisselende dekking en caching. De remedie is je data expliciet tijdsvast maken: leg peildatum en stand-datum vast, gate vergelijkingen op dekking en versioneer je snapshots. Wil je de nieuwe jaargang van een hele portefeuille zonder code controleren, dan vult de Excel-wizard je bestand met adressen in 1 keer aan. Dan zijn de eerste 8 weken van het jaar gewoon een verwacht seizoen in plaats van een storing.