Wanneer ARR-rapportages haperen: het pleidooi voor Custom Snapshots

Vraag een oprichter naar de ARR en je krijgt meestal een zelfverzekerd, rond getal. Vraag om bewijs, een uitsplitsing per jaar of het verloop over de laatste twee kwartalen, en dat vertrouwen verdwijnt vaak snel. Het cijfer waarop bestuursrapportages, investeringsrondes en de beloningsplannen van veel teamleden rusten, blijkt vaak het minst stevige cijfer van het bedrijf. 

Wij verzorgen Revenue Operations voor een groep B2B-softwarebedrijven en hebben dit vaak genoeg gezien om het patroon te herkennen. Als ARR-rapportage vastloopt, heeft dat meestal een van een paar oorzaken. De oplossing is bijna altijd dezelfde: laat het CRM de ARR niet telkens opnieuw uit actuele deals berekenen, maar leg deze vast in een speciaal record, een snapshot. Dit artikel legt uit hoe dat werkt en beschrijft twee heel verschillende trajecten waarin zo'n snapshot de financiële cijfers weer betrouwbaar maakte. 

Het cijfer dat nooit stilstaat

Jaarlijks terugkerende omzet (ARR) klinkt als één getal, maar is eigenlijk een vraag met een datum. Wat is onze terugkerende omzet vandaag? Aan het einde van het vorige kwartaal? Over een jaar, nadat deze contracten zijn verlengd en die andere zijn afgelopen? Elk antwoord is anders. Een gezond bedrijf moet ze allemaal kunnen zien. 

Het probleem is dat CRM-systemen zoals Salesforce en HubSpot zijn gebouwd om lopende deals te beheren, niet om te onthouden hoe je omzet er op een bepaald moment uitzag. Standaardrapporten lezen de actuele stand van je records. Dat werkt goed voor een pipelinerapport, maar niet voor ARR. Drie oorzaken komen steeds terug:

1. Ten eerste ontbreekt het geheugen. Een standaardrapport laat zien wat een deal vandaag vermeldt, niet wat er in maart stond. Zodra iemand een gesloten contract wijzigt, korting geeft op een verlenging of een bedrag corrigeert, verdwijnt de historie. Daarmee verdwijnt ook de basis voor een nauwkeurige ARR-waterval die laat zien hoe je van het cijfer van vorig jaar naar dat van dit jaar kwam.

2. Ten tweede passen meerjarige contracten niet in het model. Een driejarige deal van €300k is geen €300k ARR, en vaak ook geen €100k per jaar, omdat het jaarbedrag gedurende de looptijd kan stijgen of dalen. Eén bedragveld in één verkoopkans kan geen omzet weergeven die bij meerdere jaren hoort. Teams gaan records handmatig kopiëren, waarna die kopieën vrijwel meteen uiteenlopen.

3. Ten derde worden terugkerende en eenmalige omzet vermengd. Onboarding, zakelijke diensten en opstartkosten komen in hetzelfde totaal terecht als abonnementen en licenties. Zonder een duidelijke scheiding bevat je ARR ongemerkt omzet die nooit terugkomt. Het cijfer dat investeerders het belangrijkst vinden, is dan juist het cijfer met de grootste kans op fouten.

Wat een snapshot op maat precies is

De oplossing is eenvoudiger dan ze klinkt. In plaats van een rapport de ARR ter plekke te laten afleiden uit actuele deals, maken we aparte records die ARR vastleggen zoals je die wilt kunnen zien. Die records vormen de snapshot. 

In de praktijk betekent dit meestal een object dat gekoppeld is aan alle deals of verkoopkansen. Zodra een contract wordt gesloten, leest een automatisering het uit en maakt voor elk contractjaar één onderliggend record aan. Een contract van één jaar levert één record op; een driejarig contract levert er drie op. Elk record bevat het terugkerende bedrag voor dat jaar, het omzettype en de bijbehorende periode. Omzet wordt ingedeeld als terugkerend of eenmalig. Abonnementen en verbruik tellen mee voor ARR, onboarding en diensten niet. 

Met data in die vorm wordt rapporteren eenvoudig. Roll-ups tellen ARR op per jaar, omzettype, product of account. Vanuit dezelfde records kun je de actieve ARR van vandaag tonen, de ARR die volgend jaar afloopt en de contractverlengingen en uitbreidingen die daarvoor in de plaats komen. 

Het belangrijkste is de scheiding. Lopende deals blijven bewerkbaar en mogen onvolmaakt zijn; het salesteam kan gewoon doorwerken. ARR staat in een aparte, stabiele laag die de werkelijkheid vastlegt en zichzelf niet stilzwijgend herschrijft wanneer iemand een verkoopkans aanpast. Die scheiding maakt van ARR een cijfer waarop mensen vertrouwen in plaats van waarover ze discussiëren. De twee trajecten hieronder kwamen vanuit heel verschillende problemen tot dezelfde scheiding. 

