Nordlet

← Blogue

Contabilidade em SaaS Explicada: Reconhecimento de Proveitos, Diferimento, MRR

Uma explicação clara do que torna a contabilidade de subscrição diferente, as regras que a regem, as métricas que acompanham as demonstrações financeiras e o que um razão (ledger) precisa de fazer para manter o ritmo.

Nordlet Team · · 12 min de leitura

A contabilidade em SaaS é a contabilidade de uma empresa que vende o acesso a software ao longo do tempo. O único fator que a distingue da venda de um produto tradicional é a temporalidade: o cliente paga habitualmente antes de o serviço ser prestado, muitas vezes com um ano de antecedência, e os proveitos só podem ser registados à medida que os meses de serviço decorrem. Tudo o que é específico da contabilidade em SaaS decorre desse desfasamento entre a faturação e a prestação do serviço.

Este artigo explica o que o termo abrange, as regras que o governam ao abrigo da IFRS 15 e da ASC 606, o conjunto de indicadores que uma empresa de subscrição tem de manter em ordem e o que um sistema de contabilidade precisa de fazer para evitar que tudo isto seja gerido manualmente numa folha de cálculo.

O que significa a contabilidade em SaaS

Numa loja, a venda, a entrega e o reconhecimento dos proveitos ocorrem no mesmo momento. Numa empresa de subscrição, estes eventos desfazem-se:

  • O cliente assina um contrato (uma encomenda ou reserva / booking).
  • Emite uma fatura, porventura cobrando doze meses de uma só vez (uma faturação / billing).
  • O cliente efetua o pagamento (caixa / cash).
  • O serviço é prestado dia a dia, e apenas a parte entregue constitui proveito (revenue).
  • A parte faturada mas ainda não entregue figura no balanço como proveitos diferidos (deferred revenue), constituindo um passivo.

Uma empresa que reconheça a fatura anual completa como proveito logo em janeiro reporta onze meses de trabalho que ainda não realizou. Se o cliente cancelar o serviço em março e for reembolsado, esses proveitos nunca foram reais. A contabilidade de acréscimo existe exatamente para evitar esta situação, sendo o modelo de negócio SaaS aquele em que esta correção é mais crítica, dado que quase todas as vendas são pagas antes de serem entregues.

Por conseguinte, a "contabilidade em SaaS" não constitui um conjunto de livros separado. Trata-se da contabilidade de dupla partida comum, aplicada a contratos executados ao longo do tempo, complementada por uma camada de métricas operacionais que as demonstrações financeiras não evidenciam.

Porque é que o dinheiro em caixa não é o mesmo que proveito

Considere um cliente que paga 2.400 € a 1 de janeiro por um plano de doze meses. O saldo bancário aumenta em 2.400 € (acrescido de IVA) no primeiro dia. A demonstração de resultados referente a janeiro regista 200 € de proveitos, uma vez que foi prestada uma décima segunda parte do serviço. Os restantes 2.200 € representam um passivo: deve ao cliente onze meses de serviço.

Movimento em janeiro Montante
Caixa recebido (líquido de IVA) 2.400
Proveitos reconhecidos 200
Proveitos diferidos a 31 de janeiro 2.200

Disto resultam três consequências, todas geradoras de confusão para quem transita para o modelo SaaS a partir de outros setores de atividade:

  1. Uma empresa SaaS em rápido crescimento aparenta ter muita liquidez e poucos lucros. Os pagamentos antecipados anuais entram de imediato, enquanto o reconhecimento dos proveitos se atrasa até um ano.
  2. Uma empresa SaaS em retração apresenta o comportamento oposto. Os proveitos derivados de adiantamentos anteriores continuam a ser reconhecidos enquanto a entrada de novos fundos abranda.
  3. O saldo de proveitos diferidos constitui uma previsão. Trata-se de proveitos que serão reportados nos meses seguintes sem necessidade de realizar novas vendas, desde que a prestação do serviço se mantenha.

