Régua de cobrança no n8n: cobra os vencidos e calcula a PDD

TL;DR

• Montei um fluxo no n8n que lê o contas a receber de uma Google Sheet, dispara o e-mail de cobrança só nos títulos vencidos e consolida a PDD por faixa de atraso.
• O ganho não é só “mandar e-mail”: é parar de carregar a cobrança na cabeça e ainda ver onde mora o risco do recebível toda vez que você roda.
• Rodei com 6 títulos de teste: 5 cobranças disparadas, R$ 8.300 de saldo vencido, R$ 3.000 de PDD provisionada.
• Pré-requisito não-óbvio: o gatilho é manual de propósito (você roda depois de atualizar a planilha, pra não cobrar quem já pagou).

Uma régua de cobrança no n8n é um fluxo que lê o seu contas a receber, calcula o atraso de cada título na data de hoje, dispara o e-mail só nos vencidos e ainda consolida a provisão para devedores duvidosos (PDD) por faixa de atraso. Em vez de uma vez por trimestre no fechamento, você passa a ter a foto do risco toda vez que roda.

O problema: a cobrança que mora na sua cabeça

Toda tesouraria de empresa pequena ou média vive a mesma cena. O título vence, ninguém manda o lembrete na hora, e a cobrança vira uma lista mental que você carrega. Quando sobra um tempo, você abre o relatório de contas a receber, olha cliente por cliente, decide quem cobrar, escreve o e-mail, manda. No dia seguinte não lembra quem já recebeu o lembrete e quem ficou pra trás.

E tem a outra metade do problema, que é a visão de risco. Quanto desse contas a receber é provavelmente perdido? Para responder isso de verdade você precisa de aging (separar os títulos por faixa de atraso) e de PDD (a provisão para devedores duvidosos, que cresce conforme o título envelhece). Quase ninguém faz isso semana a semana. Faz no fechamento, na unha, numa planilha que muda de mão.

Montei um fluxo no n8n que resolve as duas coisas de uma vez. Ele lê o contas a receber de uma Google Sheet, calcula o atraso de cada título, dispara o e-mail de cobrança só nos vencidos, grava num log o que saiu, e consolida a PDD por faixa de atraso num relatório que vai pro seu e-mail. Rodei com 6 títulos de teste: 5 cobranças disparadas, R$ 8.300 de saldo vencido, R$ 3.000 de PDD provisionada.

A arquitetura é simples de propósito, e ERP-agnóstica

A decisão de arquitetura mais importante aqui é a mais chata: o fluxo não conecta no seu ERP. Ele lê uma Google Sheet.

Isso parece um passo pra trás até você pensar como operador. Qualquer ERP brasileiro (Omie, ContaAzul, Sankhya, TOTVS, o que for) exporta o contas a receber pra Excel ou CSV. Você cola isso numa aba de Google Sheet e pronto, o fluxo lê. Não preciso de API de ERP, não preciso de conector pago, não preciso pedir acesso pra TI. Se amanhã a empresa troca de ERP, o fluxo continua igual. A planilha é a interface, e ela é universal.

O caminho inteiro é esse:

Google Sheet (export do ERP)
   → n8n lê as contas a receber
   → calcula o atraso (aging) de cada título na data de hoje
   → filtra só os vencidos
   → dispara o e-mail de cobrança
   → grava cada cobrança num log na própria Sheet
   → consolida a PDD por faixa
   → manda o relatório de inadimplência pro e-mail interno

Tudo o que você precisa configurar (qual planilha, quais e-mails, o texto da mensagem, os percentuais de PDD) fica num único nó Configurações no topo. Você não encosta nos nós de cálculo nem nos de integração. Abre o Configurações, preenche, roda.

Por que o gatilho é manual (decisão de operador, não preguiça)

A primeira pergunta que todo mundo faz é: por que não deixar agendado pra rodar sozinho toda manhã?

