Salta al contenuto principale

Il tuo SLA di uptime SaaS non è solo una promessa legale: perché i crediti per disservizio riducono i ricavi secondo l'ASC 606

Pubblicato 12 minuti di letturaMike ThriftMike Thrift
Il tuo SLA di uptime SaaS non è solo una promessa legale: perché i crediti per disservizio riducono i ricavi secondo l'ASC 606
In questa pagina

La tua status page è rimasta rossa per quattro ore martedì scorso. Entro venerdì avevi emesso crediti di servizio a ogni cliente colpito — 10 percento della tariffa mensile qui, 25 percento là — e il tuo contabile li ha registrati come fanno la maggior parte delle piccole aziende SaaS: come costo di assistenza, o come concessione commerciale, da qualche parte sotto la linea dei ricavi. Il tuo fatturato del mese è ora sopravvalutato, il tuo net revenue retention è sbagliato, e se un finanziatore o un acquirente mai aprisse i tuoi libri contabili, la prima domanda sarebbe quella a cui non sai rispondere: quanto dei ricavi che hai dichiarato avevi effettivamente il diritto di trattenere?

Questo non è un caso limite. Un disservizio medio richiede ora 196 minuti per essere risolto, e le piccole e medie imprese stimano il costo di un'ora di inattività intorno agli $8.000 — prima ancora che venga emesso un singolo credito. Ogni credito che concedi dopo un disservizio è una riduzione del prezzo che il tuo cliente ha accettato di pagare, e secondo l'ASC 606 questo lo rende corrispettivo variabile: un importo che riduce i tuoi ricavi, non un costo che si colloca sotto di essi. Questo articolo spiega a cosa ti impegna finanziariamente il tuo SLA, come lo standard vuole che tu lo registri, e cosa correggere alla tua prossima chiusura di fine mese.

Cosa promette davvero il tuo SLA — in dollari, non in "nove"​

La maggior parte dei contratti SaaS indica l'uptime in "nove": 99,9 percento (circa 43 minuti di inattività al mese), 99,95 percento, 99,99 percento (circa 4 minuti). Il numero che conta per i tuoi libri contabili non è quello dei nove ma il programma di crediti ad esso collegato. Un tipico SLA enterprise recita più o meno così: un uptime inferiore al 99,9 percento dà diritto al cliente a un credito di servizio del 10 percento; inferiore al 99,0 percento, 25 percento; inferiore al 95,0 percento, un mese intero gratuito. Alcuni contratti prevedono escalation ulteriori, offrendo diritti di risoluzione se l'uptime manca l'obiettivo per diversi mesi consecutivi.

Tre caratteristiche di quel programma definiscono la contabilizzazione:

I crediti sono un adeguamento contrattuale del prezzo, non un gesto di buona volontà. Il cliente non paga il prezzo pieno e poi riceve un regalo. Il contratto dice che il prezzo per un mese negativo è un prezzo inferiore. Questa distinzione — riduzione di prezzo contro costo — è l'intera questione contabile, e il contratto la risolve prima ancora che il tuo contabile apra il libro mastro.

I crediti sono di solito limitati e su richiesta, non automatici. Molti SLA richiedono che il cliente richieda il credito entro 30 giorni, e limitano i crediti totali al 30-100 percento della tariffa di un mese. Ciò significa che la tua esposizione per un dato disservizio è limitata e stimabile: conosci il programma, sai quali clienti sono stati colpiti e conosci il tuo tasso storico di richieste.

La tempistica di cassa e quella dei ricavi divergono. Un credito emesso a febbraio per un disservizio di gennaio di solito compare come nota di credito su una fattura futura. L'effetto sulla cassa si manifesta quando la fattura viene pagata, ma l'effetto sui ricavi appartiene a gennaio — il periodo in cui non hai fornito ciò che avevi promesso. Registrare il credito nel mese in cui lo emetti, contro i ricavi di quel mese, falsa due periodi contemporaneamente.

Perché l'ASC 606 definisce un credito per disservizio come corrispettivo variabile​

L'idea centrale dell'ASC 606 è semplice: riconoscere i ricavi all'importo del corrispettivo che prevedi di avere il diritto di ricevere in cambio della fornitura di ciò che hai promesso. Il passo 3 del modello a cinque fasi — determinare il prezzo della transazione — è dove entra in gioco il tuo SLA. Il prezzo della transazione non è il prezzo di listino sul modulo d'ordine. È il prezzo di listino meno tutto ciò che potrebbe tornare indietro: rimborsi, sconti, riduzioni, bonus di performance — e crediti di servizio per uptime non rispettato.

