SaaS revenue reconciliation

SaaS revenue reconciliation is het maandelijks op klantniveau op elkaar afstemmen van vier bronnen: wat er in het CRM is verkocht, wat de billing factureert, wat er is betaald en wat de boekhouding als omzet verantwoordt. Het doel is dat elk verschil tussen die bronnen een verklaring heeft. Verschillen die je kunt verklaren (timing, definities) laat je staan. Verschillen die je niet kunt verklaren zijn fouten, en een deel daarvan is omzet die je misloopt.

Waarom SaaS-cijfers per definitie niet op elkaar aansluiten

Bij een SaaS-bedrijf bestaan er minstens vier getallen die allemaal "omzet" heten, en ze horen niet gelijk te zijn.

• Gecontracteerde ARR in het CRM: de jaarwaarde van wat er getekend is, vaak inclusief contracten die nog niet zijn gestart.
• Gefactureerde MRR of ARR in de billing: wat er op dit moment als terugkerend abonnement loopt.
• Ontvangen betalingen: wat er daadwerkelijk op de bank is binnengekomen.
• Verantwoorde omzet in de boekhouding: wat er volgens de verslaggevingsregels in deze periode als opbrengst telt. Een jaarfactuur die in januari vooruit wordt betaald, wordt over twaalf maanden als omzet verantwoord. De rest staat als vooruitontvangen bedrag op de balans.

Het is dus niet de vraag of deze getallen verschillen. Ze verschillen altijd. De vraag is of je elk verschil kunt uitleggen. Reconciliation is het werk dat daarvoor zorgt.

Voor het bredere kader, waarin CRM, billing en productgebruik bij SaaS worden verbonden, zie Revenue Intelligence voor SaaS.

Drie soorten verschillen

Elk verschil dat je vindt, valt in een van drie categorieën. Het helpt om ze vanaf het begin zo te labelen, omdat je ze anders behandelt.

De eerste maand dat je reconcilieert, is het merendeel van de verschillen vaak van het soort definitie. Dat is geen verspilde tijd. Elk definitieverschil dat je oplost, maakt de volgende maand sneller, en het maakt je rapportages eindelijk vergelijkbaar. Welke bron voor welk getal leidend moet zijn, staat in welke databron leidend is voor omzet.

De vier aansluitingen

1. CRM tegen billing

Per klant: komt de gecontracteerde waarde in het CRM overeen met het abonnement in de billing? Kijk naar prijs per eenheid, hoeveelheid, kortingen en looptijd. Dit is de aansluiting waar de meeste fouten zitten die omzet kosten, omdat de overdracht van deal naar abonnement meestal met de hand gebeurt. Hoe je deze specifieke afstemming aanpakt, staat uitgebreid in CRM-to-billing reconciliation.

Veelvoorkomende bevindingen:

• Gesloten deals zonder abonnement.
• Abonnementen zonder bijbehorende deal (vaak oude klanten of handmatige verlengingen).
• Upsells die als nieuwe deal in het CRM staan, maar niet als wijziging in de billing zijn doorgevoerd.

2. Billing tegen gebruik

Per klant: zit het gebruik in het product binnen wat er wordt gefactureerd? Bij seat-based pricing vergelijk je actieve gebruikers met gefactureerde seats. Bij usage-based pricing vergelijk je het gemeten volume in het product met het volume op de factuur. Verschillen hier zijn ofwel onbenutte omzet (meer gebruik dan gefactureerd) ofwel een signaal van churn-risico (veel minder gebruik dan gefactureerd).

3. Billing tegen betalingen

Per factuur: is hij betaald, en is het betaalde bedrag gelijk aan het gefactureerde bedrag? Let op deelbetalingen, gestorneerde incasso's en betalingen die op het verkeerde account zijn geboekt. Een openstaande factuur bij een actief account is de meest directe vorm van lekkage: de klant gebruikt het product en betaalt niet.

4. Billing tegen boekhouding

Per maand: sluit het totaal aan gefactureerde bedragen aan op wat er in de boekhouding (bijvoorbeeld Exact, Twinfield of AFAS) als omzet en vooruitontvangen bedragen is geboekt? Hier vind je facturen die buiten de billing om zijn gemaakt, creditnota's die niet zijn doorgeboekt, en verschillen in de periode waarin omzet wordt verantwoord.

De ARR-brug: één tabel die alles verklaart

Een handig hulpmiddel is de ARR-brug: een tabel die de ARR aan het begin van de maand verbindt met de ARR aan het eind, via elke beweging daartussen.

Maak deze brug twee keer: één keer uit het CRM en één keer uit de billing. Waar de regels verschillen, zit je werk. Als het CRM €42.000 expansion laat zien en de billing €28.000, dan is er €14.000 aan upgrades verkocht die niet worden gefactureerd, of er is een definitieverschil in wat als expansion telt. Dit zijn voorbeeldbedragen.

Een maandelijks stappenplan

Dit is een werkbaar ritme voor een finance-team dat het zonder speciale software doet.

