Automatização do processamento de faturas: a parte difícil não é ler a fatura

Toda equipe de contas a pagar tem o mesmo tipo de problema. As faturas chegam em todos os formatos que um fornecedor consegue inventar — PDFs, digitalizações, fotos de papel, e-mails com o valor no corpo — e alguém as digita no sistema, confere com um pedido de compra, acompanha as que não batem e obtém as aprovações. Digitar é tedioso. A conferência é onde o dinheiro se perde: duplicatas, impostos incorretos, condições que ninguém leu ou um fornecedor cujos dados bancários mudaram no mês passado.

Por isso, quando uma empresa diz que quer “automatizar faturas”, normalmente se refere à digitação. A parte que vale a pena automatizar é a conferência.

A leitura está suficientemente resolvida

Modelos de documentos que reconhecem o layout já conseguem ler uma fatura que nunca viram e devolver campos estruturados: fornecedor, datas, itens, impostos, totais e condições de pagamento. Eles lidam com os formatos desorganizados que antes venciam o OCR baseado em templates, e os analisadores de código aberto são bons o suficiente para que o modelo raramente seja a limitação.

Essa é a metade fácil. Uma extração correta em 95% dos casos ainda deixa uma em cada vinte faturas com erro — e nenhuma maneira de saber qual.

O sistema que realmente traz retorno

O projeto útil tem quatro partes, e só a primeira trata de leitura.

1. Extraia e depois valide com seus próprios dados. Um campo não é “correto” porque o modelo está confiante; ele é correto porque corresponde a algo que você já sabe. O pedido de compra existe e está aberto? O fornecedor corresponde ao cadastro mestre, incluindo os dados bancários? Esse número de fatura já apareceu antes? A soma dos itens corresponde ao total? A validação transforma a extração em evidência.

2. Encaminhe pela confiança, não por uma regra. Cada fatura recebe uma pontuação que combina a extração e a validação, e essa pontuação decide quem a vê:

• Confiança alta, tudo corresponde: segue diretamente para aprovação e registro contábil. Nenhuma pessoa intervém.
• Média: um campo não corresponde ou o modelo não tinha certeza. Um revisor vê o documento e os campos extraídos lado a lado e corrige um dado com um clique.
• Baixa ou anômala: fornecedor novo, dados bancários alterados ou um valor muito fora da faixa habitual. Revisão completa, por projeto.

O objetivo não é eliminar toda revisão. É reservar a revisão para o que exige julgamento.

3. Torne a revisão rápida e faça com que ela ensine. A tela de revisão é o produto que a equipe financeira realmente usa, então merece ser boa: original de um lado, campos do outro, correções com um clique e um botão “aprovar” claro. Cada correção é registrada e incorporada como feedback — um layout incomum de um fornecedor, um erro de leitura recorrente — para que o mesmo erro não aconteça duas vezes. A fila diminui a cada mês, e essa redução é a métrica.

4. Gere ações, não uma planilha. Uma fatura processada deve sair do sistema como ações concretas: um lançamento contábil com a classificação correta, um pagamento agendado dentro das condições acordadas, um status que o fornecedor possa consultar e uma rubrica orçamentária atualizada. Se o resultado é um CSV que alguém redigita, a automação transferiu a digitação em vez de eliminá-la.

O que falha, para você se preparar

Notas de crédito que parecem faturas. Várias moedas e arredondamentos. Anotações à mão em páginas digitalizadas. Fornecedores que enviam a mesma fatura duas vezes, ligeiramente diferente a cada vez. Dados bancários de um fornecedor “atualizados” por e-mail — essa é a exceção que sempre precisa chegar a uma pessoa, porque é assim que funciona a fraude com faturas.

Nenhum desses casos é motivo para não automatizar. Eles são a lista do que as regras de encaminhamento precisam detectar desde o primeiro dia.

O que medir

Taxa de processamento sem intervenção: a proporção de faturas que nenhuma pessoa tocou. Taxa de exceções e quais foram essas exceções. Dias entre o recebimento e a aprovação. Duplicatas e divergências detectadas antes do pagamento. As três primeiras métricas devem mudar no primeiro mês; a quarta é a que o diretor financeiro vai perguntar.

Se as faturas são um dos vários processos em que você suspeita que a IA deveria fazer mais, a pergunta real é qual construir primeiro e o que seus dados permitem — e vale a pena respondê-la antes que alguém escreva uma linha de código.

O que aprendemos ao criar o protótipo

Construímos isso como uma prova de conceito, não para um cliente: um painel de OCR com a fatura original de um lado e os campos extraídos do outro — número da fatura, datas, vendedor e comprador com seus identificadores fiscais, itens e totais —, além de uma contagem de processadas e pendentes e do JSON bruto a um clique. A captura de tela mostra a extração; a validação e o encaminhamento descritos acima são o projeto que um sistema de produção precisa ter sobre essa base, e não fizeram parte do protótipo.

Duas coisas funcionaram com faturas reais. A tela com documento e campos lado a lado importou mais que o modelo: os revisores conferem a extração com o documento, não de forma abstrata, e essa é a interface que uma equipe financeira realmente vai usar. Além disso, a extração sozinha, por melhor que seja, deixa a conferência por fazer — esse é o argumento de todo este artigo. O protótipo comprovou a leitura; a conferência é o produto.