Lucas TraikoffARR-rapporten die standaard in het CRM zitten gaan mis, omdat een CRM alleen de huidige stand van elke deal opslaat. Het vergeet de historie, kan een meerjarig contract niet over jaren verdelen en mengt eenmalige fees door de terugkerende omzet. De oplossing is een custom ARR-snapshot, dus één record per contractjaar met terugkerende omzet per type en datum, zodat de waterfall niet meer verschuift als iemand een deal aanpast.
Vraag een founder naar de ARR en je krijgt meestal een zelfverzekerd, rond getal. Vraag om het te onderbouwen, het per jaar uit te splitsen of te laten zien hoe het de afgelopen twee kwartalen bewoog, en die zekerheid verdwijnt vaak snel. Het getal waarop je boarddecks, je fundraises en de beloningsplannen van veel teamleden leunen, blijkt vaak het zachtste getal in het bedrijf.
We runnen revenue operations voor een portfolio van B2B-softwarebedrijven, en we hebben dit vaak genoeg zien gebeuren om er een patroon in te herkennen. Als ARR-rapportage stukgaat, gebeurt dat meestal om een van een paar redenen, en de oplossing is bijna altijd dezelfde. Vraag het CRM niet langer om ARR live te berekenen, maar bouw een speciaal daarvoor bedoeld record dat we een snapshot noemen. Dit stuk legt uit wat dat betekent, aan de hand van twee heel verschillende opdrachten waarin een custom snapshot stilletjes het stuk was dat de cijfers van finance weer logisch maakte.
Waarom standaard ARR-rapportage in Salesforce en HubSpot tekortschiet
Annual recurring revenue (ARR) klinkt als één getal, maar is eigenlijk een vraag met een datum eraan. Wat is onze terugkerende omzet per vandaag? Per het einde van vorig kwartaal? Per over een jaar, als deze verlengingen binnen zijn en die contracten aflopen? Elk daarvan is een ander getal, en een gezond bedrijf moet ze allemaal kunnen zien.
Het probleem is dat CRM's als Salesforce en HubSpot gebouwd zijn om lopende deals te managen, niet om te onthouden hoe je omzet er op een bepaald moment uitzag. Hun standaardrapporten lezen de live stand van je records op dit moment. Dat werkt prima voor een pipelinerapport. Voor ARR valt het uit elkaar, om drie redenen die steeds weer terugkomen.
- Ten eerste is er geen geheugen. Een standaardrapport kan je vertellen wat er vandaag in een deal staat, niet wat er in maart stond. Zodra iemand een gesloten contract aanpast, korting geeft op een verlenging of een waarde corrigeert, is de historie weg, en daarmee elke hoop op een kloppende ARR-waterfall die laat zien hoe je van het getal van vorig jaar bij dat van dit jaar kwam. In de enquête van Xactly uit 2024 onder 405 sales- en finance-leiders zei 66% dat hun rapportagesystemen geen toegang hadden tot historische CRM- of prestatiedata (Xactly, 2024).
- Ten tweede breken meerjarige contracten het model. Een driejarige deal van €300k is geen €300k ARR, en vaak niet eens €100k per jaar, omdat het jaarbedrag gedurende de looptijd kan stijgen of dalen. Eén bedragveld op één opportunity kan geen omzet weergeven die tegelijk in meerdere jaren valt. Teams gaan records met de hand klonen, en die handmatige kopieën lopen vrijwel meteen uit de pas. In de EU kunnen klanten nu bovendien halverwege een contract overstappen dankzij de Data Act.
- Ten derde lopen terugkerende en eenmalige omzet door elkaar. Onboardingfees, professional services en setupkosten belanden allemaal in hetzelfde totaal als abonnementen en licenties. Tenzij iets ze scheidt, erft je ARR stilletjes omzet die nooit terugkomt, en is het getal waar investeerders het meest om geven nu het getal dat het vaakst fout is.
Wat een custom ARR-snapshot is en hoe het werkt
De oplossing is minder exotisch dan ze klinkt. In plaats van een rapport ARR ter plekke uit live deals te laten afleiden, maken we aparte records waarvan de enige taak is ARR vast te houden zoals jij die wilt zien. Die records zijn de "snapshot".
In de praktijk betekent dit meestal een object dat aan alle deals of opportunities hangt. Als een contract sluit, leest automatisering het uit en maakt één child-record per jaar van de looptijd. Een eenjarig contract levert één record op. Een driejarig contract levert er drie op, elk met het terugkerende bedrag van dat jaar, het omzettype en de periode die het dekt. Elk record classificeert omzet als terugkerend of eenmalig, zodat abonnementen en gebruik meetellen voor ARR en onboarding en services niet.
Zodra de data die vorm hebben, wordt rapporteren vrij eenvoudig. Simpele roll-ups tellen ARR op per jaar, per omzettype, per product of per account. Je kunt de actieve ARR per vandaag laten zien, de ARR die volgend jaar afloopt en de verlengingen en expansions die die gaan vervangen, allemaal uit dezelfde set records.
De diepere kern zit in het ontkoppelen. Je live deals blijven bewerkbaar en rommelig, en het salesteam werkt ongestoord door. Je ARR leeft in een aparte, stabiele laag die vastlegt wat waar is en zichzelf niet stilletjes herschrijft als iemand een opportunity aanraakt. Die scheiding maakt van ARR een getal dat mensen vertrouwen in plaats van een getal waarover ze discussiëren. De twee opdrachten hieronder, beide geanonimiseerd, kwamen vanuit twee totaal verschillende startproblemen bij dezelfde scheiding uit.
Hoe een snapshot een ARR-dashboard rechtzette dat er miljoenen naast zat
De eerste was een groeiend B2B-softwarebedrijf dat meerjarige abonnementen verkocht met een mix van licenties, gebruik en onboardingfees. Het ARR-dashboard gaf ruwweg 3 miljoen dollar aan. De werkelijke closed-won ARR lag dichter bij 5,5 miljoen. Een gat van die omvang is geen afrondingsverschil; het is het verschil tussen een bedrijf dat stil lijkt te staan en een bedrijf dat hard groeit, en het kwam verkeerd terug in de cijfers waarmee de leiding het bedrijf stuurde.
De oorzaken waren precies die van hierboven, opgestapeld. Ongeveer 2 miljoen dollar aan business zat in opportunities die nooit netjes waren vastgelegd, dus standaardrapporten zagen die gewoon niet. Historische contracten bevatten handmatige rekenfouten, waaronder deals waarvan de usage-based pricing niet aansloot op de vastgelegde contractwaarde. En omdat het CRM geen cumulatieve ARR door de tijd kon tonen, had het team zijn toevlucht genomen tot een fragiele workaround. Het combineerde gewonnen en renewal-opportunities, filterde op actieve contracten en accepteerde dat open new business onzichtbaar bleef. Het dashboard loog niet zozeer, het beantwoordde een vraag die niemand had gesteld.
We bouwden een ARR Snapshot-object bovenop de bestaande quote-to-deal-structuur van het bedrijf. Als een contract sloot, rekende automatisering het om naar jaarbasis in één snapshotrecord per product, per jaar van de looptijd. Een eenjarige deal leverde één record op; een meerjarige deal één per jaar. Elke regel werd gelabeld als terugkerend of eenmalig, zodat de totale contractwaarde en de terugkerende ARR eindelijk aparte grootheden waren in plaats van hetzelfde getal met twee petten op. Roll-upvelden telden ARR vervolgens op per jaar en per omzettype over het hele boek.
Ook de rapportagestandaard veranderde. In plaats van een gemiddelde of de volledige contractwaarde te noemen, ging iedereen over op Year One ARR als gemeenschappelijke munt, van de salestool tot de manier waarop account executives werden beloond, zodat dezelfde definitie van begin tot eind gold. Gesloten deals maakten automatisch de opportunity voor de volgende cyclus aan en een nieuwe set snapshots, waardoor het team verlengingen twee en drie jaar vooruit kon projecteren en op elk moment kon zien welke ARR actief was, welke afliep en welke expansions die moesten vervangen.
Niets hiervan ging in één keer. De ARR-definitie zelf werd in de eerste paar maanden vier of vijf keer bijgesteld naarmate edge cases bovenkwamen, van expansions met afwijkende einddata tot historische deals die opnieuw moesten worden geaudit. Dat is de eerlijke realiteit van dit werk. Het snapshotobject geeft je een plek om gelijk te hebben, maar je moet nog steeds de reconciliatie doen om daar te komen. Wat blijvend veranderde, was dat het bedrijf eindelijk één bron van waarheid voor ARR had, onderbouwd door de onderliggende producten, in plaats van een dashboard dat stilletjes verschoof elke keer dat een rep een deal aanpaste.
Hoe een snapshot een ARR-waterfall opleverde die klaar was voor due diligence
De tweede opdracht was bij een softwarebedrijf op het gebied van duurzaamheid dat richting een financieringsronde ging, waar de ARR-waterfall geen nice-to-have was maar een voorwaarde voor de due diligence. Commissieplannen, kwartaal- en jaartargets, boardrapportage en de OKR's van het bedrijf hingen er allemaal aan, en commerciële en financiële due diligence liepen parallel. De forecast moest zelfs van twee naar drie jaar worden opgerekt om aan het proces te voldoen. Hier zou een foute ARR niet alleen het team misleiden; externe investeerders zouden hem regel voor regel doorlichten.
Hier was de eerdere, eenvoudigere aanpak juist het probleem geworden. Het bedrijf leunde op statische ARR-cijfers op één moment, en die verhulden precies de dingen waar due diligence om draait. Meerjarige deals met bedragen die per jaar verschilden, werden platgeslagen tot één getal. Vroege verlengingen en expansions overlapten met hun oorspronkelijke contracten, waardoor omzet over kwartalen dubbel werd geteld. In één geval bundelde een expansion oorspronkelijke en nieuwe producten, met abonnementsdata die zo'n vijf maanden overlapten, en de statische snapshot kon dat op geen enkele manier netjes weergeven.
De aanpak combineerde twee stappen. Eerst beschermden we de integriteit van de waterfall zelf. Toen iemand voorstelde een renewal-korting door te voeren door historische productdata te herschrijven, gingen we daartegenin, omdat dat de ARR-historie, de commissieberekeningen en de boardcijfers in één klap zou hebben beschadigd. De regel werd dat je het verleden nooit herschrijft. Voer de korting door bij de verlenging, annoteer de wijziging en laat het record tonen wat er werkelijk gebeurde. Lastige scenario's kregen een expliciete behandeling in plaats van gesjoemel, dus een driejarige deal met een opzegclausule na drie maanden werd behandeld als een korte, niet-terugkerende pilot vooraf, en daarna als standaard-ARR vanaf maand vier als de klant bleef.
Ten tweede groeide de snapshot van één getal uit tot een schema per contractjaar. Een contract van €300k was niet langer één getal; het was €100k per jaar over drie jaar, elk met eigen factuurdata en elk vastgelegd als eigen record. Dat schema per jaar voedde de waterfall direct en vormde tegelijk de ruggengraat van een finance-exercitie. Vanuit het contract werkend legde het team vast wat er gefactureerd had moeten worden en wanneer, stemde dat af met de historische boekhouding en stelde de ontbrekende toekomstige facturen op. Het contract gold als bron van waarheid, en het boekhoudsysteem werd daarop aangepast, niet andersom. Die volgorde deed ertoe, want zo kwam echte revenue leakage boven, waaronder apart gecontracteerde services die nooit waren gefactureerd.
Het resultaat was een waterfall waar het bedrijf echt achter kon staan. Half januari werkte hij en kwam hij voor het jaar uit op 5,4 miljoen dollar, in afwachting van de laatste validatie tegen de factuurdata, met nog maar een handvol opportunities zonder ARR. Bij een due diligence is het verschil tussen een getal dat je beweert en een getal dat je kunt herleiden, contract voor contract en jaar voor jaar, het verschil tussen een soepel en een pijnlijk proces.
Waarom ARR-snapshots werken waar standaard CRM-rapporten falen
Dit waren verschillende bedrijven, op verschillende CRM's, met verschillende problemen. De een telde miljoenen ARR te weinig; de ander telde te veel door dubbel getelde overlappingen en platgeslagen meerjarige deals. De een moest de eigen leiding overtuigen; de ander investeerders. Toch kwamen beide uit bij dezelfde structurele oplossing, en dat is geen toeval.
De reden is dat ARR in de kern een tijdreeksvraag is, gesteld aan een systeem dat ontworpen is om alleen het heden op te slaan. Geen hoeveelheid rapporten bouwen lost die mismatch op, omdat de informatie die je nodig hebt, welke omzet terugkerend was, in welk jaar, per wanneer, simpelweg niet in één live deal zit. Je kunt alleen rapporteren over data die je hebt vastgelegd, en standaardrecords leggen dit niet vast. Een snapshot wel. Die legt ARR vast in de vorm waarin de vraag echt wordt gesteld, dus per jaar, per type en op een moment dat vast blijft staan.
Al het andere volgt uit data in de juiste vorm. Roll-ups worden triviaal. Waterfalls worden eerlijk, omdat de historie eronder niet meer verschuift. Beloningsplannen en boarddecks putten uit dezelfde records, dus sales, finance en de board discussiëren eindelijk over strategie in plaats van over wiens getal klopt. De snapshot is niet slim; het is gewoon het verschil tussen ARR onder druk afleiden en hem al hebben vastgelegd.
Wanneer je een ARR-snapshotlaag in je CRM nodig hebt
Een snapshotlaag heb je op dag één waarschijnlijk niet nodig. Als elke deal een eenjarig abonnement is en je een paar dozijn klanten hebt, volstaan de standaardrapporten. Het patroon verdient zich terug zodra de complexiteit komt, en er zijn een paar betrouwbare signalen dat dat moment er is.
Het duidelijkste signaal is dat je je eigen ARR-getal niet meer volledig vertrouwt, of dat twee mensen in het bedrijf er twee verschillende versies van kunnen produceren. Vlak daarachter komen het meerjarige contract waarvan niemand precies weet hoe je het rapporteert, de verlenging of expansion die dubbel lijkt te tellen, en finance- en salesteams die werken met cijfers die nooit helemaal aansluiten. Nadert er een fundraise of audit, dan ligt de lat nog hoger, want je moet ARR per jaar en per contract kunnen herleiden, niet alleen een totaal beweren, en een spreadsheet die uit het geheugen is opgebouwd overleeft die toets niet.
Weet je niet zeker hoe ver je je eigen ARR-getal kunt vertrouwen, dan rangschikt onze CRM and GTM Health Check de gaten en lost hij de eerste op.
Het bemoedigende is dat dit een opgelost probleem is. Je hoeft niet te migreren of nog een platform te kopen; in beide gevallen hierboven werd het antwoord gebouwd in het CRM dat het bedrijf al had. Wat het vraagt, is ARR behandelen als data die je bewust vastlegt in plaats van een getal dat je onder druk afleidt, en bereid zijn de reconciliatie één keer te doen, zodat het getal daarna klopt.
Begint je ARR meer te voelen als een discussie dan als een feit, dan is dat meestal het moment waarop het snapshotpatroon zichzelf terugverdient. Het is een van de onderdelen van de revenue-infrastructuur met de meeste hefboom die een groeiend softwarebedrijf kan neerzetten, juist omdat alles daarna, forecasting, beloning en het verhaal dat je aan investeerders vertelt, ervan afhangt dat dit ene getal klopt.
FAQ over ARR-rapportage
Wat is ARR-rapportage?
ARR-rapportage toont de op jaarbasis omgerekende waarde van je terugkerende contracten op een bepaald moment en verklaart hoe die tussen twee data bewoog. Een degelijk ARR-rapport scheidt terugkerende van eenmalige omzet, splitst meerjarige contracten per jaar en is voor elke datum in het verleden te reproduceren.
Waarom komt de ARR in ons CRM niet overeen met het getal van finance?
Meestal omdat ze verschillende dingen op verschillende momenten meten. Standaardrapporten in het CRM lezen de live stand van deals, dus de historie verandert zodra iemand een record aanpast. HubSpots standaard ARR-property wordt bijvoorbeeld berekend uit de terugkerende line items en de looptijd van een deal, niet uit het dealbedrag (HubSpot), terwijl finance met billingdata werkt. Spreek één definitie af en stem record voor record af.
Wat is een ARR-waterfall?
Een ARR-waterfall, of bridge, verklaart de verandering in ARR over een periode. Begin-ARR, plus nieuwe en expansion-ARR, min contraction en churn, is eind-ARR. Onze Five Dots-methode bouwt hem klant voor klant op, telt alleen terugkerende omzet en toont bewegingen bruto, omdat een expansion en een even grote churn niet "geen verandering" zijn.
Hoe tellen meerjarige contracten mee voor ARR?
Er is geen universeel juiste conventie, maar er moet er wel één zijn, afgesproken met finance. De keuzes die we het vaakst zien zijn Year One ARR voor bookings en commissie, waarden per jaar voor de waterfall, gemiddelde ARR voor ramp deals en de ARR van het laatste jaar als basis voor de verlenging. De totale contractwaarde hoort nooit in ARR terecht te komen.
Kan HubSpot of Salesforce ARR standaard rapporteren?
Beide kunnen rapporteren op velden voor terugkerende omzet, maar wat ze laten zien hangt af van hoe deals zijn opgebouwd. De recurring revenue analytics van HubSpot vereisen bijvoorbeeld een Enterprise-abonnement en lezen handmatig ingevoerde properties voor terugkerende omzet, niet de producten of quotes op een deal (HubSpot). Voor meerjarige contracten en een waterfall waar finance voor tekent, voegen de meeste teams waarmee we werken een snapshotobject toe.
