Agente de IA em contas a pagar e receber: prepara, confere, não paga

Agente de IA em contas a pagar e receber: prepara, confere, não paga

Um agente de IA para contas a pagar e receber prepara e confere o trabalho repetitivo: lê notas e boletos, cruza com pedido e contrato, monta o lote de pagamento, sugere a conciliação e rascunha cobranças. O que move dinheiro não é executado por ele: pagamento, baixa, estorno e troca de dados bancários de fornecedor só saem com a aprovação de uma pessoa identificada, com registro. O valor está em chegar à aprovação com tudo conferido, não em tirar a pessoa do processo.

Principais pontos

• O agente trabalha na preparação e na conferência: leitura de documentos, cruzamentos, rascunhos, alertas e pendências organizadas.
• Pagamento, baixa, estorno, desconto e alteração de conta bancária de fornecedor exigem aprovação humana, sempre, por regra e não por sugestão no prompt.
• A permissão importa mais que a inteligência: o agente deve ter acesso de leitura e de criação de rascunho, nunca a chave que libera a transferência.
• Cada decisão do agente precisa deixar um registro: o que leu, o que comparou, o que sugeriu e quem aprovou.
• O caminho seguro é começar por um único fluxo, com métrica combinada, e só depois decidir se amplia, ajusta ou para.

O que significa um agente de superinteligência no financeiro?

O termo aparece bastante em material comercial, mas convém ser exato. Nenhum agente que uma empresa opera hoje é uma superinteligência no sentido discutido na literatura. O que existe é um agente de IA com acesso a ferramentas, que lê, compara e propõe. Se você quer entender a diferença, vale ler o texto sobre AGI, superinteligência e agentes de IA.

No financeiro, isso importa por uma razão prática. Quando se promete uma inteligência que resolve tudo, a tendência é dar a ela acesso demais. A abordagem mais segura segue o que a própria Anthropic descreve ao falar de agentes: começar simples, usar fluxos previsíveis onde der e reservar a autonomia para onde ela realmente ajuda. Em contas a pagar e receber, a autonomia útil está na leitura e na conferência. A decisão que gera saída de caixa fica com gente.

O que o agente prepara em contas a pagar?

Contas a pagar tem muito trabalho que antecede o clique de pagar. É nessa fase que o agente economiza atenção da equipe. As tarefas de preparação mais comuns:

• Receber documentos de várias origens (e-mail do financeiro, pasta compartilhada, WhatsApp de fornecedor) e organizar tudo em uma fila única.
• Extrair dados de notas fiscais, boletos e faturas: fornecedor, CNPJ, valor, vencimento, número do documento, linha digitável.
• Sugerir a classificação: centro de custo, categoria contábil, projeto, conforme o histórico e as regras da empresa.
• Montar o rascunho do lançamento no sistema de gestão, marcado como pendente de revisão.
• Agrupar vencimentos da semana e propor uma ordem de pagamento, destacando o que tem multa ou juros por atraso.
• Redigir a mensagem de pergunta ao fornecedor ou ao solicitante quando falta informação.

Repare que todos os verbos são de preparar, sugerir, montar e redigir. Nenhum deles é pagar. O agente entrega um pacote pronto para uma pessoa decidir.

O que o agente confere antes de qualquer pagamento?

A conferência é onde um agente costuma ser mais útil, porque é cansativa para humanos e tem regras claras. Um bom conjunto de verificações:

• Três vias: o documento bate com o pedido de compra e com o recebimento do serviço ou da mercadoria?
• Duplicidade: já existe lançamento com mesmo fornecedor, valor e vencimento, ou com número de documento parecido?
• Fornecedor: o CNPJ está cadastrado, ativo na base interna e igual ao do documento?
• Conta de destino: os dados bancários do boleto ou da fatura são os mesmos do cadastro? Qualquer diferença vira alerta vermelho.
• Valor e condição: o valor está dentro do contrato, da tolerância definida e do orçamento do centro de custo?
• Impostos e retenções: o lançamento considera o que o contador definiu como regra, sem que o agente invente tratamento tributário?

Há ainda um risco que merece atenção própria. Documentos recebidos de fora são entrada não confiável. Um PDF ou e-mail pode conter texto escrito para enganar o modelo, como uma instrução disfarçada pedindo para ignorar regras ou trocar a conta. Isso se chama injeção de prompt, e o guia da OWASP sobre prevenção descreve as defesas. Em termos de operação financeira, a defesa principal é estrutural: o conteúdo de documentos é tratado como dado, nunca como ordem, e o agente não tem permissão para executar a ação perigosa mesmo que seja enganado.