1. Werkdag 1 tot 3: exporteren. Gesloten en gewijzigde deals uit het CRM, alle actieve abonnementen uit de billing, openstaande facturen, gebruiksdata per klant.
2. Werkdag 3: koppelen. Elke klant één regel, met de waarden uit alle bronnen naast elkaar. Dit werkt alleen als je een gedeelde klant-ID hebt.
3. Werkdag 4: verschillen markeren. Stel drempels in. Bijvoorbeeld: elk verschil boven €50 per maand per klant, of boven 5 procent van de contractwaarde.
4. Werkdag 4 en 5: labelen. Timing, definitie of fout. Alleen de fouten gaan door naar de volgende stap.
5. Werkdag 5: eigenaar toewijzen. Elke fout krijgt een eigenaar en een deadline. Finance voor factuurfouten, sales voor contractwijzigingen, customer success voor gebruik boven contract.
6. Werkdag 10: afsluiten. Welke fouten zijn opgelost, welk bedrag is teruggehaald, welke oorzaak zat erachter?
7. Elk kwartaal: oorzaken analyseren. Als dezelfde soort fout drie maanden op rij terugkomt, zit het probleem in het proces, niet in de uitvoering.

Rekenvoorbeeld: stel de eerste reconciliation

Stel, je hebt 350 klanten en doet voor het eerst een volledige reconciliation. Je vindt 90 verschillen. Dit zijn voorbeeldaantallen, bedoeld om de verdeling te illustreren.

• 45 zijn timing: contracten die net voor of na de maandgrens zijn gestart.
• 25 zijn definitie: eenmalige fees die in het CRM in ARR zijn meegeteld.
• 20 zijn fouten. Daarvan gaan er 12 over een te lage factuur, gemiddeld €180 per maand, en 8 over een te hoge factuur, gemiddeld €90 per maand.

De te lage facturen zijn samen 12 x €180 x 12 = €25.920 per jaar aan omzet die je vanaf nu wel factureert. De te hoge facturen zijn samen 8 x €90 x 12 = €8.640 per jaar die je moet corrigeren, en die je beter zelf vindt dan dat de klant het doet. Beide zijn winst: het eerste direct, het tweede in vertrouwen.

De tweede maand vind je minder, omdat de definities zijn opgelost en de oude fouten zijn gecorrigeerd. Wat overblijft, zijn de nieuwe fouten. Dat is het getal dat je wilt zien dalen.

Waar reconciliation vastloopt

Geen gedeelde klant-ID. Als je CRM-accounts niet één op één te koppelen zijn aan billing-klanten, besteed je het grootste deel van de tijd aan matchen op naam. Los dit eerst op, ook al voelt het als voorwerk.

Te veel verschillen zonder drempel. Een verschil van €0,40 door afronding is geen bevinding. Zonder drempel verdrink je in ruis en haakt het team na twee maanden af.

Geen eigenaar. Een lijst met verschillen die in een gedeelde map staat, wordt niet opgelost. Elke fout moet bij een persoon terechtkomen.

Alleen totalen vergelijken. Als je alleen de totale ARR uit CRM en billing vergelijkt, kunnen fouten elkaar opheffen. Een klant die te veel betaalt en een klant die te weinig betaalt, vallen in het totaal tegen elkaar weg. Reconcilieer altijd per klant.

Van handwerk naar doorlopende controle

De maandelijkse handmatige reconciliation is een goed begin, maar heeft een ingebouwde vertraging: een fout die op de tweede van de maand ontstaat, vind je op zijn vroegst een maand later. Bij terugkerende omzet is dat een maand lekkage per fout.

De volgende stap is dat de koppeling tussen de bronnen doorlopend gebeurt, zodat een afwijking zichtbaar wordt op de dag dat hij ontstaat. Dat kan met een eigen datapijplijn naar een warehouse zoals Snowflake, of met software die de systemen direct leest. De logica blijft dezelfde als hierboven: per klant, per bron, met drempels en een eigenaar. Waar de meeste verschillen tussen billing en contract vandaan komen, staat in SaaS billing leakage. Een vergelijkbare aanpak voor contractwaarde in het algemeen staat in contractwaarde tegen gerealiseerde omzet.

Veelgestelde vragen

Wat is het verschil tussen revenue reconciliation en een bankreconciliatie?

Een bankreconciliatie controleert of je boekhouding overeenkomt met je bankafschrift. Revenue reconciliation controleert of wat er is verkocht, gefactureerd, gebruikt en ontvangen op elkaar aansluit, per klant. Het eerste gaat over geld dat binnenkwam, het tweede ook over geld dat had moeten binnenkomen.

Hoe vaak moet een SaaS-bedrijf reconciliëren?

Minimaal maandelijks, gekoppeld aan de maandafsluiting. Bedrijven met veel usage-based pricing of veel tussentijdse wijzigingen hebben baat bij een hogere frequentie, omdat elke week vertraging een week lekkage is.

Moet ARR in het CRM gelijk zijn aan ARR in de billing?

Niet per se, maar elk verschil moet verklaarbaar zijn. Het CRM mag contracten bevatten die nog niet zijn gestart. De billing mag abonnementen bevatten die al zijn opgezegd maar nog doorlopen. Zolang je dat per klant kunt aanwijzen, is het verschil in orde.

Wie is eigenaar van revenue reconciliation?

Meestal finance, omdat het aansluit op de maandafsluiting. Maar de oplossing van de gevonden fouten ligt vaak bij sales of customer success. Spreek vooraf af wie welke soort fout oplost, anders blijft de lijst liggen.