---
id: saas/inadimplencia-dunning
industria: SaaS e tecnologia
uso: específico
esforco: médio
grao: Tentativa de pagamento (evento), assinatura (fila) e cliente x mês (foto)
---

# Inadimplência e dunning da assinatura

Quanto MRR está preso em cobrança, quanto foi recuperado dentro do ciclo e quais assinaturas o time precisa cobrar hoje, sem contar tentativa como dívida.

## Resumo executivo

**Para quem:** Empresas de SaaS com cobrança recorrente que perdem clientes por falha de pagamento sem perceber.

**O que resolve**

- Churn involuntário separado do voluntário, com a taxa de recuperação de cada mês.
- Uma fila diária de assinaturas com dinheiro preso, com motivo e próxima ação.
- Inadimplência na data de referência que bate com o financeiro.

**Por que importa:** Falha de pagamento é o churn mais silencioso: o cartão é recusado, o billing tenta de novo, desiste e cancela, e ninguém fala com o cliente. O billing mostra só o status atual da fatura, não quanto tempo ela ficou presa nem se foi recuperada. Medir a recuperação por coorte e trabalhar uma fila diária devolve receita que já estava vendida.

**Perguntas de negócio que responde**

- Quanto MRR está preso em cobrança hoje?
- Qual a taxa de recuperação das falhas de pagamento de agosto?
- Quais assinaturas precisam de um cartão novo e quais só de um lembrete?
- Quem está inadimplente hoje e há quantos dias?
- Quais motivos de recusa mais terminam em cancelamento?
- Quanto do churn do mês foi involuntário?

**O que você precisa**

- Billing conectado na Nekt com faturas, tentativas de pagamento e assinaturas
- A política de cobrança: quantas tentativas, quando bloqueia o acesso e quando cancela
- Os códigos de recusa do gateway mapeados para categorias com ação

**O que você recebe**

- Uma tabela de eventos de falha e recuperação, uma linha por tentativa
- Taxa de recuperação mensal por coorte, com a maturidade de cada mês
- Fila diária de cobrança por assinatura, priorizada
- Um agente de IA que responde quem deve, quanto e desde quando

## Detalhado

### O problema

Cada tentativa de cartão recusada vira uma linha, e a mesma fatura pode ter várias antes de ser paga. Quem conta linhas multiplica a inadimplência; quem olha só o status atual não vê a fatura que falhou e foi paga dias depois, nem a que foi anulada no cancelamento. O resultado é churn involuntário misturado com voluntário e um CS que descobre a falha quando o cliente já saiu.

### Regras de negócio