E em contas a receber: cobrança, conciliação e baixa?

Do lado do recebimento, o agente também prepara e confere, e a fronteira é a mesma.

O que ele pode fazer:

• Cruzar o extrato bancário com os títulos em aberto e sugerir a conciliação, apontando o que casou com certeza e o que precisa de olhar humano (valor parcial, pagamento agrupado, cliente diferente do titular).
• Listar títulos vencidos por faixa de atraso e por cliente, com o histórico de contato.
• Redigir lembretes e cobranças no tom definido pela empresa, para revisão antes do envio.
• Preparar a segunda via de boleto ou a atualização de data, quando a política permitir, como rascunho.
• Separar divergências: pagamento a maior, a menor, sem identificação, em duplicidade.

Se a cobrança sai por WhatsApp, entram regras do canal. Mensagem ativa exige template aprovado e permissão do cliente, e a conversa tem a janela de atendimento própria. Vale conhecer o que dizem os textos sobre mensagens ativas no WhatsApp, templates e opt-in antes de automatizar qualquer régua de cobrança. Cobrança é também uma relação com o cliente, e tom e timing errados custam mais que o atraso.

A baixa em si, que marca o título como recebido e altera o saldo do cliente, é uma ação com efeito contábil. O agente sugere, a pessoa confirma.

O que nunca sai sem aprovação humana?

Esta é a parte central do desenho. Uma regra útil: se a ação é difícil de desfazer, envolve dinheiro saindo, ou altera um dado que protege o dinheiro, ela passa por uma pessoa. Um guia de decisão em forma de lista:

• Pagamento de qualquer valor: boleto, PIX, TED, transferência, cartão corporativo. Aprovação individual ou em lote, por alguém com alçada.
• Alteração de dados bancários de fornecedor: exige validação por um segundo canal (ligação para contato já cadastrado, por exemplo), feita por pessoa.
• Baixa de título a receber: confirmada por quem concilia, principalmente em casos de pagamento parcial ou divergente.
• Concessão de desconto, abatimento, parcelamento ou renegociação: decisão comercial e financeira, fora do escopo do agente.
• Estorno, cancelamento de título e emissão de nota de crédito.
• Cadastro de novo fornecedor ou cliente com limite de crédito.
• Qualquer exceção às regras: valor acima da tolerância, documento sem pedido, urgência pedida por mensagem.

As ações de baixo risco, como classificar, lembrar um vencimento, pedir um documento faltante, podem seguir sem aprovação individual, desde que registradas e revisáveis.

O ponto técnico decisivo é onde essa regra mora. Se ela está só no texto de instrução do modelo, ela é uma recomendação. Para ser regra de verdade, precisa estar nas permissões do sistema: o agente usa credenciais que não conseguem liberar pagamento. O guia da OWASP sobre autorização trata disso com o princípio do menor privilégio e a verificação de permissão em cada requisição. Aplicado ao financeiro: a aprovação ocorre no sistema bancário ou no ERP, com o usuário da pessoa, e não por uma resposta de chat.

Um detalhe adicional vale registrar. Quando uma aprovação dispara um pagamento por API, a mesma ordem não pode ser executada duas vezes por falha de rede ou nova tentativa. Provedores de pagamento resolvem isso com chaves de idempotência, como explica a documentação da Stripe sobre requisições idempotentes. Mesmo que seu banco ou ERP use outro mecanismo, a pergunta a fazer ao fornecedor é a mesma: o que impede um pagamento duplicado em caso de repetição?

Cenário ilustrativo: um lote de fornecedores na quinta-feira

Cenário ilustrativo, sem relação com nenhuma empresa real. Uma distribuidora paga fornecedores em lote toda quinta-feira. Na terça, o agente reúne os documentos recebidos, extrai os dados e monta os lançamentos como rascunho. Na quarta, ele roda as conferências: encontra uma nota que parece duplicada de outra já lançada, um boleto cuja conta de destino difere do cadastro do fornecedor e uma fatura sem pedido de compra associado.

