Sua página de status ficou vermelha por quatro horas na terça-feira passada. Na sexta-feira, você já havia emitido créditos de serviço para todos os clientes afetados — 10 por cento da mensalidade aqui, 25 por cento ali — e seu contador os registrou da forma como a maioria das pequenas empresas SaaS faz: como um custo de suporte, ou uma concessão de marketing, em algum lugar abaixo da linha da receita. Sua receita do mês agora está superestimada, sua retenção líquida de receita está errada e, se um credor ou comprador algum dia abrir seus livros, a primeira pergunta será aquela que você não consegue responder: quanto da receita que você reportou você de fato tinha direito de manter?
Isso não é um caso isolado. A indisponibilidade média agora leva 196 minutos para ser resolvida, e pequenas e médias empresas estimam o custo de uma hora de inatividade em cerca de $8.000 — antes de qualquer crédito ser emitido. Cada crédito que você concede após uma indisponibilidade é uma redução do preço que seu cliente concordou em pagar, e sob o ASC 606 isso o torna contraprestação variável: um valor que reduz sua receita, não uma despesa que fica abaixo dela. Este artigo explica o que seu SLA o compromete financeiramente, como a norma quer que você o registre e o que corrigir no seu próximo fechamento mensal.
O que seu SLA realmente promete — em dólares, não em noves
A maioria dos contratos SaaS cita o uptime em "noves": 99,9 por cento (cerca de 43 minutos de inatividade por mês), 99,95 por cento, 99,99 por cento (cerca de 4 minutos). O número que importa para seus livros não são os noves, mas o cronograma de créditos atrelado a eles. Um SLA empresarial típico diz algo assim: uptime abaixo de 99,9 por cento rende ao cliente um crédito de serviço de 10 por cento; abaixo de 99,0 por cento, 25 por cento; abaixo de 95,0 por cento, um mês inteiro grátis. Alguns contratos escalam ainda mais, oferecendo direitos de rescisão se o uptime ficar abaixo da meta por vários meses consecutivos.
Três características desse cronograma moldam a contabilização:
Créditos são um ajuste contratual de preço, não um gesto de boa vontade. O cliente não paga o preço cheio e depois recebe um presente. O contrato diz que o preço de um mês ruim é um preço menor. Essa distinção — redução de preço versus despesa — é toda a questão contábil, e o contrato a responde antes mesmo que seu contador abra o razão.
Créditos geralmente têm limite e precisam ser solicitados, não são automáticos. Muitos SLAs exigem que o cliente solicite o crédito em até 30 dias e limitam o total de créditos a 30 a 100 por cento da mensalidade de um mês. Isso significa que sua exposição em qualquer indisponibilidade é limitada e estimável: você conhece o cronograma, sabe quais clientes foram afetados e conhece sua taxa histórica de solicitações.
O momento do caixa e o momento da receita divergem. Um crédito emitido em fevereiro por uma indisponibilidade de janeiro geralmente aparece como uma nota de crédito contra uma fatura futura. O efeito no caixa ocorre quando a fatura é paga, mas o efeito na receita pertence a janeiro — o período em que você deixou de entregar o que prometeu. Registrar o crédito no mês em que você o emite, contra a receita desse mês, distorce dois períodos ao mesmo tempo.
Por que o ASC 606 classifica um crédito por indisponibilidade como contraprestação variável
A ideia central do ASC 606 é simples: reconheça a receita pelo valor da contraprestação que você espera ter direito a receber em troca da entrega do que prometeu. A Etapa 3 do modelo de cinco etapas — determinação do preço da transação — é onde seu SLA entra em cena. O preço da transação não é o preço de tabela no formulário de pedido. É o preço de tabela menos tudo o que pode voltar: reembolsos, descontos, abatimentos, bônus de desempenho — e créditos de serviço por uptime não cumprido.
O guia de receita da PwC coloca os créditos de SLA diretamente nessa categoria. A contraprestação variável deve ser estimada na inception do contrato e atualizada a cada período de reporte, usando um de dois métodos:
- Valor esperado — a média ponderada por probabilidade entre os resultados possíveis. Isso se ajusta bem a uma carteira de clientes: se o histórico diz que 3 por cento do faturamento mensal normalmente retorna como créditos de SLA, seu crédito esperado sobre $100.000 de faturamento mensal é $3.000.
- Valor mais provável — o único resultado mais provável. Isso se ajusta a uma situação binária: um grande cliente cujo contrato ou aciona um crédito de $20.000 neste mês ou não aciona nada.
Em seguida vem a restrição, a parte que os fundadores mais frequentemente pulam. Você pode incluir a contraprestação variável no preço da transação — ou seja, reconhecer a receita — apenas na medida em que for provável que não ocorra uma reversão significativa quando a incerteza for resolvida. Em termos simples: se há uma chance real de que você venha a dever o crédito de volta, não conte essa parcela como receita ainda. Registre-a como um passivo de reembolso e ajuste-a quando o uptime do mês for conhecido.
Observe o que a restrição implica para uma empresa SaaS com um histórico significativo de indisponibilidade. Se seu serviço não cumpriu o SLA em quatro dos últimos doze meses, "esperamos não dever nada" não é uma estimativa defensável. Sua própria página de status é a Prova A do auditor.
Os lançamentos contábeis: um mês com indisponibilidade
Suponha que um cliente pague $10.000 por mês, e seu SLA de 99,9 por cento conceda um crédito de 10 por cento para qualquer mês em que o uptime fique abaixo da meta. O uptime de janeiro ficou em 99,4 por cento. Aqui está o ciclo completo.
No faturamento, o valor faturado é receita diferida, como de costume — caixa recebido (ou conta a receber registrada) por serviço ainda não entregue:
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 USDPercorra o que aconteceu. No fechamento do mês, você reconheceu $9.500 de receita e alocou $500 em um passivo de reembolso — sua estimativa do crédito que a indisponibilidade de janeiro acionará. Quando a nota de crédito real for emitida em fevereiro, ela debita o passivo, não a receita e não uma conta de despesa. A receita de janeiro estava correta desde o início, e a receita de fevereiro não é afetada pela indisponibilidade de janeiro.
Se a estimativa e o valor real diferirem, a diferença ajusta a receita no período em que a incerteza é resolvida. Estimou $500 mas emitiu $1.000 porque dois clientes solicitaram em vez de um? Os $500 adicionais reduzem a receita quando você toma conhecimento. Estimou $500 e ninguém solicitou? Libere os $500 para a receita. A conta de passivo é o amortecedor; a receita nunca é reapresentada por um ajuste de rotina.
Dois detalhes que vale a pena acertar. Primeiro, o passivo de reembolso é separado da receita diferida: a receita diferida é para serviço que você ainda não entregou, enquanto o passivo de reembolso é para serviço entregue que você pode ter que devolver. Compensá-los juntos esconde ambas as histórias. Segundo, se um crédito se relaciona a um período futuro — um mês grátis concedido como desculpa em vez de um crédito contratual por uma falha passada — essa é uma análise diferente, mais próxima de uma modificação de contrato ou de um direito material, e ajusta a receita futura em vez da passada.
Os três erros que fundadores SaaS cometem com créditos de SLA
Erro 1: Registrar o crédito como despesa. Este é o erro mais comum e o mais prejudicial. Registrar um crédito por indisponibilidade de $10.000 como débito em "despesa de suporte ao cliente" ou "concessões de marketing" deixa a receita superestimada em $10.000 e inventa $10.000 de despesa que nunca ocorreu. Margem bruta, crescimento de receita e todo índice baseado em receita ficam altos demais. Sob o ASC 606, valores pagáveis ao cliente que não sejam por um bem ou serviço distinto recebido em troca reduzem o preço da transação. Um crédito pela sua própria indisponibilidade não compra nada distinto — reduz a receita, ponto final.
Erro 2: Reconhecer a receita cheia agora e corrigir depois. Algumas empresas registram os $10.000 completos como receita de janeiro e depois registram o crédito de $1.000 contra a receita de fevereiro quando a nota de crédito é emitida. Ambos os meses agora estão errados: janeiro alto demais, fevereiro baixo demais. Pior, o erro se acumula em suas métricas — a retenção líquida de receita de janeiro parece ótima, a de fevereiro parece fraca, e nenhuma reflete a realidade. O padrão de passivo de reembolso acima existe justamente para manter cada período honesto.
Erro 3: Estimar zero porque a indisponibilidade "não vai acontecer de novo". A restrição se baseia em probabilidade, não em otimismo. Se sua infraestrutura teve três meses acionando SLA no ano passado, uma estimativa de zero créditos esperados não é conservadora nem agressiva — é sem fundamento. Auditores testam essa estimativa contra seu histórico de incidentes, e compradores em due diligence farão o mesmo. Uma pequena reserva permanente, dimensionada a partir das taxas de solicitação dos últimos meses e ajustada mensalmente, é tanto mais precisa quanto muito mais fácil de defender do que um zero confiante que sua página de status contradiz.
O que isso faz com as métricas que compradores e credores leem
Colocar os créditos de SLA acima da linha da receita versus abaixo dela muda cada número pelo qual uma empresa SaaS é avaliada:
- MRR e ARR devem ser líquidos de créditos esperados. Se 2 por cento do faturamento historicamente retorna como créditos de SLA, um ARR divulgado de $1 milhão é na verdade $980.000 de receita esperada. Reportar o número bruto é como fundadores acabam explicando um "problema de churn" em due diligence que na verdade era um problema de crédito o tempo todo.
- Retenção líquida de receita absorve créditos como contração. Um cliente que pagou $120.000 no ano passado e $114.000 este ano após créditos por indisponibilidade reteve a 95 por cento, não 100 por cento — mesmo que nunca tenha reduzido uma licença.
- Margem bruta sobe quando você corrige o erro, paradoxalmente. Mover créditos de despesa de suporte para contrarreceita reduz tanto a receita quanto o custo da receita, e como o crédito excede qualquer custo associado, o percentual de margem melhora enquanto a receita cai. Espere a pergunta e tenha o histórico reapresentado pronto.
Se você usa contabilidade em texto puro, a correção é estrutural em vez de procedimental: uma conta dedicada Liabilities:Refund:SLA-Credits, um lançamento de fechamento mensal que reconhece a receita de assinatura líquida do crédito esperado e um lançamento de ajuste quando as notas de crédito são emitidas. A documentação do beancount sobre padrões de reconhecimento de receita cobre a forma geral da contabilização de receita diferida na qual isso se baseia, e o histórico de balanço da conta de reembolso serve também como sua trilha de auditoria para a estimativa.
Uma lista de verificação de fechamento mensal que leva vinte minutos
- Extraia o uptime por faixa de cliente. Seu monitoramento já calcula isso; solicite o número mensal contra cada limite de SLA, não apenas a média geral.
- Liste os créditos acionados. Para cada cliente abaixo do limite, calcule o crédito contratual a partir do cronograma — antes de verificar quem realmente solicitou.
- Aplique seu histórico de taxa de solicitação. Se aproximadamente 60 por cento dos créditos acionados historicamente são solicitados, seu valor esperado é 60 por cento do total acionado. Documente a taxa e revise-a trimestralmente.
- Registre a receita líquida da estimativa. Reconheça a receita de assinatura com o crédito esperado alocado no passivo de reembolso, como no exemplo acima.
- Ajuste a estimativa do mês passado. Compare a reserva do mês passado com as notas de crédito efetivamente emitidas; libere ou complemente a diferença por meio da receita do período corrente.
- Concilie o saldo do passivo. A conta de reembolso deve conter apenas estimativas não resolvidas. Qualquer coisa mais antiga que sua janela de solicitação (geralmente 30 a 60 dias) já deveria ter sido liberada — um saldo obsoleto crescente significa que os ajustes estão sendo pulados.
Comece este mês, não no próximo trimestre. Extraia o relatório de uptime do mês passado, calcule os créditos que seu cronograma de SLA diz que você deve e compare esse número com o que seus livros mostram como redução de receita. Se os livros mostram zero — e, para a maioria das empresas SaaS em estágio inicial, eles mostram zero — você encontrou seu primeiro lançamento de ajuste, e sua receita foi superestimada exatamente nesse valor a cada mês como esse.
