Waarom een spreadsheet niet schaalt als register

De meeste creditprogramma’s beginnen niet met een register maar met een spreadsheet. Een tabblad met projecten, een tabblad met uitgegeven eenheden, een kolom “verkocht aan”, en een mailbox waarin de afspraken staan. Dat is geen amateurisme; voor een pilot met een handvol projecten is het de juiste eerste stap.

Het probleem ontstaat later, en sluipend: zodra er geld, eigendom en externe controle aan de cijfers hangen. Dit artikel beschrijft waar het dan breekt, wat een register anders doet, wanneer het tijd is en hoe je overstapt zonder historie te verliezen.

Waar een spreadsheet wél goed voor is

Eerst het eerlijke deel. In de pilotfase weet je nog niet welke velden je nodig hebt, hoe een methodologie zich in de praktijk gedraagt of hoe vaak je gaat uitgeven. Een spreadsheet dwingt geen datamodel af en dat is dan een voordeel: je voegt een kolom toe zonder een leverancier te bellen.

Ook als denkgereedschap is een spreadsheet ongeslagen. Een berekening van baseline naar tonnen of een scenario voor bufferpercentages hoort in een rekenblad. Het punt is niet dat spreadsheets slecht zijn, maar dat een spreadsheet geen register is — en dat het verschil pas zichtbaar wordt als het te laat is om het rustig op te lossen.

Wat een register moet kunnen

Een register is in essentie een systeem dat één vraag altijd eenduidig beantwoordt: van wie is deze eenheid nu, en wat is ermee gebeurd. Het beoordelingskader van de ICVCM eist een register dat projecten en uitgegeven credits uniek identificeert, vastlegt en volgt, zodat elke eenheid ondubbelzinnig te herkennen is — en dat een afgeboekte eenheid niet opnieuw kan worden overgedragen.

De Europese CRCF-verordening gaat een stap verder: certificeringsschema’s moeten openbare registers opzetten en bijhouden, met geautomatiseerde systemen, die interoperabel zijn met de registers van andere erkende schema’s om dubbeltelling te voorkomen. De Commissie richt uiterlijk eind 2028 een Unieregister in; tot die tijd gelden die eisen voor de registers van de schema’s zelf.

Waar het breekt: eigendom en overdracht

Een cel in een spreadsheet bevat een waarde, geen eigendom. Als in kolom F staat “verkocht aan Bedrijf A”, dan is dat een tekst die iedereen met schrijfrechten kan veranderen, kopiëren of laten staan terwijl de eenheden al aan Bedrijf B zijn gegaan.

Overdracht is in een register één ondeelbare handeling: de eenheid verlaat de ene rekening en verschijnt op de andere, of er gebeurt niets. In een spreadsheet zijn dat twee bewerkingen — een regel aanpassen, een e-mail sturen — met daartussen een toestand waarin de eenheid van niemand of van twee partijen is. Precies daar ontstaat dubbele verkoop, en bijna nooit met opzet.

Daar komt het versieprobleem bij. Zodra een bestand wordt gemaild, bestaan er twee. Na een kwartaal zijn er meer: “register_def”, “register_def_v2”, de versie op de gedeelde schijf, de export voor de accountant. Welke is de waarheid? In een register bestaat die vraag niet; er is één stand en een geschiedenis.

Waar het breekt: fouten die niemand ziet

Over spreadsheetfouten bestaat decennia onderzoek, vooral van Raymond Panko. Zijn samenvatting van veldaudits van operationele spreadsheets is ontnuchterend: in de meest recente audits bevatte minstens 86 procent van de onderzochte spreadsheets fouten, en waar het foutpercentage per cel is gemeten, lag dat tussen 0,4 en 6,9 procent.

Belangrijker dan het percentage is het mechanisme. Een formule die één regel te weinig meeneemt, geeft geen foutmelding; hij geeft een iets te laag totaal. Een sorteeractie op één kolom in plaats van de hele tabel koppelt serienummers aan de verkeerde projecten en ziet er daarna volkomen normaal uit. Panko wijst er ook op dat ervaren gebruikers nauwelijks minder fouten maken dan beginners — de fout zit in het gereedschap, niet in de gebruiker.

In een register heet dat: een uitgifte die niet in het totaal terechtkomt, een afboeking die door een filter onzichtbaar is, een vintage die door een datumnotatie in het verkeerde jaar valt — zonder enige melding.

Waar het breekt: toegang, controle en afhankelijkheid