Na quinta de manhã, o responsável abre uma tela com três grupos. O primeiro tem os itens conferidos sem ressalva, com o motivo de cada conferência visível. O segundo tem os três alertas, cada um com a evidência lado a lado. O terceiro tem o que ficou sem informação, com a pergunta já redigida ao solicitante. A pessoa aprova o primeiro grupo, contata o fornecedor do boleto divergente por um telefone já cadastrado e devolve a nota duplicada. O pagamento sai pelo banco, com a aprovação dela. O registro guarda o que o agente viu, o que sugeriu e quem decidiu.

Nesse cenário o agente não fez nada que um bom analista não faria. Fez de forma consistente, antes do prazo, e deixou o rastro.

Como implantar sem improvisar?

O método que aplicamos em projetos de IA segue quatro passos: mapear, limitar, pilotar e transferir. No financeiro, eles ficam assim:

• Mapear: descrever o fluxo atual como ele é, com quem recebe o documento, onde lança, quem aprova, quais exceções aparecem e onde o retrabalho acontece. Definir uma linha de base para comparar depois.
• Limitar: decidir quais dados o agente vê, quais ações pode preparar e quais ficam bloqueadas. Dados de pessoas físicas, como sócios e autônomos, pedem atenção à LGPD, e a ANPD é a fonte oficial para acompanhar orientações. Se algum fluxo envolver revisão de decisões automatizadas sobre pessoas, o texto sobre decisões automatizadas e o art. 20 da LGPD ajuda.
• Pilotar: escolher um fluxo real e pequeno, por exemplo a conferência de documentos de um grupo de fornecedores, com registro de cada decisão e uma métrica combinada de antemão. Testar com dados fictícios e ambiente de simulação antes de tocar em dados reais, como descreve o artigo sobre testar agentes de IA com mocks e sandbox.
• Transferir: entregar a operação com documentação, responsáveis e rotina de revisão do registro. Ao fim, decidir com evidência se amplia, ajusta ou encerra.

Um checklist curto para a revisão do piloto:

• O agente consegue, tecnicamente, liberar algum pagamento? A resposta deve ser não.
• Todo alerta tem evidência anexada?
• Há um responsável nomeado para cada tipo de aprovação?
• O registro permite reconstruir uma decisão passada?
• Existe plano para quando o agente errar ou ficar fora do ar, e o processo manual continua funcionando?

Para pensar a arquitetura de forma mais ampla, o texto sobre a camada de superinteligência da empresa em cinco blocos mostra como separar contexto, ferramentas, permissões e supervisão. A gestão de risco de forma geral tem um referencial no NIST AI Risk Management Framework, útil para quem precisa registrar como a empresa identifica e trata riscos de IA.

Perguntas frequentes

Um agente de IA pode pagar boletos sozinho? Tecnicamente pode, se alguém der a ele essa permissão, mas não recomendamos. O desenho mais seguro mantém a liberação do pagamento com uma pessoa com alçada, usando as credenciais dela no banco ou no ERP. O agente entrega o lote conferido e as evidências, e a decisão final permanece humana.

Preciso trocar meu ERP para usar um agente no financeiro? Em geral não. O agente pode trabalhar com o sistema que você já usa, lendo dados e criando rascunhos por integração ou exportação. O que precisa ser verificado é se o sistema permite criar perfis com permissões restritas, porque é isso que sustenta a regra de que o agente nunca libera pagamento.

Qual a diferença entre um agente de IA e uma automação tradicional no financeiro? A automação tradicional segue regras fixas e funciona bem quando o documento é padronizado. O agente lida melhor com variação, como notas em formatos diferentes, e-mails soltos e divergências que pedem interpretação. Na prática, o melhor desenho combina os dois: fluxo determinístico para o que é previsível e IA onde há julgamento, sempre com aprovação humana nas ações de dinheiro.

Como proteger dados de fornecedores e clientes ao usar IA? Comece limitando o que o agente enxerga ao necessário para a tarefa e registrando cada acesso. Verifique onde os dados são processados e se há transferência para fora do Brasil, tema tratado no texto sobre transferência internacional de dados com IA e a LGPD. Defina também quem na empresa responde pelo tratamento e por quanto tempo o registro é guardado.

Fontes

• Anthropic: Building effective agents
• OWASP: Authorization Cheat Sheet
• OWASP: LLM Prompt Injection Prevention Cheat Sheet
• Stripe: Idempotent requests