La guida sui ricavi di PwC colloca i crediti SLA esattamente in questo insieme. Il corrispettivo variabile deve essere stimato alla stipula del contratto e aggiornato ogni periodo di rendicontazione, utilizzando uno di due metodi:

  • Valore atteso — la media ponderata per probabilità tra i possibili esiti. Si adatta bene a un portafoglio di clienti: se la storia dice che circa il 3 percento del fatturato mensile di solito ritorna come crediti SLA, il tuo credito atteso su $100.000 di fatturato mensile è $3.000.
  • Importo più probabile — il singolo esito più probabile. Si adatta a una situazione binaria: un grande cliente il cui contratto o attiva un credito di $20.000 questo mese o non attiva nulla.

Poi arriva il vincolo, la parte che i fondatori spesso trascurano. Puoi includere il corrispettivo variabile nel prezzo della transazione — cioè riconoscere il ricavo — solo nella misura in cui è probabile che non si verifichi una significativa inversione quando l'incertezza si risolve. In termini semplici: se c'è una possibilità concreta che dovrai restituire il credito, non contare quella porzione come ricavo ancora. Registrala invece come passività di rimborso, e adeguala quando l'uptime del mese è noto.

Nota cosa implica il vincolo per un'azienda SaaS con una storia significativa di disservizi. Se il tuo servizio ha mancato il suo SLA in quattro degli ultimi dodici mesi, "prevediamo di non dovere nulla" non è una stima difendibile. La tua stessa status page è il reperto A dell'auditor.

Le scritture contabili: un mese con un disservizio​

Supponiamo che un cliente paghi $10.000 al mese, e che il tuo SLA del 99,9 percento conceda un credito del 10 percento per qualsiasi mese in cui l'uptime scende sotto l'obiettivo. L'uptime di gennaio si attesta al 99,4 percento. Ecco il ciclo completo.

Alla fatturazione, l'importo fatturato è ricavo differito come al solito — cassa ricevuta (o credito registrato) per un servizio non ancora fornito:

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 USD

Esaminiamo cosa è successo. A fine mese, hai riconosciuto $9.500 di ricavi e messo da parte $500 in una passività di rimborso — la tua stima del credito che il disservizio di gennaio attiverà. Quando la nota di credito effettiva viene emessa a febbraio, addebita la passività, non i ricavi e non un conto di costo. I ricavi di gennaio erano corretti fin dall'inizio, e i ricavi di febbraio non sono toccati dal disservizio di gennaio.

Se la stima e l'effettivo differiscono, la differenza rettifica i ricavi nel periodo in cui l'incertezza si risolve. Stimati $500 ma emessi $1.000 perché due clienti hanno fatto richiesta invece di uno? I $500 extra riducono i ricavi quando ne vieni a conoscenza. Stimati $500 e nessuno ha fatto richiesta? Rilascia i $500 a ricavi. Il conto della passività è l'ammortizzatore; i ricavi non vengono mai riesposti per un adeguamento di routine.

Due dettagli da non sbagliare. Primo, la passività di rimborso è separata dal ricavo differito: il ricavo differito è per un servizio che non hai ancora fornito, mentre la passività di rimborso è per un servizio fornito che potresti dovere restituire. Compensarli insieme nasconde entrambe le storie. Secondo, se un credito si riferisce a un periodo futuro — un mese gratuito concesso come scusa piuttosto che un credito contrattuale per un fallimento passato — si tratta di un'analisi diversa, più vicina a una modifica del contratto o a un diritto materiale, che rettifica i ricavi futuri anziché passati.

I tre errori che i fondatori SaaS commettono con i crediti SLA​

Errore 1: registrare il credito come costo. Questo è l'errore più comune e il più dannoso. Registrare un credito per disservizio di $10.000 come addebito a "spese di assistenza clienti" o "concessioni commerciali" lascia i ricavi sopravvalutati di $10.000 e inventa $10.000 di costi che non si sono mai verificati. Il margine lordo, la crescita dei ricavi e ogni rapporto basato sui ricavi risultano tutti troppo alti. Secondo l'ASC 606, gli importi dovuti al cliente che non sono per un bene o servizio distinto ricevuto in cambio riducono il prezzo della transazione. Un credito per il tuo stesso disservizio non ti compra nulla di distinto — riduce i ricavi, punto e basta.

Errore 2: riconoscere i ricavi pieni ora e correggerli dopo. Alcune aziende registrano l'intero $10.000 come ricavo di gennaio, poi registrano il credito di $1.000 contro i ricavi di febbraio quando la nota di credito viene emessa. Entrambi i mesi sono ora sbagliati: gennaio troppo alto, febbraio troppo basso. Peggio, l'errore si accumula nelle tue metriche — il net revenue retention di gennaio sembra ottimo, quello di febbraio debole, e nessuno dei due riflette la realtà. Lo schema con passività di rimborso di cui sopra esiste proprio per mantenere onesto ogni periodo.

