Uma fatura pode chegar com sucesso na caixa de correio de contas a pagar e ainda assim se transformar em horas de trabalho manual. Alguém deve identificar o fornecedor, encontrar o pedido de compra, verificar o que foi recebido, revisar preços e impostos, detectar duplicidades e decidir quem resolve cada diferença. Quando as evidências ficam em bandejas, arquivos e módulos separados, o pagamento é atrasado ou adiantado com verificações incompletas.
Este artigo se concentra em um caso de uso específico: uso de agentes de IA para verificar faturas de fornecedores em relação ao pedido de compra e recebimento registrado no ERP. A IA captura e organiza dados, executa comparações permitidas e prepara exceções; As políticas do ERP e pessoas autorizadas mantêm a aprovação contábil e a liberação de pagamentos.
O que é verificação de fatura AI
É um fluxo de contas a pagar que recebe uma fatura, extrai seus campos e linhas, encontra os documentos operacionais relacionados e compara as informações antes de enviá-las para lançamento ou aprovação. A IA ajuda especialmente quando o documento não chega em um formato uniforme ou quando a exceção precisa de contexto de múltiplas fontes.
O objetivo não é que um modelo decida se uma fatura “parece correta”. O objetivo é produzir uma verificação reprodutível: qual fatura foi recebida, a que pedido e recebimento ela se refere, quais regras foram aplicadas, quais diferenças apareceram e quem deve agir.
O que significa fazer correspondência de duas ou três vias?
A comparação depende dos documentos disponíveis e da política de compras:
- Conciliação bidirecional: compara a fatura com o pedido de compra. Serve para validar fornecedor, moeda, conceitos, quantidades, preços e condições autorizadas.
- Correspondência tripla: adiciona recebimento de mercadoria ou confirmação de serviço. Isso evita a aprovação apenas porque algo foi pedido e ainda não há comprovante de entrega.
- Fatura sem pedido de compra: requer roteiro diferenciado, com centro de custo definido, contrato, responsável e aprovação. Não deve ser forçado a uma partida inexistente.
O Microsoft Learn documenta que as faturas do fornecedor podem ser relacionadas às linhas de recebimento, mesmo quando há entregas parciais. Ele também descreve processos que fazem a correspondência automática de recebimentos com linhas sujeitas a uma política tripartida e exibem status como concluído, em espera ou com falha. A lição operacional é clara: uma exceção deve ter estado e razão, e não estar escondida em uma correspondência difusa.
##Por que o processo manual trava
As faturas nem sempre chegam na mesma ordem ou com os mesmos identificadores que o ERP espera:
- O número do pedido aparece incompleto, em outra página ou em formato diferente.
- Uma fatura reúne vários recebimentos parciais.
- O fornecedor fatura um valor diferente do recebido.
- O preço unitário, desconto, frete ou imposto não coincidem.
- A recepção existe, mas ainda não foi cadastrada no sistema.
- O mesmo documento chega por correio e por portal.
- Uma alteração autorizada no pedido não é refletida em todos os sistemas.
- Uma fatura de serviço requer a confirmação do responsável e não uma entrada no armazém.
Sem um arquivo comum, o contas a pagar pede a compra, a compra pede a transação e o fornecedor envia o documento novamente. Cada reenvio aumenta o risco de duplicação, enquanto a equipe perde visibilidade sobre quem tem a próxima ação.
Fluxo passo a passo recomendado
1. Receba a fatura em uma entrada controlada
O documento pode entrar por meio de uma caixa de entrada de contas a pagar, portal de fornecedores, integração de faturamento eletrônico ou API. O stream mantém o arquivo original, canal, data, remetente e um identificador exclusivo. Ele também verifica anexos e evita que um thread encaminhado crie novos casos sem validação.
Antes de extrair informações, você deve verificar o tipo de arquivo, aplicar controles de segurança e separar mensagens suspeitas. Uma fatura não deve se tornar automaticamente uma instrução para o agente: o conteúdo do documento são dados a serem verificados e não um pedido com privilégios sobre o ERP.
2. Extraia campos e preserve evidências
O agente pode propor fornecedor, número da fatura, data, moeda, subtotal, impostos, total, pedido de compra e linhas. Cada valor deve manter referência à página ou região do documento de onde veio. Se os dados forem ilegíveis, contraditórios ou de baixa confiança, serão sinalizados para revisão em vez de inventados.
A captura deve normalizar os formatos sem alterar o valor original. Por exemplo, você pode padronizar datas ou separadores decimais para comparação, mas preservar a representação recebida para auditoria.
3. Resolver o relacionamento com fornecedor e pedido
O número escrito na fatura é um sinal, nem sempre uma chave suficiente. O fluxo contrasta fornecedor, pessoa jurídica, moeda, pedido em aberto, centro de custo e linhas. Se houver duas ordens plausíveis ou o provedor não corresponder ao mestre autorizado, ele não escolhe silenciosamente: cria uma exceção explicável.
Também é uma boa ideia verificar o status do provedor e as alterações recentes nos dados confidenciais. Uma atualização de conta bancária, por exemplo, requer um processo de validação separado e não deve ser aprovada porque apareceu numa fatura.
4. Compare fatura, pedido e recebimento por linha
A correspondência útil ocorre no nível da linha, não apenas no total. Para cada item, o fluxo compara SKU ou serviço, descrição, unidade, quantidade pedida, quantidade recebida, quantidade faturada anteriormente, preço, desconto, impostos e encargos autorizados.
Entregas parciais exigem saldo acumulado. Se 100 unidades foram encomendadas, 60 foram recebidas e 40 já foram faturadas, uma nova fatura de 20 poderá ser consistente; um em cada 60 exige a revisão do histórico para não exceder o que foi recebido. O mesmo princípio se aplica a marcos de serviços e consumo contratual.
5. Aplicar tolerâncias explícitas
Nem toda diferença representa um erro. As empresas podem aceitar pequenas variações devido a arredondamentos, peso, taxa de câmbio ou cobranças pré-autorizadas. A Oracle documenta tolerâncias percentuais e de valor entre fatura, pedido, recebimento e impostos, e o uso de retenção na fonte quando a variação excede o limite.
As tolerâncias devem ser versionadas por entidade, categoria, fornecedor ou tipo de compra, com limite claro. O agente não deve ampliar a margem para conseguir uma correspondência ou tratar uma média histórica como compensação.
6. Detecte possíveis duplicatas
Procurar apenas pelo mesmo nome de arquivo é insuficiente. A detecção pode combinar fornecedor, número da fatura, entidade, moeda, valor, data e referência. A SAP documenta verificações duplicadas com base em atributos configuráveis e na geração de avisos ou erros quando existe uma possível correspondência.
Um alerta duplicado também não equivale a fraude nem autoriza a exclusão de um registro. A equipe deve ser capaz de comparar documentos, ver cancelamentos ou notas de crédito e decidir se é uma reenvio, uma correção válida ou um documento repetido.
7. Exceções de rota com contexto
Toda diferença precisa de um dono de acordo com a sua causa. O recibo em falta pode ir para o requerente ou para o armazém; um preço fora da tolerância, às compras; um imposto inconsistente sobre as finanças; um fornecedor não reconhecido, para dados mestre ou conformidade.
O caso deve incluir fatura original, documentos relacionados, linhas afetadas, regra aplicada, diferença calculada, responsável, prazo e ação esperada. Assim a pessoa resolve a exceção sem reconstruir o arquivo inteiro.
8. Registre a decisão e sincronize o ERP
Quando uma pessoa corrige, aprova ou rejeita, o resultado retorna ao caso e ao ERP com usuário, data, motivo e versão dos documentos. As novas tentativas devem ser idempotentes: uma integração repetida não pode lançar duas vezes a fatura ou duplicar uma tarefa de aprovação.
A contabilidade e o pagamento permanecem atrás de licenças e segregação de funções. O agente pode preparar ou enviar uma transação permitida para o fluxo de trabalho, mas não deve ignorar uma retenção ou usar as credenciais de uma pessoa com mais privilégios.
Fatura padrão vs. exceção
| Situação | Possível automação | Controle necessário |
|---|---|---|
| Correspondência completa dentro da tolerância | Preparar e enviar para fluxo de trabalho definido | Validações e rastreabilidade de ERP |
| Recepção parcial | Comparar com o saldo recebido e faturado | Não exceda o valor acumulado |
| Preço fora da tolerância | Criar exceção para compras | Aprovação de alteração ou correção |
| Possível duplicado | Bloqueie o progresso e mostre as partidas | Revise antes de postar |
| Factura sem encomenda | Aplicar rota específica não PO | Responsável, centro de custo e aprovação |
| Alteração de conta bancária | Separado do fluxo de faturas | Verificação independente de fornecedor |
| Dados ilegíveis ou ambíguos | Solicitar correção ou revisão | Não preencha os campos inventados |
O que o agente pode fazer e o que uma pessoa retém
| Agente pode apoiar | Requer sistema ou pessoa autorizada |
|---|---|
| Capturar campos e linhas com evidências | Confirmar dados ambíguos |
| Pesquisar pedido, recebimento e contrato | Crie um pedido retroativo |
| Calcular diferenças e aplicar regras atuais | Alterar tolerâncias ou política |
| Detectar possíveis correspondências duplicadas | Denunciar fraude ou excluir documentos |
| Preparar e atribuir uma exceção | Aprovar uma diferença material |
| Atualizar estados permitidos | Lançar ou liberar o pagamento fora do fluxo de trabalho |
O AI RMF do NIST propõe governar, mapear, medir e gerenciar os riscos dos sistemas de IA durante o seu ciclo de vida. Nas contas a pagar, isto se traduz em testar vários documentos e fornecedores, medir erros de extração e correspondência, limitar permissões, reter evidências, monitorar alterações e manter a revisão humana onde uma decisão pode resultar em um pagamento incorreto ou no bloqueio injusto de um fornecedor.
##Integrações mínimas
- Caixa de entrada ou portal onde as faturas são recebidas.
- ERP ou sistema de contabilidade de fornecedores, pedidos, recebimentos, impostos e estados.
- Repositório de documentos para preservar originais e versões.
- Workflow de aprovação com gestores, substituições e limites.
- Sistema de compras ou contratos quando o pedido não contém todo o contexto.
- Webhooks ou APIs com autenticação, idempotência e permissões mínimas.
- CRM ou inbox omnicanal quando a comunicação com o fornecedor deve ser relacionada ao case.
Nem sempre é necessário substituir o ERP. Seelai pode atuar como uma camada operacional que recebe eventos, prepara verificações e coordena exceções, enquanto o sistema financeiro mantém os registros e controles contábeis que já estão funcionando.
Métricas para avaliar um piloto
Comece com uma entidade, um grupo de fornecedores e faturas com um pedido de compra. Compare com uma linha de base e meça:
- Tempo desde o recebimento até a primeira verificação.
- Porcentagem de campos e linhas extraídas sem correção.
- Faturas com correspondência completa de duas ou três vias.
- Corrija exceções e falsos positivos por tipo.
- Duplicatas detectadas antes de postar ou pagar.
- Tempo de resolução de compras, operações e finanças.
- Facturas devolvidas por falta de provas ou dados.
- Correções pós-contábeis.
- Descontos para pagamento antecipado aproveitados sem aumento de erros.
- Ações sem rastreabilidade ou tentativas bloqueadas por permissões.
O objetivo não deve ser maximizar a taxa de processamento sem contato humano. Uma fatura verdadeiramente automatizável é aquela que passa por controles definidos com evidências suficientes. Os demais deverão chegar à pessoa certa com mais rapidez e melhor explicação.
Como começar sem automatizar todas as contas a pagar
Selecione um fluxo estável: faturas com pedido, fornecedores recorrentes e recebimentos registrados. Documente as tolerâncias atuais e confirme quem resolve cada exceção. Em seguida, testa casos normais e adversos: entrega parcial, número de pedido incorreto, fatura duplicada, nota de crédito, câmbio, linha adicional, imposto inesperado, arquivo ilegível, fornecedor inativo, integração inativa e nova tentativa do mesmo evento.
Expanda o escopo somente quando a equipe puder reconstruir por que cada fatura foi adiantada, retida ou escalada. Faturas sem pedido, contratos complexos e alterações bancárias podem ser incorporadas posteriormente utilizando seu próprio roteamento e controles.
Perguntas frequentes
A IA substitui a correspondência de ERP?
Não necessariamente. O ERP pode manter a política, tolerâncias, fluxo de trabalho e contabilidade. O agente ajuda a transformar documentos, localizar relacionamentos e preparar exceções para que a correspondência existente receba dados mais completos.
Uma fatura correspondente pode ser paga automaticamente?
A correspondência é uma condição de controle e não uma autorização universal de pagamento. A empresa deve manter suas aprovações, segregação de funções, retenções, validações contábeis e cronograma de pagamentos.
O que acontece com faturas sem pedido de compra?
Eles devem usar um fluxo específico. A IA pode classificar a despesa, buscar contrato ou responsável e obter apoio, mas não deve inventar uma ordem para enviar a fatura através de um controle que não cumpriu.
Como evitar que o agente preencha dados incorretos?
Com extração vinculada a evidências, limites de confiança, validações com base em dados mestre e regra de abstenção. Caso haja dois valores plausíveis ou falta de suporte, o sistema solicita revisão em vez de escolher por conveniência.
Onde Seelai se encaixa
Seelai conecta agentes de IA, automações, caixa de entrada omnicanal e software operacional para transformar uma fatura em um arquivo verificável. O agente captura e relaciona informações; O ERP disponibiliza ordens, recepções, regras e status; o fluxo de trabalho retém aprovações; e as exceções chegam à equipe com evidências e a próxima ação.
O resultado esperado é não pagar mais rápido a qualquer custo. É reduzir a digitação e a busca manual, detectar diferenças antes de postar e permitir que o contas a pagar se concentre em exceções reais sem perder o controle financeiro.
Fontes
- Microsoft Learn, visão geral das faturas do fornecedor: https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/vendor-invoices-overview
- Microsoft Learn, visão geral dos processos automatizados de faturamento de fornecedores: https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/auto-vendr-invc-process
- Microsoft Learn, registre a fatura do fornecedor e compare com a quantidade recebida: https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/tasks/record-vendor-invoice-match-against-received-quantity
- Ajuda do Oracle Payables, tolerâncias de fatura: https://docs.oracle.com/cd/A60725_05/html/comnls/us/ap/toleranc.htm
- Portal de ajuda SAP, verifique se há duplicação de entrada de fatura: https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ed84b70c199d4470ae2e5ccb93b2e45b/a971b6531de6b64ce10000000a174cb4.html
- NIST, Estrutura de Gerenciamento de Risco de Inteligência Artificial (AI RMF 1.0): https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10
Se sua equipe ainda compara faturas, pedidos e recebimentos entre e-mails, planilhas e telas de ERP, agende uma demonstração Seelai em /demo. Analisaremos um tipo de fatura, seus documentos de origem, tolerâncias, responsáveis e integrações para projetar um piloto de verificação com IA em sua operação real.