- O WhatsApp é interface; a base de dados é a “fonte de verdade” do processo.
- Padronização (campos mínimos + respostas estruturadas) evita retrabalho e fraudes bobas.
- Auditoria não é luxo: registre quem decidiu, quando, o quê e com qual comprovante.
- Planeje falhas: deduplicação, retries e um caminho de exceção mantêm o processo vivo.
Defina o “mínimo necessário” (para não virar chat infinito)
Padronize o que o solicitante precisa enviar: valor, categoria/centro de custo, descrição curta, forma de pagamento e comprovante (imagem/PDF). Se faltar algo, o fluxo devolve uma pergunta objetiva (“Qual centro de custo?”) em vez de aceitar texto livre sem estrutura.
Escolha como o WhatsApp vai entrar no fluxo (oficial vs não oficial)
Decida o provedor/canal que vai receber mensagens e anexos e repassar ao n8n (webhook). Em processo financeiro, priorize estabilidade e conformidade: o custo pode ser maior, mas a previsibilidade costuma compensar.
Crie um endpoint de entrada (Webhook) e normalize o payload
No n8n, crie um Webhook para receber: número/ID do usuário, texto, mídia (URL/ID), timestamp e metadados. Normalize tudo para um formato interno único (ex.: {solicitanteId, valorCentavos, categoria, descricao, anexoUrl, origem}). Isso reduz “remendos” mais adiante.
Valide e faça deduplicação (idempotência)
Implemente regras simples: valor > 0, categoria permitida, tamanho/ tipo de arquivo do anexo, limite por política. Para evitar duplicidade (mensagem reenviada, webhook repetido), gere uma chave única (ex.: hash do anexo + valor + data + solicitante) e recuse reprocessamentos idênticos.
Grave um registro auditável antes de pedir aprovação
Salve em uma base (planilha, banco, Airtable/Supabase, etc.) o status inicial “PENDENTE”, o conteúdo recebido e o link do comprovante. O fluxo não deve depender do chat como “fonte de verdade”. Se o aprovador demorar, o processo não se perde.
Roteie para o aprovador correto (regra por valor e centro de custo)
Crie uma matriz simples de aprovação: até X vai para líder, acima vai para gerente/diretoria; certos centros de custo exigem aprovação dupla. Se você não tiver o dado exato de limites/política, comece com uma regra conservadora e ajuste com o time financeiro.
Envie a solicitação ao aprovador com ação clara (aprovar/reprovar)
Envie uma mensagem estruturada com: solicitante, valor, categoria, descrição e link/preview do comprovante. A ação deve ser inequívoca: “APROVAR 1234” ou botões (quando suportado). Evite respostas livres como “ok”, porque viram dor de cabeça na auditoria.
Trate a resposta do aprovador e trave contra fraude básica
Confirme que quem respondeu é o aprovador esperado (ID/número). Se a resposta vier de outro contato, registre como tentativa inválida. Para casos sensíveis, use segunda confirmação (ex.: “Confirme APROVAR novamente”) ou aprovação em dois níveis.
Atualize status, registre justificativa e gere trilha de auditoria
Ao aprovar/reprovar, atualize o registro com: aprovador, data/hora, decisão, justificativa (obrigatória na reprovação) e anexos/links. Se houver política de retenção, defina prazo e rotinas de limpeza (com cuidado para não apagar o que a contabilidade precisa manter).
Integre com o financeiro (contas a pagar / reembolso) sem “pular etapas”
Após aprovação, dispare a criação de lançamento/solicitação no sistema financeiro (ou fila de conferência). Mantenha um status intermediário “APROVADO_AGUARDANDO_FINANCEIRO” para separar a decisão da execução. Isso evita que um erro de integração pareça “reprovação”.
Inclua reprocessamento, alertas e um caminho de exceção
Defina: quantas tentativas de envio ao aprovador, backoff, e o que fazer se o provedor do WhatsApp cair (ex.: mandar e-mail/Slack para o financeiro). Crie um painel simples de pendências e um fluxo manual de “reanalisar” quando um anexo expirar ou um link quebrar.
Arquitetura rápida (sem complicar)
Para um processo que não vire um monstro, pense em três trilhas: entrada (solicitação), decisão (aprovação) e execução (financeiro). Cada trilha grava estado e não depende do chat para “lembrar” do que aconteceu.
Se você já viu fluxo quebrar por causa de mensagem duplicada, anexo que some ou aprovador que responde “ok”, sabe por que normalização e idempotência aparecem cedo aqui.
- Entrada: WhatsApp → Webhook → Validação → Registro PENDENTE
- Decisão: Roteamento → Mensagem ao aprovador → Resposta → Registro APROVADO/REPROVADO
- Execução: Integração financeiro → Status final + comprovantes + logs
Campos mínimos recomendados (e por quê)
Quanto mais “conversa”, mais chance de erro. Em despesas, o custo da dúvida geralmente é maior do que o custo de pedir um campo a mais.
A tabela abaixo é um ponto de partida. Ajuste ao seu contexto (ex.: viagem, obra, marketing, TI).
| Campo | Exemplo | Motivo prático |
|---|---|---|
| Valor | R$ 128,90 | Sem isso, não dá para aplicar regra por faixa nem conferir reembolso |
| Categoria/centro de custo | Marketing > Ads | Define aprovador e facilita conciliação |
| Descrição curta | Uber para reunião cliente X | Ajuda auditoria e reduz contestação |
| Forma de pagamento | Cartão pessoal | Muda tratamento: reembolso vs lançamento direto |
| Comprovante | Foto nota/PDF | Base documental; sem anexo vira “ouvi dizer” |
| Projeto/cliente (se aplicável) | Cliente ACME | Permite rateio e repasse correto |
Cuidados de LGPD que pegam esse tipo de fluxo
Despesas podem carregar dados pessoais sem querer (nome completo em nota, endereço, placa, geolocalização no comprovante). Defina quem pode ver, por quanto tempo e com qual finalidade.
Se o comprovante ficar em um storage público por link, trate como risco: prefira links temporários e controle de acesso. Quando eu vejo vazamento nesse tipo de automação, quase sempre é por “atalho” em anexo.
- Minimização: colete só o necessário para aprovar e prestar contas.
- Acesso: aprovadores veem apenas o que precisam (não o histórico inteiro).
- Retenção: prazo claro para apagar mensagens/anexos que não precisam mais existir.
- Registro: mantenha trilha de auditoria (quem acessou/decidiu) quando fizer sentido.
Erros comuns (que parecem pequenos, mas quebram o processo)
Aprovação via WhatsApp funciona muito bem quando é “chato” do jeito certo: regras claras e estados claros.
Se você quer reduzir incêndios, evite estes pontos:
- Não ter status intermediário (tudo vira “aprovado” mesmo quando falhou enviar ao financeiro).
- Aceitar resposta livre do aprovador (vira disputa: “eu não aprovei isso”).
- Não deduplicar mensagens/webhooks (duplicidade de reembolso é o pior tipo de bug).
- Não prever exceção: aprovador em férias, comprovante ilegível, categoria inexistente.
Perguntas frequentes
Dá para fazer aprovação de despesas no WhatsApp sem usar botões, só com mensagem?
Como evitar duplicidade (duas aprovações ou dois reembolsos) quando o webhook repete?
Onde guardar os comprovantes: no WhatsApp, no Drive, ou em um storage próprio?
Precisa mesmo registrar quem aprovou e quando, se é uma empresa pequena?
Leia também
Como automatizar contas a pagar e receber com n8n (passo a passo)
Aprenda a automatizar contas a pagar e receber com n8n sem programar: alertas de vencimento, cobrança automática por WhatsApp e conciliação com planilha.
Ler →
Webhook no n8n: como receber, tratar e responder HTTP (sem gambiarra)
Aprenda a criar um webhook no n8n, validar assinatura, tratar payload, evitar duplicidade e responder HTTP 200/400/500 com padrão de produção.
Ler →
Automação de WhatsApp e LGPD: o que pode, o que não pode e como não tomar multa
Guia direto sobre automação de WhatsApp e LGPD: o que é permitido, o que vira risco (base comprada, disparo frio) e como se blindar com consentimento, opt-out e registro de evidências.
Ler →
Rate limit, retry e backoff: como parar de quebrar automação em API (n8n, Make, Zapier)
Guia direto para lidar com rate limit (429), retries e backoff em automações com APIs. Aprenda padrões práticos para n8n, Make e Zapier e evite falhas intermitentes, duplicidades e banimentos.
Ler →