Como automatizar contas a pagar: da nota ao pagamento

Segunda-feira, nove da manhã. A caixa de entrada do financeiro tem boletos em PDF, notas fiscais encaminhadas pelo comercial, uma foto de recibo tirada no celular e um e-mail do fornecedor avisando que "mudou de banco". Alguém abre cada anexo, digita valor e vencimento no ERP, procura o pedido de compra para conferir, manda mensagem para o diretor aprovar e, no fim do dia, sobe o lote no internet banking. Na semana seguinte, outra pessoa passa a tarde marcando no sistema o que foi pago.

O processo funciona até o dia em que um boleto vence esquecido, uma nota é paga duas vezes ou um boleto adulterado passa pela conferência. Não é falta de cuidado da equipe: é um processo que depende de atenção humana onde uma regra conferiria melhor.

Automatizar contas a pagar não é tirar pessoas do processo. É fazer a máquina digitar, cruzar e lembrar, e deixar as pessoas decidirem. Este texto percorre o fluxo inteiro, da chegada do documento à baixa, e mostra em cada etapa o que dá para automatizar e onde o controle humano precisa ficar.

A resposta curta: as cinco etapas do fluxo automatizado

Para quem quer o mapa antes do detalhe, automatizar contas a pagar significa montar este fluxo:

1. Captura: notas, boletos e faturas entram no sistema sem digitação, a partir do XML, do código de barras ou de leitura automática do PDF.
2. Conferência: cada documento é cruzado com o pedido de compra e com o recebimento da mercadoria ou do serviço.
3. Aprovação: o título conferido segue para quem tem alçada para aprovar aquele valor e aquela categoria de despesa.
4. Pagamento: os títulos aprovados viram um lote agendado no banco, por arquivo de remessa ou por API.
5. Baixa: o retorno do banco confirma o pagamento, e o título é baixado e conciliado sem ninguém marcar à mão.

Em todas as etapas, o que não se encaixa na regra vai para uma fila de exceções com dono e motivo. É ela que concentra o trabalho humano, em vez de espalhá-lo pelo processo inteiro.

Onde o contas a pagar manual perde tempo e dinheiro

Antes de desenhar a automação, vale nomear os vazamentos. Eles costumam ser os mesmos em empresas de portes e setores diferentes:

• Digitação. Cada nota ou boleto é redigitado no ERP: fornecedor, valor, vencimento, centro de custo. Erro de um dígito no valor ou na data vira pagamento errado ou juros.
• Documento perdido. O boleto chegou no e-mail de quem pediu a compra, não no do financeiro. Só aparece quando o fornecedor cobra o atraso.
• Pagamento em duplicidade. A mesma nota chega pelo fornecedor e pelo comprador, e é lançada duas vezes.
• Pagar o que não chegou. A nota vem com quantidade ou preço diferente do pedido, e ninguém confere antes do vencimento.
• Aprovação por mensagem. O "pode pagar" fica num aplicativo de conversa, sem registro auditável de quem aprovou o quê.
• Baixa atrasada. O pagamento saiu, mas o título continua em aberto no sistema, e o fluxo de caixa projetado fica errado.

Captura de boletos, notas e faturas sem digitação

A captura é onde a automação devolve mais horas, e a regra de ouro é: use o dado estruturado sempre que ele existir, e só leia PDF quando não houver alternativa.

Notas fiscais: o XML já tem tudo

Para a nota fiscal eletrônica de mercadorias (NF-e), o arquivo que vale é o XML, não o DANFE em PDF. Ele traz emitente, itens, quantidades, valores, impostos e, muitas vezes, as duplicatas com vencimento. Além de receber o XML por e-mail, o sistema pode buscar as NF-e emitidas contra o CNPJ da empresa no serviço de distribuição de documentos fiscais do ambiente nacional da NF-e, usando o certificado digital da empresa. Isso reduz a dependência de o fornecedor lembrar de enviar. Para notas de serviço (NFS-e), o formato e o canal de consulta ainda variam conforme o município, porque a migração para o padrão nacional da NFS-e não acontece no mesmo ritmo em todas as prefeituras, e o sistema precisa suportar essa variação.