Voorbeeld één: een dashboard dat er miljoenen naast zat

Het eerste bedrijf was een groeiende B2B-softwareleverancier met meerjarige abonnementen en een combinatie van licenties, verbruik en onboardingkosten. Het ARR-dashboard toonde ongeveer 3 miljoen dollar. De werkelijke ARR uit gewonnen deals lag dichter bij 5,5 miljoen. Zo'n verschil is geen afrondingsfout: het is het verschil tussen een bedrijf dat lijkt te stagneren en een bedrijf dat snel groeit. Toch gebruikte de directie de onjuiste cijfers om het bedrijf te sturen.

De oorzaken waren precies de genoemde problemen, die elkaar versterkten. Ongeveer 2 miljoen dollar aan omzet zat in verkoopkansen die nooit correct waren vastgelegd en daardoor onzichtbaar waren in standaardrapporten. Historische contracten bevatten handmatige rekenfouten, waaronder deals waarbij verbruiksprijzen niet aansloten op de geregistreerde contractwaarde. Omdat het CRM geen cumulatieve ARR door de tijd kon tonen, gebruikte het team een kwetsbare omweg: gewonnen deals en verlengingskansen samenvoegen, filteren op actieve contracten en accepteren dat openstaande nieuwe business onzichtbaar bleef. Het dashboard gaf vooral antwoord op een vraag die niemand had gesteld.

We bouwden een ARR Snapshot-object boven op de bestaande structuur van offerte naar deal. Zodra een contract werd gesloten, rekende een automatisering dit om naar jaarbedragen en maakte voor elk product en elk contractjaar een snapshotrecord aan. Een eenjarige deal kreeg één record; een meerjarige deal één per jaar. Elke regel kreeg het label terugkerend of eenmalig, zodat de totale contractwaarde en de terugkerende ARR eindelijk verschillende waarden waren. Roll-upvelden telden ARR vervolgens op per jaar en omzettype voor alle contracten.

Ook de rapportagestandaard veranderde. In plaats van het gemiddelde of de volledige contractwaarde gebruikte iedereen voortaan de ARR van het eerste jaar als gemeenschappelijke maatstaf: van salestools tot de beloning van account executives. Dezelfde definitie gold zo in het hele proces. Gesloten deals genereerden automatisch een verkoopkans voor de volgende contractperiode en nieuwe snapshots. Daardoor kon het team verlengingen twee en drie jaar vooruit voorspellen en op elk moment zien welke ARR actief was, welke afliep en welke uitbreidingen daarvoor in de plaats zouden komen.

Dit gebeurde niet van de ene op de andere dag. De ARR-definitie werd in de eerste maanden vier of vijf keer verfijnd doordat uitzonderingen naar voren kwamen: uitbreidingen met afwijkende einddatums en historische deals die opnieuw gecontroleerd moesten worden. Dat is de realiteit van dit werk. Het snapshotobject biedt een plek om correcte gegevens vast te leggen, maar eerst moet je de cijfers op elkaar laten aansluiten. De blijvende verandering was één betrouwbare bron voor ARR, onderbouwd door de producten, in plaats van een dashboard dat ongemerkt verschoof zodra een salesmedewerker een deal wijzigde.

Voorbeeld twee: betrouwbare cijfers vóór due diligence

Het tweede traject betrof een softwarebedrijf voor duurzaamheid dat een investeringsronde voorbereidde. De ARR-waterval was daar noodzakelijk voor due diligence. Provisieplannen, kwartaal- en jaardoelen, bestuursrapportages en de OKR's van het bedrijf waren ervan afhankelijk. Commerciële en financiële due diligence liepen parallel. De prognoseperiode moest zelfs van twee naar drie jaar worden uitgebreid. Een fout in de ARR zou hier niet alleen het team misleiden: externe investeerders zouden elk onderdeel onderzoeken.

De eerdere, eenvoudigere aanpak was juist het probleem geworden. Het bedrijf vertrouwde op statische ARR-cijfers van afzonderlijke momenten, die precies verborgen wat bij due diligence belangrijk is. Meerjarige deals met wisselende jaarbedragen werden teruggebracht tot één getal. Vroege verlengingen en uitbreidingen overlapten met de oorspronkelijke contracten, waardoor omzet in meerdere kwartalen dubbel werd geteld. Bij één uitbreiding werden oorspronkelijke en nieuwe producten samengevoegd, met abonnementsperioden die ongeveer vijf maanden overlapten. De statische snapshot kon dat niet correct weergeven.

We combineerden twee maatregelen. Eerst beschermden we de integriteit van de waterval. Toen werd voorgesteld om verlengingskorting te verwerken door historische productdata te wijzigen, wezen we dat af. Daarmee zouden de ARR-historie, provisieberekeningen en bestuurscijfers tegelijk onjuist worden. De regel werd: herschrijf het verleden nooit. Verwerk korting bij de verlenging, licht de wijziging toe en laat het record weergeven wat er echt is gebeurd. Lastige situaties kregen een expliciete verwerking. Zo behandelden we een driejarige deal met een opzeggingsmogelijkheid na drie maanden eerst als korte, niet-terugkerende pilot, en vanaf maand vier als reguliere ARR als de klant bleef.