Errore 3: stimare zero perché il disservizio "non succederà di nuovo". Il vincolo si basa sulla probabilità, non sull'ottimismo. Se la tua infrastruttura ha avuto tre mesi che attivano lo SLA l'anno scorso, una stima di zero crediti attesi non è né prudente né aggressiva — è priva di fondamento. Gli auditor verificano questa stima contro la tua storia di incidenti, e gli acquirenti in due diligence faranno lo stesso. Una piccola riserva permanente, dimensionata sui tassi storici di richiesta e adeguata mensilmente, è sia più accurata sia molto più facile da difendere di uno zero fiducioso che la tua status page contraddice.

Cosa questo fa alle metriche che acquirenti e finanziatori leggono​

Mettere i crediti SLA sopra la linea dei ricavi invece che sotto cambia ogni numero su cui viene valutata un'azienda SaaS:

  • MRR e ARR dovrebbero essere al netto dei crediti attesi. Se il 2 percento del fatturato storicamente ritorna come crediti SLA, un ARR dichiarato di $1 milione è in realtà $980.000 di ricavi attesi. Riportare il numero lordo è come i fondatori finiscono per spiegare in due diligence un "problema di churn" che in realtà era sempre stato un problema di crediti.
  • Il net revenue retention assorbe i crediti come contrazione. Un cliente che ha pagato $120.000 l'anno scorso e $114.000 quest'anno dopo i crediti per disservizio ha mantenuto al 95 percento, non al 100 percento — anche se non ha mai ridotto un solo posto.
  • Il margine lordo sale quando correggi l'errore, paradossalmente. Spostare i crediti dalle spese di assistenza al controricavo riduce sia i ricavi sia il costo del venduto, e poiché il credito supera qualsiasi costo associato, la percentuale di margine migliora mentre i ricavi scendono. Aspettati la domanda, e tieni pronta la storia riesposta.

Se usi la contabilità in testo semplice, la correzione è strutturale più che procedurale: un conto dedicato Liabilities:Refund:SLA-Credits, una scrittura di fine mese che riconosce i ricavi da abbonamento al netto del credito atteso, e una scrittura di adeguamento quando le note di credito vengono emesse. La documentazione beancount sui modelli di riconoscimento dei ricavi illustra la forma generale della contabilizzazione dei ricavi differiti su cui questo si basa, e la storia di stato patrimoniale del conto di rimborso funge da doppia traccia di audit per la stima.

Una checklist di fine mese che richiede venti minuti​

  1. Estrai l'uptime per fascia di clienti. Il tuo monitoraggio lo calcola già; chiedi il numero mensile rispetto a ciascuna soglia SLA, non solo la media complessiva.
  2. Elenca i crediti attivati. Per ogni cliente sotto soglia, calcola il credito contrattuale dal programma — prima di verificare chi ha effettivamente fatto richiesta.
  3. Applica la tua storia del tasso di richiesta. Se storicamente circa il 60 percento dei crediti attivati viene richiesto, il tuo valore atteso è il 60 percento del totale attivato. Documenta il tasso e rivedilo trimestralmente.
  4. Registra i ricavi al netto della stima. Riconosci i ricavi da abbonamento con il credito atteso parcheggiato nella passività di rimborso, come nell'esempio sopra.
  5. Adegua la stima del mese scorso. Confronta la riserva del mese scorso con le note di credito effettivamente emesse; rilascia o integra la differenza attraverso i ricavi del periodo corrente.
  6. Riconcilia il saldo della passività. Il conto di rimborso dovrebbe contenere solo stime non risolte. Qualsiasi cosa più vecchia della tua finestra di richiesta (di solito 30-60 giorni) avrebbe già dovuto essere rilasciata — un saldo stantio in crescita significa che gli adeguamenti vengono saltati.

Inizia questo mese, non il prossimo trimestre. Estrai il rapporto di uptime del mese scorso, calcola i crediti che il tuo programma SLA dice che devi, e confronta quel numero con ciò che i tuoi libri contabili mostrano come riduzione dei ricavi. Se i libri mostrano zero — e per la maggior parte delle aziende SaaS in fase iniziale, mostrano zero — hai trovato la tua prima scrittura di adeguamento, e i tuoi ricavi sono stati sopravvalutati esattamente di quell'importo ogni mese simile.

Fonte: https://beancount.io/it/blog/2026/11/09/saas-uptime-sla-outage-credits-variable-consideration-asc-606-guide

Pubblicato: 9 novembre 2026