Porque cobrança errada é pior que cobrança atrasada. Se o fluxo rodar sozinho às 8h em cima de uma planilha que ainda não recebeu as baixas de ontem, ele cobra gente que já pagou. Você queima a relação com um cliente bom por causa de um dado velho.

O gatilho aqui é um botão manual (“Rodar a Régua”). O desenho é proposital: você atualiza a planilha (exporta o contas a receber do dia, confere as baixas), e aí você roda. O dado fresco é responsabilidade sua, e o fluxo só age depois que você decidiu que a foto está correta.

A regra geral que aplico: gatilho automático só quando a fonte do dado é confiável e automática. Quando a ação depende de um dado que uma pessoa precisa atualizar (e contas a receber é exatamente isso), o gatilho é manual. A frescura do dado manda no tipo de gatilho.

Passo a passo dos nós

Os nós, na ordem em que o fluxo executa:

1. Rodar a Régua (gatilho manual). O botão de “executar workflow” do n8n. Você clica depois de atualizar a planilha. É o ponto de controle humano.

2. Configurações. Um nó Set/Code no topo onde mora tudo que você troca: o documentId da Sheet, o nome da aba de contas, o nome da aba de log, o e-mail interno que recebe o relatório, o template da mensagem de cobrança (com placeholders {cliente}, {titulo}, {valor}, {diasAtraso}), e as faixas de PDD com os percentuais. A ideia é que você configure aqui e nunca mais precise abrir outro nó.

3. Ler Contas a Receber. Nó Google Sheets (read) que puxa a aba de contas a receber. Cada linha vira um título: cliente, e-mail, número do título, emissão, vencimento, valor, status.

4. Calcular Aging. Nó Code (JS). Pega a data de hoje no fuso de Brasília e calcula os dias de atraso de cada título. Classifica na faixa (0-30, 31-60, 61-90, 91-180, +180, ou “a vencer”). Usar a data dinâmica de Brasília aqui é o que faz o aging estar sempre correto, sem você editar nada.

5. Filtrar Vencidos. Nó IF/Filter. Só passam adiante os títulos com dias de atraso maior que zero. O que está a vencer não vira cobrança. No teste, dos 6 títulos, 5 passaram (A a E) e o Cliente F (faltando 23 dias pro vencimento) ficou de fora.

6. Enviar Cobrança. Nó Gmail (send). Para cada título vencido, monta o e-mail com o template do Configurações e manda pro e-mail do próprio devedor. Um e-mail por título.

7. Registrar Cobrança no log. Nó Google Sheets (append) que grava cada cobrança numa aba Log de Cobranças da mesma Sheet. Colunas: Data Envio, Título, Cliente, Email, Valor, Dias Atraso, Faixa, Assunto, Mensagem enviada, Status. Esse nó existe por um motivo de operador: você precisa auditar o que saiu sem ficar caçando na caixa de e-mail. Abre a aba de log e vê tudo o que a régua disparou, com o texto que foi enviado.

8. Consolidar PDD. Nó Code (JS). Agrupa todos os títulos vencidos por faixa, soma o saldo de cada faixa e aplica o percentual de provisão. Devolve a tabela de aging com a PDD.

9. Enviar Relatório. Nó Gmail (send) que manda a tabela de aging + PDD pro e-mail interno configurado (o seu, ou o do gestor). Esse e-mail vai só pra dentro de casa, nunca pro cliente.

O coração do cálculo são dois blocos Code. O do Calcular Aging, em resumo:

// data de hoje no fuso de Brasília, nunca data fixa
const hoje = DateTime.now().setZone('America/Sao_Paulo').startOf('day');
const venc = DateTime.fromISO(item.vencimento).startOf('day');
const diasAtraso = Math.floor(hoje.diff(venc, 'days').days);

let faixa = 'a vencer';
if (diasAtraso > 0)        faixa = '0-30';
if (diasAtraso > 30)       faixa = '31-60';
if (diasAtraso > 60)       faixa = '61-90';
if (diasAtraso > 90)       faixa = '91-180';
if (diasAtraso > 180)      faixa = '+180';

