Digitale MRV verlaat de pilotfase: van jaarrapport naar doorlopende data

Traditionele MRV — meten, rapporteren, verifiëren — werkt in jaarcycli. Een project verzamelt gegevens, stelt een rapport op, een verificateur controleert steekproeven, en daarna volgt een uitgifte. Dat proces is degelijk en langzaam, en het kost een aanzienlijk deel van de opbrengst van een project.

Digitale MRV, kortweg dMRV, draait dat om. In plaats van periodiek een dossier op te bouwen, laat je meetgegevens doorlopend binnenkomen uit sensoren, satellietbeelden en modellen. De verificatie verschuift dan van het beoordelen van een rapport naar het beoordelen van een datastroom.

2026: het jaar dat het serieus werd

Digitale MRV werd jaren als belofte gepresenteerd. Wat 2026 anders maakt, is dat de grote programma’s het in hun eigen uitgifteproces zijn gaan gebruiken.

• Verra, het grootste crediteringsprogramma ter wereld, keurde in februari 2026 de eerste credits goed onder een dMRV-pilot gericht op frequenter uitgeven.
• Gold Standard startte een dMRV-pilotprogramma dat tot oktober 2026 loopt.
• Het Global Carbon Council lanceerde in mei 2026 TRACE, zijn eerste goedgekeurde dMRV-platform.

Dat is een patroon, geen incident. Als drie programma’s binnen een paar maanden dezelfde stap zetten, is dMRV geen onderscheidende technologie meer maar infrastructuur waar je aan moet kunnen koppelen.

Wat er onder de motorkap zit

De technieken zijn geen magie en dat is goed nieuws — ze zijn navolgbaar en controleerbaar.

Voor de Nederlandse praktijk is die derde categorie het meest relevant. Bij veenweideprojecten is de grondwaterstand de bepalende variabele voor veenoxidatie. Een peilbuis die elk uur meet, levert een fundamenteel ander bewijs dan een handmatige meting per kwartaal.

De echte verandering is het ritme

De aandacht gaat meestal naar nauwkeurigheid, maar de ingrijpendste verandering is de frequentie. Als data doorlopend binnenkomt, hoeft uitgifte niet meer op een jaarcyclus te wachten.

Dat klinkt als een verbetering en dat is het ook, maar het breekt aannames die in veel registers zijn ingebakken:

1. Een vintage is niet langer automatisch een kalenderjaar. Je moet periodes fijnmaziger kunnen vastleggen.
2. Herberekening wordt normaal. Als nieuwe data een eerdere schatting bijstelt, moet je kunnen corrigeren zonder de geschiedenis te wissen.
3. Uitgiftes worden kleiner en talrijker. Wat handmatig ging bij vier uitgiftes per jaar, gaat niet meer bij vier per maand.
4. De herkomst van data wordt een eigenschap van de eenheid. Welke sensor, welk beeld, welke modelversie lag hieraan ten grondslag?

Punt twee is het lastigste. Een register dat alleen de huidige stand kent, kan een herberekening niet netjes verwerken. Je moet kunnen laten zien wat je eerder dacht, wat er is bijgesteld en waarom — vooral als er al eenheden zijn verkocht op basis van de oude schatting.

Uitgewerkt: een veenweideproject

Abstract blijft dit lastig te wegen, dus een concreet voorbeeld uit de Nederlandse praktijk. Bij veenweideprojecten is het principe eenvoudig: veen dat droog staat, oxideert en stoot CO2 uit. Zet je het waterpeil hoger, dan remt dat de oxidatie. De reductie zit dus in het peil.

De keten van meting naar eenheid loopt dan zo:

1. Peilbuizen meten de grondwaterstand, bij dMRV met hoge frequentie in plaats van een handmatige ronde per kwartaal.
2. Die reeks wordt omgezet naar een drooglegging over de tijd — hoe lang stond het veen hoe diep onder water.
3. Een rekenmodel zet drooglegging om naar vermeden emissie in tonnen CO2-equivalent.
4. Een verificateur beoordeelt of de sensoren deugen, of de reeks compleet is en of het model correct is toegepast.
5. Het register geeft eenheden uit, met de meetperiode, de modelversie en de onderliggende reeks eraan gekoppeld.