Daarnaast veranderde de snapshot van één bedrag in een overzicht per contractjaar. Een contract van €300k werd €100k per jaar over drie jaar, met eigen factuurdatums en een apart record voor elk jaar. Dat jaaroverzicht voedde de waterval rechtstreeks en vormde ook de basis voor een financiële controle. Vanuit de contracten legde het team vast wat wanneer gefactureerd had moeten worden. Dat werd vergeleken met historische boekhoudgegevens, waarna ontbrekende toekomstige facturen werden voorbereid. Het contract was leidend en de boekhouding moest daarop aansluiten, niet andersom. Die volgorde maakte echt omzetverlies zichtbaar, waaronder apart overeengekomen diensten die nooit waren gefactureerd.

Het resultaat was een waterval die het bedrijf kon onderbouwen. Half januari werkte deze en kwam de jaaromzet uit op 5,4 miljoen dollar, nog onder voorbehoud van de laatste controle met factuurgegevens. Slechts bij een paar verkoopkansen ontbrak nog ARR. Bij due diligence maakt het verschil tussen een cijfer dat je alleen noemt en een cijfer dat je per contract en per jaar kunt herleiden, het verschil tussen een soepel en een moeizaam proces.

Waarom dit steeds de oplossing blijkt

Dit waren verschillende bedrijven, met verschillende CRM-systemen en verschillende problemen. Het ene telde miljoenen ARR te weinig; het andere telde te veel door overlap en onjuist verwerkte meerjarige deals. Het ene moest de eigen directie overtuigen, het andere investeerders. Toch kwamen beide uit op dezelfde structurele oplossing. Dat is geen toeval.

ARR is in de kern een vraag over een tijdreeks, gesteld aan een systeem dat alleen de huidige stand bewaart. Hoeveel rapporten je ook bouwt, dat lost het verschil niet op. De informatie die je nodig hebt – welke omzet terugkerend was, in welk jaar en op welk moment – staat simpelweg niet in één actuele deal. Je kunt alleen rapporteren over vastgelegde data. Standaardrecords leggen die historie niet vast; snapshots wel. Ze registreren ARR in de vorm waarin je ernaar vraagt: per jaar, per type en op een vast tijdstip.

Al het andere volgt uit die juiste datavorm. Roll-ups worden eenvoudig. Watervallen worden betrouwbaar omdat de historie eronder niet meer verschuift. Beloningsplannen en bestuursrapportages gebruiken dezelfde records. Sales, Finance en het bestuur bespreken daardoor eindelijk de strategie in plaats van wiens cijfer klopt. Een snapshot is geen kunstgreep: het is het verschil tussen ARR onder tijdsdruk berekenen en deze vooraf goed vastleggen.

Als dit op jouw bedrijf lijkt

Vanaf dag één heb je waarschijnlijk geen snapshotlaag nodig. Als elke deal een eenjarig abonnement is en je enkele tientallen klanten hebt, volstaan standaardrapporten. De aanpak verdient zich terug zodra de complexiteit toeneemt. Daarvoor zijn een paar duidelijke signalen.

Het duidelijkste signaal is dat je je eigen ARR niet meer volledig vertrouwt, of dat twee mensen binnen het bedrijf tot verschillende cijfers komen. Andere signalen zijn meerjarige contracten waarvan niemand weet hoe ze gerapporteerd moeten worden, verlengingen of uitbreidingen die dubbel lijken te tellen, en cijfers van Finance en Sales die nooit aansluiten. Bij een naderende investeringsronde of audit gaat de lat omhoog. Je moet ARR per jaar en per contract kunnen herleiden, niet alleen een totaal noemen. Een spreadsheet die uit het geheugen is opgebouwd, houdt bij controle geen stand.

Het goede nieuws is dat dit een oplosbaar probleem is. Je hoeft geen systemen te migreren of een nieuw platform te kopen. In beide voorbeelden werd de oplossing gebouwd binnen het CRM dat het bedrijf al gebruikte. Het vraagt om ARR te behandelen als data die je bewust vastlegt in plaats van een getal dat je onder tijdsdruk berekent. En om eenmalig de gegevens goed op elkaar aan te sluiten, zodat het cijfer daarna correct blijft.

Als je ARR meer een discussiepunt dan een feit begint te worden, verdient een snapshotaanpak zich doorgaans terug. Het is een van de meest waardevolle verbeteringen die een groeiend softwarebedrijf in zijn commerciële systemen kan aanbrengen. Alles wat erop volgt – prognoses, beloning en het verhaal voor investeerders – hangt af van dat ene juiste cijfer.