A entrada do glossário sobre proveitos diferidos, proveitos não ganhos e rendimentos diferidos aborda este passivo com maior profundidade. O artigo complementar sobre proveitos diferidos em SaaS com lançamentos contabilísticos ilustra estes lançamentos caso a caso.

Os cinco números e as suas diferenças

Indicador O que mede Onde se encontra
Reservas (Bookings) Valor total do contrato assinado num período Relatório operacional, não no razão
Faturação (Billings) Montantes faturados num período Razão de clientes (contas a receber)
Proveitos (Revenue) Valor do serviço prestado no período Demonstração de resultados
Proveitos diferidos (Deferred revenue) Faturado mas ainda não entregue Balanço, passivo
MRR / ARR Valor mensal (ou anual) normalizado das subscrições ativas Relatório operacional, não no razão

A regra que articula os primeiros quatro indicadores é simples: faturação − proveitos reconhecidos = variação dos proveitos diferidos. Se os seus relatórios não cumprirem esta identidade, um dos três valores está incorreto.

O MRR e o ARR não constituem quaisquer medidas de contabilidade. O MRR contabiliza exclusivamente o valor do contrato recorrente normalizado a uma base mensal; assim, um plano anual de 2.400 € contribui com 200 € de MRR, ao passo que as taxas de configuração únicas não têm qualquer contributo. Os proveitos, pelo contrário, incluem a taxa de configuração no momento em que são obtidos e obedecem às regras de reconhecimento abaixo descritas. Estes dois indicadores respondem a questões distintas e nunca devem ser reconciliados entre si, mas sim explicados em separado.

As regras: IFRS 15 e ASC 606

Ambas as normas utilizam o mesmo modelo de cinco passos. No contexto de um contrato SaaS, os passos resolvem-se da seguinte forma:

Passo A regra Aplicação típica em SaaS
1. Identificar o contrato Um acordo executório com substância comercial A encomenda assinada ou os termos online aceites
2. Identificar as obrigações de desempenho Promessas autónomas feitas ao cliente Acesso ao software; integração (onboarding) ou implementação, se distinta; suporte premium, se comercializado em separado
3. Determinar o preço da transação O montante a que espera ter direito, incluindo consideração variável A taxa de subscrição, deduzida de eventuais reembolsos ou créditos esperados
4. Alocar o preço Pelas obrigações em proporção dos preços de venda independentes Um desconto de pacote (bundle) é distribuído pelo software e pela integração, não ficando concentrado numa única linha
5. Reconhecer os proveitos Quando ou à medida que cada obrigação é satisfeita Acesso ao software: ao longo do tempo, de forma linear; integração: num momento específico ou por marco (milestone)

Três aspetos determinam a maior parte do trabalho prático.

O acesso ao software é satisfeito ao longo do tempo. O cliente consome o serviço de forma contínua, pelo que os proveitos são reconhecidos de maneira uniforme ao longo do período de serviço. O método da linha reta ponderada pelos dias é o padrão habitual.

A integração pode ou não ser distinta. Se o cliente puder retirar benefício do software sem recorrer ao serviço de implementação, e se esse serviço for comercializado em separado, constitui uma obrigação autónoma reconhecida no momento da entrega. Caso o software seja inutilizável sem essa integração, ambos formam uma única obrigação e o preço total é reconhecido ao longo do prazo da subscrição. Trata-se de um julgamento exercido pela empresa e não pelo software.

A consideração variável é excluída até ser altamente provável. Se prever que 5% dos planos anuais sejam reembolsados, o preço da transação corresponde a 95% da fatura; os restantes 5% constituem um passivo por reembolso e não proveitos. Passam a constituir proveitos apenas quando o prazo para reembolso decorre sem que haja reclamações.

O artigo sobre o reconhecimento de proveitos em SaaS ao abrigo da IFRS 15 com lançamentos práticos no razão aplica cada passo a um exemplo numérico e demonstra os respetivos lançamentos contabilísticos.