1. **Tentativa é evento, dívida é a fatura.** Guarde as tentativas numa tabela de eventos, uma linha por tentativa, com data, motivo e gateway. Inadimplência, recuperação e fila contam no grão da fatura ou da assinatura. Retentativa automática, segunda via e reemissão são a mesma dívida. (Evite: Contar linhas da tabela de recusas como dívidas.)
2. **Recuperada é quem paga dentro de um ciclo da primeira falha.** A coorte do mês são as assinaturas com pelo menos uma falha no mês, ancoradas na primeira falha do mês. Recuperada é a que teve um pagamento com sucesso dentro de um ciclo de cobrança a partir dela: cerca de 30 dias no mensal, 90 no trimestral, um ano no anual. Todas as periodicidades entram, cada uma com a sua janela. Numa base real, a recuperação dos meses fechados ficava perto de metade. (Evite: Chamar de recuperada só a fatura paga na mesma semana, ou olhar o status de hoje.)
3. **Mês recente ainda está maturando.** Nos meses recentes, a janela de um ciclo ainda está aberta. Marque o mês como maturando até a janela fechar (no mensal, fim do mês mais 31 dias) e nunca leia a taxa baixa de um mês aberto como piora. Uma leitura semanal com janela curta é outro indicador e não se compara com a mensal. (Evite: Comparar o mês corrente com meses fechados.)
4. **O motivo da recusa decide a ação.** Normalize os códigos de recusa de cada gateway numa tabela única, com categoria e se vale tentar de novo. Número, CVC ou validade inválidos (incorrect_number, incorrect_cvc, invalid_expiry_month, invalid_expiry_year no Stripe) pedem cartão novo; recusa genérica do emissor ou saldo insuficiente pedem nova tentativa ou lembrete. Códigos que chegam com e sem zero à esquerda são o mesmo. Código fora da tabela aparece como não mapeado, nunca como outro, e alguém revisa toda semana. (Evite: Tratar toda recusa igual, ou agrupar o desconhecido em outros.)
5. **A fila é de quem ninguém está cobrando.** Entram as assinaturas vivas com fatura em aberto vencida e sem nova tentativa agendada pelo billing (next_payment_attempt vazio no Stripe), e as canceladas pelo billing nos últimos 30 dias cuja última tentativa falhou e nada foi pago depois. Enquanto o billing ainda está tentando, ele mesmo manda o aviso: não duplique o contato. A fila é uma foto, então confira a fatura ao vivo antes de cobrar. (Evite: Mandar a lista inteira de faturas em aberto para o time.)
6. **Prioridade por recência e motivo.** Uma régua simples funciona: até 14 dias da falha, recuperar agora; cartão inválido, pedir cartão novo; até 60 dias, reenviar a cobrança com o link da fatura; depois disso, perda provável. Conte os dias pelo vencimento da fatura em aberto mais antiga, não pelo último pagamento, que inclui o ciclo já pago. Ordene por MRR dentro de cada prioridade. (Evite: Ordenar a fila por data de criação da fatura.)
7. **Inadimplência oficial é a foto na data de referência.** Inadimplente é quem tem cobrança não cancelada vencida e não paga na data de referência: fim do mês nos meses fechados, hoje no mês corrente. Vencida hoje ainda não conta. Não há carência: um dia de atraso já conta, e a gravidade vem da faixa de dias. Ter atrasado em algum momento do mês é outra métrica, só histórica. Inadimplente não é inativo: o cliente segue na base até o cancelamento. (Evite: Marcar como inadimplente quem atrasou em algum dia do mês e já pagou.)
8. **Past_due fica no MRR, marcado.** Assinatura past_due continua no MRR marcada como em cobrança até virar canceled ou unpaid. Tirar e devolver quando é paga cria churn e reativação que não aconteceram. Se a empresa decide tirar depois de uma carência (por exemplo, 7 dias), a regra é escrita e igual em todos os meses. (Evite: Tirar past_due do MRR e devolver no mês seguinte.)
9. **Churn involuntário só depois da janela.** Cancelamento feito pelo billing, ou pelo time por política de inadimplência, depois de falhas sem pagamento é churn involuntário. Declare o churn só depois da janela de recuperação, com o valor do MRR antes da falha. Uma política comum é desligar quem tem dois ou mais títulos vencidos, com o mais antigo há mais de 60 dias. (Evite: Contar como churn no dia em que o cartão é recusado.)
10. **Bloqueio de acesso precisa de histórico.** Billing e produto guardam só se o cliente está bloqueado agora. Grave os eventos de bloqueio e desbloqueio, por webhook ou foto diária, para saber quanto tempo cada cliente ficou bloqueado e se pagou depois. Bloquear após um prazo é decisão operacional, não automática: não deduza bloqueio dos dias de atraso. (Evite: Supor que todo cliente com mais de 30 dias de atraso está bloqueado.)

### Fila de cobrança: prioridade e ação

Dias contados a partir do vencimento da fatura em aberto mais antiga da assinatura.

- **falha há até 14 dias** → P1, recuperar agora (`lembrete com o link da fatura`)
- **número, CVC ou validade inválidos** → P2, pedir cartão novo (`incorrect_number, incorrect_cvc, invalid_expiry_*`)
- **falha entre 15 e 60 dias** → P2, reenviar cobrança
- **mais de 60 dias sem pagamento** → P3, perda provável
- **cancelada pelo billing há até 30 dias, sem pagamento depois** → Janela de recuperação
- **billing ainda tentando** → Fora da fila (`next_payment_attempt preenchido`)

### Definições

| Métrica | Definição |
|---|---|
| Coorte de falha do mês | assinaturas com pelo menos uma tentativa de pagamento recusada no mês, ancoradas na primeira falha do mês |
| Taxa de recuperação | assinaturas da coorte com pagamento bem-sucedido dentro de um ciclo da primeira falha / assinaturas da coorte |
| MRR em cobrança | MRR das assinaturas vigentes com fatura em aberto vencida, na data de referência |
| Inadimplente na data | cliente com qualquer cobrança não cancelada vencida e não paga na data de referência, sem carência |
| Dias de atraso | data de referência menos o vencimento da fatura em aberto mais antiga |
| Churn involuntário | MRR do mês anterior das assinaturas canceladas depois de falha de pagamento sem pagamento posterior, declarado após a janela de recuperação |
| Aprovação na primeira tentativa | faturas de cobrança automática pagas na primeira tentativa / faturas de cobrança automática do mês |