E o do Consolidar PDD, agrupando e provisionando:

// faixasPdd vem do nó Configurações: { "0-30": 0.05, "31-60": 0.10, ... }
const porFaixa = {};
for (const t of titulosVencidos) {
  porFaixa[t.faixa] ??= { saldo: 0, pdd: 0 };
  porFaixa[t.faixa].saldo += t.valor;
  porFaixa[t.faixa].pdd   += t.valor * faixasPdd[t.faixa];
}

Mantive os blocos curtos de propósito. São versões resumidas da lógica, não o JS exato do workflow. Quem quiser o fluxo pronto importa o JSON (mais sobre isso no fim).

A PDD por faixa de atraso, com o número real

A lógica de provisão é a parte que separa isso de um “mandador de e-mail”. A PDD provisiona uma parte do saldo de cada faixa, e essa parte cresce conforme o título envelhece. A tabela que usei:

Faixa (dias de atraso)	% de provisão
0-30	5%
31-60	10%
61-90	30%
91-180	50%
+180	100%

Os percentuais ficam no nó Configurações, então cada empresa pluga a própria política de provisão. Não existe número mágico aqui; existe a política da sua contabilidade.

Com os 6 títulos de teste (data de referência 2026-06-07), a saída foi essa:

Faixa	Título	Saldo	PDD
0-30 (A=18d)	Cliente A	R$ 1.000	R$ 50
31-60 (B=43d)	Cliente B	R$ 2.000	R$ 200
61-90 (C=79d)	Cliente C	R$ 1.500	R$ 450
91-180 (D=148d)	Cliente D	R$ 3.000	R$ 1.500
+180 (E=249d)	Cliente E	R$ 800	R$ 800
A vencer (F)	Cliente F	R$ 5.000	R$ 0 (não cobra)
Total vencido		R$ 8.300	R$ 3.000

Leitura de operador: do contas a receber em atraso (R$ 8.300), R$ 3.000 já estão provisionados como provável perda. E quase todo esse risco mora num lugar só, o Cliente D (R$ 1.500 de PDD, faixa 91-180). É essa visão que a régua te dá toda vez que você roda, em vez de uma vez por trimestre no fechamento.

Como evitar cobrança indevida e duplicada

Aqui vem a parte honesta, e ela importa porque cobrança errada custa cliente. A revisão de risco do fluxo (feita antes de eu liberar) apontou três pontos que você precisa saber antes de rodar em cima de dado real.

1. O fluxo cobra todo título vencido com status “em aberto”. Se a baixa não chegou na planilha, ele cobra quem já pagou. O gatilho manual mitiga isso (você só roda depois de atualizar a planilha com as baixas do dia), mas a responsabilidade do dado é sua. A próxima versão do fluxo vai filtrar explicitamente status != pago/baixado em vez de confiar só em “em aberto”, e vai considerar uma carência (não cobrar nos primeiros 1 a 3 dias de atraso, que costumam ser só o pagamento ainda compensando). Por enquanto: confira as baixas antes de rodar.

2. Rodar duas vezes no mesmo dia dispara o e-mail duas vezes pro mesmo título. O fluxo não tem dedupe ainda. O log registra os dois disparos, mas não bloqueia o segundo. Regra prática até a v2 resolver: antes de rodar, abra a aba Log de Cobranças e confira se já rodou hoje. Se rodou, não rode de novo. O log existe justamente pra isso ser visível.

3. A mensagem é única para todas as faixas. Hoje o cliente de 18 dias e o de 249 dias recebem o mesmo tom. Funciona, mas o ideal é escalonar (lembrete leve até 30 dias, tom mais firme acima de 90). Deixei a mensagem editável no Configurações; escalonar por faixa entra como evolução.

Nenhum desses pontos quebra o piloto. Mas se você for rodar isso na sua empresa, eles são a diferença entre uma régua que ajuda e uma que gera dor de cabeça. A régua não dispensa o seu olho no dado, e a conferência fiscal continua sua.