Erros comuns

  • Reconhecer o valor da fatura. O erro mais frequente: os proveitos equivalem à faturação e os proveitos diferidos não existem no balanço. Isto sobreavalia os proveitos nos anos de crescimento e subavali-os posteriormente.
  • Deixar o desconto do pacote numa única linha. Um pacote de 3.000 € composto por software e integração, com um desconto aplicado exclusivamente à linha de integração, resulta num reconhecimento excessivo de proveitos no início. O desconto deve ser distribuído por ambas as obrigações.
  • Tratar os reembolsos como uma surpresa. As taxas de reembolso previsíveis constituem consideração variável. Registar o montante total e anular os reembolsos posteriormente sobreavalia os proveitos em todos os períodos.
  • Misturar o MRR nos proveitos. O MRR representa um ritmo de exploração (run-rate); os proveitos correspondem ao que foi efetivamente entregue. Um relatório de gestão que confunda um com o outro não resistirá a uma auditoria de diligência devida (due diligence).
  • Mapas em folhas de cálculo. Um plano de amortização de proveitos diferidos mantido manualmente desvia-se do razão no preciso momento em que um cliente efetua um upgrade, downgrade ou cancela o contrato a meio do período.
  • Encerrar o mês com diferimentos por liquidar. Se a libertação de rendimentos diferidos for efetuada através de um lançamento manual, corre-se o risco de fechar um mês com proveitos gerados mas não reconhecidos.

Boas práticas

  1. Atribuir o método de reconhecimento à linha da fatura e não a uma folha de cálculo. A linha que define o preço deve especificar igualmente o modo como os proveitos são obtidos: num momento específico, de forma linear entre duas datas, por marco ou por percentagem de conclusão.
  2. Manter os proveitos diferidos como um saldo derivado. O passivo deve corresponder à soma das tranches pendentes do plano, explicáveis linha a linha, e não a um valor introduzido manualmente no final do mês.
  3. Registar os preços de venda independentes. A alocação exige-os. Defina-os uma única vez por produto e associe-os ao item do catálogo.
  4. Estimar os reembolsos no momento da emissão. Registe a percentagem esperada como um passivo por reembolso e ajuste-a face às notas de crédito efetivas.
  5. Liberter os diferimentos como parte do fecho de contas. O mês não pode ser bloqueado sem que todas as tranches exigíveis nesse período tenham sido reconhecidas.
  6. Separar o IVA do reconhecimento de proveitos. O IVA é devido no momento da emissão da fatura ou da receção do adiantamento, e não quando o serviço é prestado. Os dois calendários devem ser independentes.
  7. Reportar o movimento global (roll-forward). Proveitos diferidos iniciais, acrescidos da faturação, deduzidos dos proveitos reconhecidos, equivalem aos proveitos diferidos finais. Produza este relatório mensalmente.
  8. Manter o MRR num relatório operacional. Calcule-o a partir das subscrições ativas e do seu valor normalizado. Não o deduza do razão, nem permita que alimente o razão.

Como a Nordlet automatiza o diferimento

O módulo de reconhecimento de proveitos da Nordlet implementa as regras anteriores sob a forma de propriedades associadas às linhas comuns de faturação, eliminando a necessidade de manter um razão auxiliar separado para reconciliação.

Método na linha. Cada linha de uma fatura de vendas aceita um objeto recognition, onde o parâmetro method pode assumir os valores point_in_time (predefinido, proveitos no momento da emissão), ratable com uma data de início (startDate) e de fim (endDate), milestone com uma lista de percentagens cuja soma atinja 100, ou percent_complete. No momento da emissão da fatura, o direito a receber (receivable) e o IVA são contabilizados na totalidade, sendo o valor líquido de uma linha diferida creditado em rendimentos diferidos em vez de proveitos.

Os planos são derivados e não digitados. Uma linha linear gera uma tranche por mês civil, ponderada pelos dias de serviço decorridos nesse mês. Cada tranche pode ser consultada através de sales/recognition-schedules/list com o estado pendente, reconhecido ou cancelado, permitindo justificar o saldo de proveitos diferidos ao cêntimo.