Boletos: o código de barras é a fonte

A linha digitável do boleto já contém o banco, o valor e o vencimento. Ler o código de barras do PDF elimina a digitação desses campos. O que a linha digitável não traz é o beneficiário: o nome e o CNPJ de quem vai receber aparecem na consulta do boleto registrado, que o banco faz antes de pagar, seja no internet banking, seja pela API. E, quando a empresa usa o DDA (Débito Direto Autorizado) no seu banco, os boletos emitidos contra o CNPJ dela aparecem lá, mesmo que o PDF nunca chegue. Cruzar o que veio por e-mail com o que está no DDA é uma das conferências mais úteis do processo.

Faturas e documentos sem padrão

Conta de concessionária, fatura de serviço internacional, recibo de prestador: aqui entra a leitura automática do documento. O sistema classifica o tipo, extrai os campos para um formato fixo e valida contra o cadastro. Como montar esse pipeline com segurança, inclusive com revisão humana nos campos duvidosos, está em extração de dados de documentos com IA.

Um ponto prático: crie um canal único de entrada, como um endereço de e-mail exclusivo para documentos de pagamento, e oriente fornecedores e compradores a usá-lo. Metade do problema de documento perdido se resolve aqui, antes de qualquer código.

Conferência automática com pedido e recebimento

Capturar é só metade. A pergunta que o financeiro precisa responder antes de pagar é: essa cobrança corresponde a algo que pedimos e recebemos?

A técnica clássica é o cruzamento em três pontas:

Quando as três batem dentro de uma tolerância definida pela empresa, o título segue sozinho para aprovação. Quando não batem, vai para a fila de exceções com o motivo explícito: "preço unitário acima do pedido", "quantidade faturada maior que a recebida", "nota sem pedido vinculado".

Esse cruzamento só é possível se o pedido de compra existir no sistema. Em empresas onde a compra ainda acontece por e-mail, a automação do pagamento esbarra na falta de dado do lado da compra. Por isso vale olhar os dois processos juntos; o desenho do lado da compra está em sistema de cotação e compras: da requisição ao pedido.

Despesas sem pedido (aluguel, energia, assinaturas) são comparadas com o contrato ou com o histórico: uma conta de energia muito acima da média merece um olhar humano.

Duas checagens automáticas valem para qualquer documento:

• Duplicidade: mesmo fornecedor, mesmo número de documento ou mesmo código de barras já lançado.
• Cadastro: fornecedor ativo, CNPJ válido e dados bancários conferidos.

Aprovação por alçada antes de pagar

A aprovação é onde o controle humano precisa ficar, e a automação serve para torná-la rápida e rastreável.

Uma política de alçadas define quem aprova o quê. Ela costuma combinar três critérios:

• Valor: faixas de valor com aprovadores diferentes, definidas pela própria empresa.
• Natureza da despesa: investimento, despesa recorrente, serviço pontual.
• Centro de custo: o gestor da área aprova o que é da área dele.

O sistema envia o título ao aprovador certo, com o documento, o pedido e o resultado da conferência na mesma tela. O aprovador decide pelo celular ou pelo computador, e cada decisão fica registrada com nome, data e hora. Se ninguém aprova em um prazo definido, o pedido sobe para o substituto, para que o vencimento não chegue antes da decisão.

Um princípio que não deve ser automatizado: quem lança não aprova, e quem aprova não paga. Essa segregação de funções é a principal defesa interna contra erro e fraude, e o sistema deve impedir que a mesma pessoa execute as três etapas no mesmo título.

Agendamento e remessa ao banco

Com os títulos aprovados, o sistema monta o lote de pagamento. Há dois caminhos técnicos principais:

• Arquivo de remessa, no padrão CNAB que os bancos brasileiros usam há décadas. O sistema gera o arquivo, alguém com permissão o envia ao banco, e o banco devolve um arquivo de retorno com o resultado de cada pagamento.
• API do banco, oferecida por muitas instituições para pagamento de boletos, transferências e Pix. O pagamento é enviado direto pelo sistema, e a confirmação volta pela mesma via.

Qual dos dois usar depende dos bancos com que a empresa trabalha e do que cada um oferece. A escolha entre integrar por API ou automatizar o uso do internet banking por robô também aparece aqui, e os critérios estão em RPA ou integração via API. Em pagamento, a API é preferível sempre que existe, porque o retorno é estruturado e o controle de acesso é do banco.

Em qualquer caminho, a liberação final no banco deve continuar humana, com a autenticação de quem tem poder para movimentar a conta. O sistema prepara o lote, mostra o total e a lista, e a pessoa autorizada libera. A automação elimina a digitação, não a assinatura.

Com os vencimentos no sistema, ele também pode sugerir a data de pagamento considerando o saldo projetado e descontos por antecipação.

Baixa automática e conciliação

O pagamento saiu. Agora o título precisa ser baixado no sistema, com data, valor pago, juros ou desconto, e a conta bancária usada.

Com o retorno do banco (arquivo ou API), essa baixa é automática: cada pagamento confirmado localiza o título correspondente e o fecha. Pagamentos rejeitados, como boleto já pago, conta encerrada ou dado divergente, voltam para a fila de exceções em vez de ficarem esquecidos.

A etapa seguinte é conferir a baixa contra o extrato bancário, garantindo que o que o sistema diz que saiu de fato saiu. Esse cruzamento, com suas tolerâncias e tratamento de tarifas, é o mesmo da conciliação dos recebimentos e está detalhado em conciliação bancária automática.

Fraudes e boletos falsos: as travas necessárias

Automatizar contas a pagar sem travas antifraude é acelerar o erro. Os golpes mais comuns no contas a pagar de empresas exploram exatamente as brechas do processo manual:

• Boleto adulterado. O PDF chega com a linha digitável trocada. O valor e o vencimento parecem certos, mas o beneficiário é outro.
• Troca de dados bancários. Um e-mail, às vezes da conta verdadeira do fornecedor que foi invadida, pede para pagar numa conta nova.
• Fornecedor fantasma. Um cadastro criado para receber pagamentos que não correspondem a nenhuma compra.

As travas que o sistema precisa ter:

1. Beneficiário conferido. O CNPJ do beneficiário retornado na consulta do boleto, ou o titular da chave Pix, precisa coincidir com o fornecedor cadastrado. Divergência bloqueia o pagamento.
2. Boleto que não está no DDA recebe sinal de alerta e vai para conferência.
3. Alteração de dados bancários exige confirmação por um canal independente, como uma ligação para um contato já cadastrado, nunca pelo próprio e-mail que pediu a mudança. O sistema registra quem confirmou e bloqueia pagamentos à conta nova até lá.
4. Cadastro de fornecedor com aprovação de uma pessoa diferente de quem cadastrou.
5. Pagamento sem pedido ou contrato acima de um limite definido pela empresa exige aprovação adicional.
6. Trilha de auditoria completa: cada lançamento, alteração, aprovação e liberação fica registrado e não pode ser apagado.

Também vale lembrar que documentos de pagamento trazem dados pessoais de prestadores pessoa física, e o acesso a eles deve ser restrito a quem precisa, como pede a LGPD.

Checklist para começar a automatizar

Um roteiro em ordem de dependência, para não automatizar o caos:

1. Mapeie o fluxo real: por onde os documentos chegam, quem lança, quem aprova, quem paga e quanto tempo cada etapa leva hoje.
2. Escreva a política de alçadas e valide com a diretoria antes de configurá-la no sistema.
3. Crie o canal único de entrada de documentos e comunique aos fornecedores.
4. Limpe o cadastro de fornecedores, com CNPJ e dados bancários conferidos.
5. Ligue a captura estruturada primeiro (XML e código de barras), e a leitura de PDF depois.
6. Defina as tolerâncias da conferência com pedido e recebimento.
7. Implemente as travas antifraude antes de automatizar o pagamento, não depois.
8. Integre com o banco e com a baixa, começando por uma conta bancária.
9. Rode em paralelo com o processo atual por alguns ciclos de pagamento, conferindo título a título.
10. Meça: títulos lançados sem digitação, tempo entre a chegada do documento e a aprovação, pagamentos com juros por atraso e tamanho da fila de exceções.

Questões tributárias, como retenções em notas de serviço e escrituração das despesas, precisam ser validadas com o contador da empresa. O sistema deve suportar as regras, mas quem as define é quem responde pela contabilidade. Do lado do escritório, a rotina é tema de sistema para escritório de contabilidade.

Perguntas frequentes

O que é DDA e como ele ajuda no contas a pagar?

O DDA, ou Débito Direto Autorizado, é um serviço bancário em que os boletos emitidos contra o CNPJ da empresa aparecem no banco, mesmo que o PDF nunca chegue. No contas a pagar, o DDA ajuda a não perder vencimentos e a detectar fraude: boleto recebido por e-mail que não aparece no DDA merece conferência antes do pagamento.

Dá para automatizar o pagamento sem ninguém aprovar?

Não é recomendável. A automação do contas a pagar deve digitar, cruzar e lembrar, mas a aprovação por alçada e a liberação final no banco continuam humanas. A segregação de funções, em que quem lança não aprova e quem aprova não paga, é a principal defesa interna contra erro e fraude no processo.

Preciso trocar de ERP para automatizar o contas a pagar?

Normalmente não. Muitas vezes basta aproveitar o ERP e construir só a camada que falta: captura dos documentos, conferência com pedido e recebimento, telas de aprovação, fila de exceções e integração com o banco. O ERP continua como registro dos títulos, recebendo os lançamentos e as baixas feitos pela automação do contas a pagar.

Qual a diferença entre CNAB e API bancária?

CNAB é o padrão de arquivo de remessa e retorno que os bancos brasileiros usam há décadas: o sistema gera o arquivo, alguém com permissão envia ao banco e o banco devolve o resultado. A API bancária envia o pagamento direto pelo sistema e devolve a confirmação pela mesma via, de forma estruturada, e é preferível quando o banco oferece.

Quanto tempo leva para automatizar o contas a pagar?

Depende do volume de documentos, do ERP e dos bancos envolvidos. A automação do contas a pagar costuma seguir fases: diagnóstico, protótipo, piloto com uma conta bancária e um grupo de fornecedores e expansão, com alguns ciclos de pagamento rodando em paralelo ao processo atual. O cronograma só se define depois do diagnóstico.

Como a Pervian Tech trabalha automação financeira

Na Pervian Tech, começamos pelo diagnóstico gratuito do seu fluxo: quantos documentos chegam, por quais canais, o que o ERP já faz bem, quais bancos estão envolvidos e onde a equipe perde mais tempo hoje. Muitas vezes basta aproveitar o ERP e construir só a camada que falta.

A partir daí, desenhamos a automação sob medida, com desenvolvimento web para as telas de aprovação e exceção e integração com ERP e bancos por API sempre que possível. O cronograma segue fases (diagnóstico, protótipo, piloto com uma conta e um grupo de fornecedores, expansão) e é definido depois do diagnóstico. Outras frentes do tema estão na página de automação de processos e na categoria automação do blog.

O investimento é sob consulta, porque depende do volume de documentos, dos sistemas e bancos envolvidos e das regras da sua empresa. Se o seu contas a pagar ainda começa numa caixa de e-mail, conte como ele funciona hoje.