Bij stap één en twee gaat het in de praktijk mis. Een peilbuis die twee weken uitvalt, laat een gat in de reeks. Dat gat moet je opvullen — met interpolatie, met een naburige meetlocatie, of door de periode buiten beschouwing te laten. Welke keuze je maakt, beïnvloedt het aantal eenheden. Die keuze moet dus vastgelegd worden, niet impliciet in een rekenblad verdwijnen.

Data-eigendom en bewaartermijnen

Een onderwerp dat bij dMRV-projecten steevast te laat op tafel komt: van wie is de data, en hoe lang moet je hem bewaren?

• Sensoren staan vaak op grond van een derde — een boer, een terreinbeheerder. Wie mag die metingen gebruiken, en waarvoor? Leg dat vast voordat de eerste eenheid wordt verkocht.
• Satellietbeelden van commerciële aanbieders komen met licentievoorwaarden. Een licentie die afloopt, kan je onderbouwing raken.
• De monitoringperiode bij langdurige opslag kan tientallen jaren beslaan. Je bewaartermijn moet die periode overleven, inclusief de vraag of je leverancier dat ook doet.
• Perceelgegevens kunnen persoonsgegevens zijn als ze aan een individuele agrarisch ondernemer te koppelen zijn. Dat raakt de AVG, en dus je grondslag en bewaarbeleid.

Dit is geen randvoorwaarde maar onderdeel van de kwaliteit van je credits. Een eenheid waarvan de onderbouwing over tien jaar niet meer opvraagbaar is, is over tien jaar niet meer verdedigbaar.

Wat dMRV niet oplost

Hier is nuchterheid op zijn plaats, want er wordt veel beloofd rond dMRV.

• Het maakt de verificateur niet overbodig. Onafhankelijke controle blijft nodig; wat verandert is dat de controle zich richt op de betrouwbaarheid van de datastroom en de aannames in het model.
• Het lost additionaliteit niet op. Of een project zonder credits ook was gebeurd, is een beoordeling, geen meting. Geen enkele satelliet ziet dat.
• Het maakt permanentie niet zeker. Beter meten van koolstof in de bodem zegt niets over of die koolstof daar over dertig jaar nog zit.
• Het is niet automatisch goedkoper. Sensoren, data-abonnementen en integratiewerk kosten geld. De winst zit in snelheid en in minder handwerk, niet per definitie in een lagere totaalprijs.

Rond dMRV circuleren opvallend precieze claims over kostenbesparing en nauwkeurigheidswinst. Die komen doorgaans van leveranciers en zijn zelden onafhankelijk gecontroleerd. Wij nemen ze niet over, en wij zouden ze ook niet in een projectonderbouwing zetten.

Wat dit van je software vraagt

dMRV is in de kern een integratievraagstuk. De meetkant is vakwerk van specialisten; de administratieve kant is software.

• Databronnen koppelen via API’s in plaats van bestanden overtypen, met vastlegging van wanneer welke gegevens binnenkwamen.
• Versiebeheer op meetdata en modellen, zodat een berekening reproduceerbaar blijft.
• Herberekeningen die de oude waarde bewaren in plaats van overschrijven.
• Uitgifte die geautomatiseerd kan, met controlestappen die een mens alleen ziet als er iets afwijkt.
• Een audit trail die vragen aankan als: op basis waarvan is deze eenheid uitgegeven, en wat wisten we op dat moment?

Het patroon dat we in projecten zien: organisaties onderschatten niet de techniek van meten, maar de administratie van veranderende gegevens. Zolang een meting één keer per jaar komt, kun je met documenten werken. Zodra er dagelijks data binnenkomt, moet je systeem het verschil kennen tussen een meting, een schatting en een uitgegeven eenheid.