Uma última coisa sobre dado sensível: construí e testei tudo com dados fake-BR (cliente fictício, e-mail @teste.com, valores redondos). O fluxo orquestra (lê a Sheet, calcula, manda e-mail, grava log); ele não é cofre de extrato bancário. Rode na sua instância de n8n, com os seus dados. Dado bancário de verdade pede outra arquitetura (processamento local), que é assunto de outro produto.

Como verificar se deu certo

Depois de rodar, três checagens rápidas confirmam que a régua fez o que devia:

1. Conta os e-mails. No teste, 5 cobranças saíram (Clientes A a E) e o Cliente F (a vencer) ficou de fora. Se um título a vencer recebeu cobrança, o filtro de vencidos está errado.
2. Abre a aba Log de Cobranças. Cada e-mail disparado vira uma linha com a mensagem enviada. É a sua auditoria sem precisar caçar na caixa de saída.
3. Confere o total da PDD. O relatório interno fecha em R$ 8.300 de saldo vencido e R$ 3.000 de PDD. Se a soma das faixas não bate com o total, o percentual de alguma faixa no Configurações está fora da sua política.

Perguntas relacionadas

A régua funciona com o meu ERP (Omie, ContaAzul, TOTVS)?

Funciona com qualquer um, porque o fluxo não conecta no ERP. Ele lê uma Google Sheet onde você cola o export do contas a receber (todo ERP brasileiro exporta pra Excel ou CSV). A planilha é a interface, então trocar de ERP não quebra nada: o fluxo continua igual, você só troca o export.

Dá pra deixar a régua agendada, rodando sozinha todo dia?

Dá, mas eu não faria enquanto o contas a receber depender de você atualizar a planilha. Se o fluxo rodar às 8h em cima de um dado que ainda não recebeu as baixas de ontem, ele cobra quem já pagou. Gatilho automático só quando a fonte do dado é confiável e automática.

Isso não vira cobrança indevida, mandando e-mail pra quem já pagou?

Vira, se a planilha estiver desatualizada. O fluxo cobra todo título vencido com status em aberto, então uma baixa que não chegou na planilha vira e-mail pra um cliente adimplente. É por isso que o gatilho é manual: você confere as baixas do dia, atualiza a planilha e só então roda.

Se eu rodar a régua duas vezes no mesmo dia, o cliente recebe dois e-mails?

Recebe. O fluxo ainda não tem dedupe: o log registra os dois disparos, mas não bloqueia o segundo. Até isso entrar na v2, a regra prática é abrir a aba Log de Cobranças antes de rodar e conferir se já rodou hoje. Se rodou, não rode de novo.

Os percentuais de PDD do exemplo (5% a 100%) servem pra minha empresa?

Servem como ponto de partida, não como verdade. Os percentuais que usei (5% na faixa de 0 a 30 dias até 100% acima de 180) são uma tabela de exemplo; a sua vem da política de provisão da sua contabilidade. Eles ficam num nó de configuração, então você troca sem mexer no cálculo.

Posso rodar isso com os dados reais dos meus clientes?

Pode, na sua própria instância de n8n, com as suas credenciais. Montei e testei tudo com dados fictícios, e o fluxo só orquestra (lê a planilha, calcula, manda e-mail, grava o log). Ele não é cofre de dado bancário: extrato de verdade pede outra arquitetura, com processamento local.

Próximo passo

Se você quer parar de carregar a cobrança na cabeça e ainda ganhar a visão de risco por aging toda semana, esse fluxo faz o trabalho. Os pontos do “como evitar cobrança indevida” são a v2 (filtro de status, carência, dedupe, mensagem por faixa), e eu publico a evolução aqui.

Se quiser o contexto de mercado por trás disso, o ponto de partida é o Radar sobre agente de IA na tesouraria BR: 83% das empresas brasileiras ainda nem automatizam cobrança, e essa régua é o primeiro passo concreto pra sair desse número.

---