Je statuspagina stond afgelopen dinsdag vier uur lang op rood. Op vrijdag had je aan elke getroffen klant servicecredits uitgegeven — hier 10 procent van een maandbedrag, daar 25 procent — en je boekhouder boekte ze zoals de meeste kleine SaaS-bedrijven dat doen: als supportkosten, of als marketingconcessie, ergens onder de omzetregel. Je omzet voor de maand is nu te hoog voorgesteld, je net revenue retention is onjuist, en als een kredietverstrekker of overnemende partij ooit je boeken opent, is de eerste vraag precies degene die je niet kunt beantwoorden: hoeveel van de omzet die je rapporteerde, had je eigenlijk mogen behouden?
Dit is geen randgeval. Een gemiddelde storing kost nu 196 minuten om op te lossen, en kleine en middelgrote bedrijven schatten de kosten van een uur downtime op ongeveer $8.000 — nog voordat er één credit is uitgegeven. Elke credit die je na een storing verleent, is een verlaging van de prijs die je klant is overeengekomen te betalen, en onder ASC 606 maakt dat het een variabele vergoeding: een bedrag dat je omzet verkleint, geen kostenpost die eronder staat. Dit artikel legt uit waartoe je SLA je financieel verplicht, hoe de standaard wil dat je het boekt, en wat je bij je volgende maandafsluiting moet corrigeren.
Wat je SLA daadwerkelijk belooft — in dollars, niet in negens
De meeste SaaS-contracten drukken uptime uit in "negens": 99,9 procent (ongeveer 43 minuten downtime per maand), 99,95 procent, 99,99 procent (ongeveer 4 minuten). Het getal dat voor je boeken telt, zijn niet de negens maar het creditschema dat eraan hangt. Een typisch enterprise-SLA luidt ongeveer zo: uptime onder 99,9 procent levert de klant een servicecredit van 10 procent op; onder 99,0 procent, 25 procent; onder 95,0 procent, een volledige maand gratis. Sommige contracten escaleren verder en bieden opzeggingsrechten als de uptime meerdere maanden op rij de doelstelling mist.
Drie kenmerken van dat schema bepalen de boekhouding:
Credits zijn een contractuele prijsaanpassing, geen geste van goede wil. De klant betaalt niet de volle prijs en ontvangt daarna een cadeau. Het contract zegt dat de prijs voor een slechte maand een lagere prijs is. Dat onderscheid — prijsverlaging versus kostenpost — is de hele boekhoudkundige vraag, en het contract beantwoordt die voordat je boekhouder ooit het grootboek opent.
Credits zijn meestal gemaximeerd en moeten worden aangevraagd, niet automatisch. Veel SLA's vereisen dat de klant de credit binnen 30 dagen aanvraagt, en beperken het totale creditbedrag tot 30 tot 100 procent van één maandbedrag. Dat betekent dat je blootstelling bij een gegeven storing begrensd en schatbaar is: je kent het schema, je weet welke klanten zijn getroffen, en je kent je historische claimpercentage.
De cash-timing en de omzet-timing lopen uiteen. Een credit die in februari wordt uitgegeven voor een storing in januari, verschijnt meestal als creditnota tegen een toekomstige factuur. Het cash-effect valt op het moment dat de factuur wordt betaald, maar het omzeteffect hoort bij januari — de periode waarin je niet leverde wat je beloofde. De credit boeken in de maand waarin je hem uitgeeft, tegen de omzet van die maand, stelt twee perioden tegelijk onjuist voor.
Waarom ASC 606 een storingscredit als variabele vergoeding aanmerkt
Het kernidee van ASC 606 is eenvoudig: verantwoord omzet voor het bedrag aan vergoeding dat je verwacht te mogen ontvangen in ruil voor het leveren van wat je hebt beloofd. Stap 3 van het vijfstappenmodel — het bepalen van de transactieprijs — is waar je SLA in beeld komt. De transactieprijs is niet de stickerprijs op het bestelformulier. Het is de stickerprijs minus alles wat kan terugkomen: restituties, kortingen, rabatten, prestatiebonussen — en servicecredits voor gemiste uptime.
De omzetgids van PwC plaatst SLA-credits precies in dit vakje. Variabele vergoeding moet bij aanvang van het contract worden geschat en elke verslagperiode worden bijgewerkt, met een van twee methoden:
- Verwachte waarde — het met waarschijnlijkheid gewogen gemiddelde over mogelijke uitkomsten. Dit past goed bij een portefeuille klanten: als de historie zegt dat 3 procent van de maandelijkse facturering doorgaans als SLA-credits terugkomt, is je verwachte credit op $100.000 aan maandelijkse facturering $3.000.
- Meest waarschijnlijke bedrag — de enkele meest waarschijnlijke uitkomst. Dit past bij een binaire situatie: één grote klant wiens contract deze maand ofwel een credit van $20.000 activeert, ofwel niets.
Dan komt de beperking, het deel dat oprichters het vaakst overslaan. Je mag variabele vergoeding alleen in de transactieprijs opnemen — dat wil zeggen de omzet verantwoorden — voor zover het waarschijnlijk is dat een significante terugdraaiing niet optreedt wanneer de onzekerheid zich oplost. In gewone taal: als er een reële kans is dat je de credit moet terugbetalen, tel dat stuk dan nog niet als omzet. Neem het op als terugbetalingsverplichting en werk het bij wanneer de uptime van de maand bekend is.
Let op wat de beperking betekent voor een SaaS-bedrijf met een noemenswaardige storingshistorie. Als je service in vier van de laatste twaalf maanden de SLA miste, is "we verwachten niets verschuldigd te zijn" geen verdedigbare schatting. Je eigen statuspagina is het bewijsstuk A van de accountant.
De journaalposten: een maand met een storing
Stel dat één klant $10.000 per maand betaalt, en je SLA van 99,9 procent een credit van 10 procent verleent voor elke maand waarin de uptime onder de doelstelling zakt. De uptime van januari komt uit op 99,4 procent. Hier is de volledige cyclus.
Bij facturering is het gefactureerde bedrag zoals gebruikelijk uitgestelde omzet — ontvangen cash (of geboekte vordering) voor nog niet geleverde service:
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Assets:Receivable:Customer USD
2026-01-01 open Income:SaaS:Subscription USD
2026-01-01 open Liabilities:Deferred-Revenue:SaaS USD
2026-01-01 open Liabilities:Refund:SLA-Credits USD
2026-01-01 * "Customer" "January invoice — 10,000 monthly subscription"
Assets:Receivable:Customer 10000.00 USD
Liabilities:Deferred-Revenue:SaaS -10000.00 USD
2026-01-31 * "Month-end" "Recognize January revenue net of 500 expected SLA credits"
Liabilities:Deferred-Revenue:SaaS 10000.00 USD
Liabilities:Refund:SLA-Credits -500.00 USD
Income:SaaS:Subscription -9500.00 USD
2026-02-05 * "Customer" "Outage credit issued — January uptime 99.4 percent vs 99.9 SLA"
Liabilities:Refund:SLA-Credits 500.00 USD
Assets:Receivable:Customer -500.00 USDLoop door wat er gebeurde. Bij de maandafsluiting verantwoordde je $9.500 omzet en parkeerde je $500 in een terugbetalingsverplichting — je schatting van de credit die de storing van januari zal activeren. Wanneer de daadwerkelijke creditnota in februari uitgaat, debiteert die de verplichting, niet de omzet en niet een kostenrekening. De omzet van januari was de eerste keer al juist, en de omzet van februari blijft onaangetast door de storing van januari.
Als de schatting en het werkelijke bedrag verschillen, past het verschil de omzet aan in de periode waarin de onzekerheid zich oplost. $500 geschat maar $1.000 uitgegeven omdat twee klanten claimden in plaats van één? De extra $500 verlaagt de omzet wanneer je het te weten komt. $500 geschat en niemand claimde? Laat de $500 vrijvallen naar omzet. De verplichtingenrekening is de schokdemper; de omzet wordt nooit herzien voor een routineuze bijstelling.
Twee details die je goed moet doen. Ten eerste staat de terugbetalingsverplichting los van de uitgestelde omzet: uitgestelde omzet is voor service die je nog niet hebt geleverd, terwijl de terugbetalingsverplichting is voor geleverde service die je mogelijk moet teruggeven. Ze tegen elkaar wegstrepen verbergt beide verhalen. Ten tweede: als een credit betrekking heeft op een toekomstige periode — een gratis maand als excuus in plaats van een contractuele credit voor een eerdere tekortkoming — is dat een andere analyse, dichter bij een contractwijziging of een materieel recht, en die past de toekomstige omzet aan in plaats van het verleden.
De drie fouten die SaaS-oprichters maken met SLA-credits
Fout 1: de credit als kostenpost boeken. Dit is de meest voorkomende fout en de meest schadelijke. Een storingscredit van $10.000 boeken als debet op "klantenservicekosten" of "marketingconcessies" laat de omzet $10.000 te hoog en verzint $10.000 aan kosten die nooit zijn gemaakt. Brutomarge, omzetgroei en elke ratio die op omzet is gebaseerd, vallen allemaal te hoog uit. Onder ASC 606 verlagen bedragen die aan de klant verschuldigd zijn en niet in ruil voor een afzonderlijk goed of een afzonderlijke dienst worden ontvangen, de transactieprijs. Een credit voor je eigen storing levert je niets afzonderlijks op — het verlaagt de omzet, punt uit.
Fout 2: nu de volledige omzet verantwoorden en het later corrigeren. Sommige bedrijven boeken de volledige $10.000 als omzet van januari en boeken de credit van $1.000 vervolgens tegen de omzet van februari wanneer de creditnota uitgaat. Beide maanden zijn nu onjuist: januari te hoog, februari te laag. Erger nog, de fout versterkt zich in je statistieken — de net revenue retention van januari ziet er geweldig uit, die van februari zwak, en geen van beide weerspiegelt de werkelijkheid. Het patroon met de terugbetalingsverplichting hierboven bestaat juist om elke periode eerlijk te houden.
Fout 3: nul schatten omdat de storing "niet weer zal gebeuren". De beperking draait op waarschijnlijkheid, niet op optimisme. Als je infrastructuur vorig jaar drie maanden had die de SLA activeerden, is een schatting van nul verwachte credits niet conservatief of agressief — hij is niet onderbouwd. Accountants toetsen deze schatting aan je incidenthistorie, en overnemende partijen doen bij due diligence hetzelfde. Een kleine permanente reserve, gebaseerd op historische claimpercentages en maandelijks bijgesteld, is zowel nauwkeuriger als veel makkelijker te verdedigen dan een zelfverzekerde nul die je statuspagina tegenspreekt.
Wat dit doet met de statistieken die kopers en kredietverstrekkers lezen
SLA-credits boven de omzetregel versus eronder plaatsen verandert elk getal waarop een SaaS-bedrijf wordt gewaardeerd:
- MRR en ARR moeten netto zijn van verwachte credits. Als 2 procent van de facturering historisch als SLA-credits terugkomt, is een ARR-kop van $1 miljoen in werkelijkheid $980.000 aan verwachte omzet. Het brutogetal rapporteren is hoe oprichters in due diligence een "churn-probleem" moeten uitleggen dat eigenlijk al die tijd een creditprobleem was.
- Net revenue retention absorbeert credits als contractie. Een klant die vorig jaar $120.000 betaalde en dit jaar $114.000 na storingscredits, behield 95 procent, niet 100 procent — zelfs als die nooit een zitplaats heeft opgezegd.
- Brutomarge stijgt paradoxaal genoeg wanneer je de fout corrigeert. Credits uit supportkosten halen en in contra-omzet plaatsen verkleint zowel de omzet als de kostprijs van de omzet, en omdat de credit groter is dan eventuele bijbehorende kosten, verbetert het margepercentage terwijl de omzet daalt. Verwacht de vraag, en houd de herziene historie klaar.
Als je plain-text accounting gebruikt, is de oplossing structureel in plaats van procedureel: een aparte Liabilities:Refund:SLA-Credits-rekening, een maandafsluitingspost die abonnementsomzet verantwoordt netto van de verwachte credit, en een bijstellingspost wanneer creditnota's uitgaan. De beancount-documentatie over patronen voor omzetverantwoording behandelt de algemene vorm van de uitgestelde-omzet-boekhouding waarop dit voortbouwt, en de balanshistorie van de terugbetalingsrekening dient tegelijk als je audit trail voor de schatting.
Een maandafsluitingschecklist van twintig minuten
- Haal de uptime per klantniveau op. Je monitoring berekent dit al; vraag het maandcijfer op tegen elke SLA-drempel, niet alleen het gemiddelde van het hele bestand.
- Maak een lijst van geactiveerde credits. Bereken voor elke klant onder de drempel de contractuele credit uit het schema — voordat je controleert wie daadwerkelijk heeft geclaimd.
- Pas je historische claimpercentage toe. Als historisch ongeveer 60 procent van de geactiveerde credits wordt geclaimd, is je verwachte waarde 60 procent van het geactiveerde totaal. Documenteer het percentage en herzie het per kwartaal.
- Boek de omzet netto van de schatting. Verantwoord abonnementsomzet met de verwachte credit geparkeerd in de terugbetalingsverplichting, zoals in het voorbeeld hierboven.
- Stel de schatting van vorige maand bij. Vergelijk de reserve van vorige maand met de daadwerkelijk uitgegeven creditnota's; laat het verschil vrijvallen of vul het aan via de omzet van de huidige periode.
- Reconcileer het saldo van de verplichting. De terugbetalingsrekening mag alleen onopgeloste schattingen bevatten. Alles ouder dan je claimvenster (meestal 30 tot 60 dagen) zou al moeten zijn vrijgevallen — een groeiend verouderd saldo betekent dat bijstellingen worden overgeslagen.
Begin deze maand, niet volgend kwartaal. Haal het uptimerapport van vorige maand op, bereken de credits die je SLA-schema zegt dat je verschuldigd bent, en vergelijk dat getal met wat je boeken als omzetverlaging tonen. Als de boeken nul tonen — en voor de meeste SaaS-bedrijven in een vroege fase tonen ze nul — heb je je eerste bijstellingspost gevonden, en is je omzet elke maand zoals deze precies met dat bedrag te hoog voorgesteld.