• Audit trail. Een spreadsheet weet niet wie een cel heeft gewijzigd, wanneer en waarom. Versiegeschiedenis in cloudtools legt geen reden vast en is niet aan een eenheid te koppelen.
• Toegang is alles of niets. Wie het bestand mag zien, mag meestal ook alles wijzigen; alleen-lezen voor een verificateur is niet af te dwingen.
• Afstemming is handwerk. Betalingen staan in de boekhouding, certificaten in een map, eenheden in het bestand; of die drie kloppen, controleert iemand met de hand.
• Verificateurs kunnen niet onafhankelijk controleren. Ze krijgen een export en moeten erop vertrouwen dat die de actuele stand is.
• Geen publiek opzoeken en geen API. Een koper kan een serienummer niet zelf natrekken, en koppelingen met verkoopplatform of meetbron lopen via kopiëren en plakken.
• Persoonsgegevens en transacties door elkaar. Namen, e-mailadressen en bankgegevens van grondeigenaren staan naast eenheden en prijzen. Onder de AVG moet je toegang kunnen beperken tot wat iemand nodig heeft; met één bestand kan dat niet.
• Sleutelpersoonrisico. Er is doorgaans één persoon die weet hoe het bestand werkt, welke kolom je niet mag aanraken en waarom regel 412 geel is.

Naast elkaar

Signalen dat het tijd is

Er is geen magisch aantal eenheden waarbij een spreadsheet ophoudt te werken. Er zijn wel vier momenten waarop het risico van karakter verandert.

1. De eerste externe koper. Zolang eenheden binnen de eigen kring blijven, is een fout een intern probleem. Zodra een derde betaalt, is dezelfde fout een contractbreuk.
2. De eerste audit of verificatie van het register zelf. Een verificateur die vraagt “laat zien wie dit heeft gewijzigd” krijgt in een spreadsheet geen antwoord.
3. De eerste correctie waarover discussie ontstaat. Als een uitgifte moet worden bijgesteld en twee partijen een andere versie van het bestand hebben, is er geen scheidsrechter.
4. Frequenter uitgeven. Digitale MRV maakt van vier uitgiftes per jaar er veertig; wat met de hand nog ging, gaat dan niet meer.

Overstappen zonder historie te verliezen

De angst voor een overstap is meestal de angst om de geschiedenis kwijt te raken. Dat hoeft niet, als je de migratie als een boekhoudkundige handeling behandelt en niet als een IT-project.

1. Bevries het bestand. Kies een tijdstip, maak de spreadsheet alleen-lezen en spreek af dat wijzigingen daarna niet meer tellen.
2. Maak de identificatie schoon. Elke eenheid of reeks krijgt één definitief identificatienummer; duplicaten, tikfouten en “zie mail” worden opgelost vóór de import, niet erna.
3. Importeer met herkomst. Elke geïmporteerde regel krijgt een verwijzing naar de bron: welk bestand, welke versie, welke regel.
4. Bewaar het bestand als archief. Niet weggooien, niet meer bewerken: het is het bewijs van de stand op de bevriesdatum.
5. Stem de totalen af. Uitgegeven, overgedragen, afgeboekt en in omloop moeten per project en per vintage in beide systemen gelijk zijn. Elk verschil krijgt een verklaring op papier.
6. Draai één cyclus parallel. Eén uitgifteronde of één kwartaal boek je in beide systemen. Daarna is het register de enige waarheid.

Een register dat wijzigingen ankert in een onafhankelijk, onveranderlijk grootboek maakt stap drie en vier sterker: je kunt later aantonen dat de geïmporteerde stand sindsdien niet is aangepast.

Wat dit betekent voor je eigen programma

Als je nu een spreadsheet gebruikt, is de vraag niet of je moet overstappen, maar of je al voorbij een van de vier signalen bent. Is dat zo, dan loop je een risico dat je zelf niet kunt zien — dat is de kern van het onderzoek naar spreadsheetfouten. Is dat niet zo, dan is een spreadsheet nog prima, mits je hem alvast behandelt als een toekomstige bron: één identificatienummer per eenheid, één bestand, één eigenaar van dat bestand.

De overstap zelf is kleiner dan hij lijkt; het schoonmaken van de identificatie is meestal het meeste werk, en dat had toch een keer moeten gebeuren. Regelgeving in deze markt verandert snel; controleer een datum of eis bij de bron voordat je erop bouwt.