Três gatilhos, sem consultas periódicas (polling). O reconhecimento é efetuado quando um período é bloqueado (sendo primeiro reconhecido tudo o que for exigível até ao final do período, impedindo o fecho de um mês com proveitos por libertar), quando é emitido um auto de entrega face a uma linha de marco e quando uma tranche agendada se torna exigível. Um ponto de terminação de simulação (dry-run) permite visualizar o impacto de um processamento antes da sua efetivação.

Alocação e reembolsos. A definição de um preço de venda independente em cada linha distribui o total da fatura proporcionalmente por todas as linhas. A definição de uma estimativa de reembolso numa linha credita essa proporção a um passivo por reembolso no momento da emissão; as notas de crédito emitidas posteriormente abatem esse passivo antes de afetarem os proveitos.

Subscrições. Um acordo com um período de faturação mensal, trimestral ou anual gera a respetiva fatura previsível para cada período com as linhas lineares já configuradas, enquanto um processo de faturação (billing run) percorre todos os acordos ativos para identificar os períodos que se tornaram exigíveis. Os períodos finais curtos são calculados em prorrogação proporcional por dias.

Os limites encontram-se documentados com a mesma transparência que as funcionalidades: os planos são fixados em euros à taxa de câmbio da data de emissão, o método de alocação residual não se encontra implementado e os componentes de financiamento significativos estão fora do âmbito. O software dispõe de capacidade para aplicar o tratamento decorrente da IFRS 15 e da ASC 606, cabendo contudo à empresa decidir qual o enquadramento aplicável a cada contrato.

FAQ

O que significa a contabilidade em SaaS?

Significa aplicar a contabilidade de acréscimo a uma empresa que comercializa acesso a software ao longo do tempo. A principal característica reside no facto de os clientes serem faturados, e frequentemente pagarem, antes de o serviço ser prestado; por conseguinte, os proveitos são reconhecidos à medida que o período de serviço decorre, enquanto a parte por entregar é registada como proveitos diferidos.

Quais são as regras da contabilidade em SaaS?

As normas aplicáveis são a IFRS 15 (utilizada na União Europeia e na maior parte do mundo) e a ASC 606 (Estados Unidos). Ambas utilizam o mesmo modelo de cinco passos: identificar o contrato, identificar as obrigações de desempenho, determinar o preço da transação, alocá-lo pelas obrigações com base nos preços de venda independentes e reconhecer os proveitos quando ou à medida que cada obrigação é satisfeita. No caso do acesso a software, isto traduz-se no reconhecimento dos proveitos ao longo do período de subscrição.

Os proveitos diferidos são o equivalente a proveitos não ganhos?

Sim. Proveitos diferidos (deferred revenue), proveitos não ganhos (unearned revenue), rendimentos diferidos e passivos de contrato (contract liability) são designações alternativas para o mesmo saldo: montantes faturados ou recebidos relativos a serviços ainda não prestados. A IFRS 15 utiliza a designação "passivo de contrato"; as contas estatutárias na UE utilizam habitualmente "rendimentos diferidos".

O MRR é um indicador contabilístico?

Não. O MRR é uma métrica operacional que representa o valor mensal normalizado dos contratos recorrentes ativos. Não figura em nenhuma norma contabilística ou demonstração financeira. Os proveitos correspondem ao montante apresentado na demonstração de resultados, incluindo itens não recorrentes como as taxas de configuração no momento em que são obtidas.

As pequenas empresas SaaS precisam de seguir a IFRS 15?

As contas estatutárias de uma empresa regem-se pelas normas contabilísticas nacionais do respetivo país, que no caso da UE decorrem da Diretiva Contabilística e podem prever simplificações para entidades de pequena dimensão. Contudo, investidores, adquirentes e auditores esperam que os proveitos de subscrição sejam diferidos independentemente da dimensão, exigindo a maioria dos enquadramentos nacionais a aplicação da contabilidade de acréscimo em qualquer circunstância. O reconhecimento integral da fatura como proveito constitui um procedimento incorreto em todas elas.

Leitura complementar