### Armadilhas

- **Recusas que multiplicaram a dívida.** Um painel contava as linhas da tabela de recusas, e a mesma venda aparecia uma vez por retentativa. A inadimplência parecia várias vezes maior que a real. Como evitar: Conte faturas e assinaturas; tentativas só como eventos.
- **Mês aberto lido como queda.** A recuperação do mês corrente aparecia bem abaixo da média e virou alarme, mas a janela de um ciclo daquele mês ainda estava aberta. Como evitar: Grave a maturidade na linha e compare só meses fechados.
- **A conta sumiu junto com a dívida.** A visão de clientes só mostrava contas com MRR. A assinatura cancelada pelo billing por falta de pagamento saía da lista justamente na janela em que ainda dava para recuperar. Como evitar: Mantenha na fila as canceladas pelo billing nos últimos 30 dias.
- **Fatura anulada, cliente recuperável.** No cancelamento, o billing anulou a fatura em aberto. O valor em aberto ficou zero, o lembrete não fazia sentido, e o caso foi descartado como sem dívida. Como evitar: Valor em aberto zero é válido nesse caso: aborde com reativação, não com lembrete.
- **Status atual usado como foto.** Uma coluna de atraso em algum momento do mês era usada como status atual e marcava como inadimplente quem já tinha pago. Como evitar: Use a foto na data de referência e rotule a outra como histórica.
- **Taxa recalculada sobre carga incompleta.** A taxa mensal rodava num horário fixo e às vezes lia a versão de ontem da tabela de eventos, ou recalculava em cima de uma carga que tinha falhado. Como evitar: Dispare depois da carga, por evento, e grave na linha a falha mais recente que a fonte tinha.

Validado em dados reais: Na conta de Stripe da própria Nekt, as faturas que tiveram alguma recusa somam cerca de três tentativas recusadas cada, então contar tentativas triplica a inadimplência. E mais de 8 em cada 10 dessas faturas acabaram pagas depois, o que é recuperação, não perda.

### Teste de aceitação

- [ ] Cada assinatura aparece no máximo uma vez na coorte de falha de cada mês.
- [ ] Recuperadas + não recuperadas = coorte, e nenhum mês com janela aberta aparece como fechado.
- [ ] O valor em aberto da fila bate com a soma das faturas abertas no billing para as mesmas assinaturas (diferença abaixo de 1%).
- [ ] Nenhuma assinatura com nova tentativa agendada pelo billing está na fila.
- [ ] A inadimplência de um mês fechado não muda ao rodar o pipeline de novo.

### Context document

```text
Inadimplência e dunning
- Tentativa de pagamento é evento. Inadimplência, recuperação e fila contam por fatura ou assinatura, nunca por tentativa.
- Coorte de falha do mês = assinaturas com pelo menos uma recusa no mês, pela primeira falha do mês.
- Recuperada = pagamento com sucesso em até um ciclo da primeira falha: 30 dias mensal, 90 trimestral, 1 ano anual.
- Mês com janela aberta está maturando. Não compare com meses fechados.
- Inadimplente = cobrança não cancelada vencida e não paga na data de referência (fim do mês fechado ou hoje). Vence hoje não conta. Sem carência.
- Inadimplente não é inativo. Past_due segue no MRR marcado como em cobrança.
- Churn involuntário só depois da janela de recuperação, com o MRR de antes da falha.
- Fila de cobrança: só assinaturas sem nova tentativa agendada pelo billing, ou canceladas pelo billing há até 30 dias sem pagamento depois.
- Prioridade: P1 até 14 dias; P2 cartão inválido ou 15 a 60 dias; P3 mais de 60 dias.
- Código de recusa fora da tabela aparece como não mapeado.
Exceções por cliente:
- <cliente>: carência de <dias> dias antes de tirar past_due do MRR.
- <cliente>: política de desligamento com <n> títulos vencidos e o mais antigo há <dias> dias.
```

### Variações

- **Boleto e Pix:** Sem retentativa automática, a régua é de lembretes antes e depois do vencimento, e uma fila preventiva lista quem vence nos próximos 7 dias.
- **Cobrança no ERP:** Quando o título vive no ERP, use faixas de atraso e a marca de negativação, reduzindo a uma linha por nota e CNPJ antes de cruzar.
- **Previsão de churn involuntário:** A política de inadimplência vira a fila de aviso, e quem não está em nenhuma regra recebe uma probabilidade de churn calibrada.