OCR é um problema resolvido o suficiente. Colocar dados incompletos e com contas que não fecham no único formato que seu ERP aceita não é.
Principais pontos
- O documento é rejeitado depois de ser lido — por um campo obrigatório vazio, um total que não fecha ou um formato fora do padrão, nada disso resolvido por um OCR melhor.
- Existem cinco formas honestas de lidar com documentos "sujos"; cada uma é genuinamente certa para algum fluxo, e uma delas significa mais gente contratada.
- Extração com IA mais RPA serve para alto volume de documentos não uniformes — e é a escolha errada, cara demais, fora desse caso.
- No nosso próprio projeto de varejo, de 13% a 15% dos documentos ainda foram para revisão humana depois de entrar em produção. Isso é normal, não é falha.
- A única forma de saber onde fica a sua linha entre modelo e humano é medir com os seus trinta documentos mais bagunçados.
Uma rede de varejo com quem trabalhamos tinha uma pasta de fornecedor que chegava toda manhã com mais ou menos a mesma cara.
Um arquivo Excel corrompido, que não abria de primeira. Um único PDF com quatro documentos diferentes digitalizados juntos — um romaneio, uma nota fiscal, um certificado de qualidade e uma página que ninguém sabia identificar. Uma planilha impressa numa impressora de escritório cansada, depois assinada à mão, depois fotografada com o celular sob a luz de uma luminária de mesa.
Tudo isso precisava estar lançado no sistema contábil até o fim do dia. Uma pessoa lia, digitava, conferia e apertava salvar.
O sistema recusava.
Um campo obrigatório estava vazio — um código fiscal que o papel nunca trouxe, para começo de conversa. Um documento que um humano já tinha "terminado" voltava direto para a fila.
Não é um problema de leitura
A maioria das ferramentas erra num ponto específico. Elas tratam isso como um problema de reconhecimento, então competem em quão bem leem uma digitalização ruim.
Ler já está bom o suficiente há anos. Um modelo moderno lê uma foto de celular torta quase tão bem quanto um analista cansado. O documento continua sendo rejeitado — e é rejeitado depois que a leitura já terminou.
O sistema que recebe o documento não avalia o quão bem você leu a página.
Ele confere se cada campo obrigatório está presente, se as contas fecham — os totais das linhas contra o total geral, a base de cálculo vezes a alíquota contra o valor do imposto — e se o formato bate com o esquema esperado, caractere por caractere.
Chamo isso de milha zero: colocar o dado sujo exatamente na forma que um receptor rigoroso vai aceitar. Isso acontece depois do reconhecimento, e é aí que mora o custo de verdade.
Uma leitura perfeita da página não garante um registro aceitável, porque o campo que faltava simplesmente nunca esteve na página. A documentação de um dos grandes fornecedores de ERP é direta sobre isso: ligar a nota fiscal eletrônica muda, em nível estrutural, como o sistema guarda e valida os dados da nota — porque os campos que o receptor agora exige podem não ter lugar nenhum no modelo de dados do sistema de origem.
Um receptor rigoroso, por natureza
Um receptor rigoroso é implacável de propósito. No Brasil, uma Nota Fiscal eletrônica (NF-e, modelo 55, para mercadorias) só passa a existir de fato quando a SEFAZ do estado emite a Autorização de Uso. Até ali, a mercadoria não pode circular legalmente — o DANFE que acompanha a carga não vale nada sem o XML autorizado por trás dele.
E essa é uma trava mais dura do que "a nota está errada". É "a venda, legalmente, ainda não aconteceu".
O emissor transmite o XML assinado, e a SEFAZ roda uma bateria de validações: esquema, regras de negócio, certificado digital e assinatura, numeração e duplicidade. Se alguma coisa não fecha, ela devolve uma Rejeição com um código numérico — e o documento nem chega a ficar registrado na base da SEFAZ. Não existe "corrigir no lugar"; você ajusta e reenvia do zero.
Os códigos são familiares para quem lida com isso no dia a dia. O 204 é duplicidade de chave de acesso — já existe uma NF-e autorizada com o mesmo CNPJ, série e número. O 217 é "esse documento não consta na nossa base" — a nota consultada nunca foi registrada. O 236 é dígito verificador inválido na própria chave de acesso de 44 dígitos — um erro de checksum, não de conteúdo. E depois tem o grupo 531 / 535 / 536 / 610, quando a base de cálculo do ICMS, o frete, o seguro ou o total declarado não batem com a soma dos itens da nota. Esse último grupo é o mais parecido com "documento limpo, bem lido, e mesmo assim rejeitado" — a nota está bem formada, só que as contas dela não se sustentam sozinhas.
E mesmo empresas que já automatizaram parte do fluxo ainda tocam à mão cerca de dois terços das suas notas; a taxa média de processamento direto ("straight-through") do setor fica perto de 32% (Ardent Partners, 2024). Uma mesa totalmente manual, por definição, toca em cada uma delas.
Cinco formas honestas de atacar isso
Existem cinco formas reais de atacar esse problema, e cada uma delas é genuinamente a resposta certa em algum contexto. Já entreguei projetos usando mais de uma, então vou dizer onde cada uma quebra também.
1. Contratar pessoas, ou contratar para o pico
Em baixo volume, ou para aquele documento fora do padrão que nenhuma automação vai aprender a ler, uma pessoa é simplesmente a opção mais barata e mais rápida — nada para construir, nada para manter.
Isso quebra em escala e, pior, em picos que se repetem. O custo total do ciclo de processamento de uma nota gira em torno de US$ 9,87, em média (Ardent Partners, 2024), e benchmarks mais antigos, de empresas que ainda operavam quase tudo à mão, apontavam algo entre US$ 18 e US$ 26 (Aberdeen, 2010 — trate como direção, não como preço atual). São custos de ciclo completo, não custo de digitação.
Nos nossos próprios projetos, vi um documento limpo levar poucos minutos e um documento ruim consumir vinte — porque, numa página fotografada, assinada à mão, com números que não fecham, a pessoa não está digitando, está investigando. Multiplique isso por um pico sazonal e você está contratando gente para trabalhar três meses no ano.
2. OCR baseado em template
Quando seus documentos são uniformes e estáveis — mesmo fornecedor, mesmo layout, mês após mês — um template que lê posições fixas é rápido, barato e preciso.
Isso quebra no momento em que o layout muda. É a armadilha mais comum, então merece mais espaço aqui.
A extração por template ancora cada campo numa coordenada ou numa palavra-chave próxima, e uma página fotografada de uma impressora ruim nunca é estável em nível de pixel — então a âncora desliza e o campo volta errado ou vazio. Profissionais no fórum da comunidade de uma grande plataforma de RPA descrevem exatamente isso: algumas centenas de notas por semana, "o formato da nota do fornecedor mudou", e o leitor para de funcionar. Uma biblioteca open source de leitura de notas fiscais, usada junto de um ERP autogerenciado, avisa isso na própria mensagem de erro — o PDF da nota não corresponde a nenhum template conhecido do sistema — falha relatada por usuários há anos, sempre que um documento sai do conjunto previsto.
A rede de varejo com que abri este texto é o motivo pelo qual isso importa. Aqueles fornecedores davam o melhor preço e a qualidade que o negócio realmente queria, então uma certa desorganização no papel era tolerada — e nenhum time de compras no mundo ia conseguir forçar quarenta fornecedores diferentes a usar um único template de nota.
Com OCR de template, a bagunça fica com você.
3. Soluções prontas e específicas do setor
Se a sua entrada já é limpa e já corresponde ao que a solução espera, essas soluções são excelentes — alguém já fez o trabalho de conformidade para você não precisar fazer.
Elas quebram porque partem do princípio de que a entrada é limpa. Uma rede de emissão de nota fiscal eletrônica compatível vai validar seu documento com prazer — e rejeitá-lo com o mesmo prazer — mas não vai consertar o dado de origem que tornou o documento inválido. Os erros recorrentes são todos anteriores: um fornecedor que digita "N/A" num campo obrigatório, uma linha vazia sobrando de uma conversão de PDF, uma referência de comprador faltando. A solução pronta cuida da emissão. A sujeira fica a montante, com você.
4. Integração customizada completa, ou trocar o sistema de origem
Quando você é dono do sistema de origem, e tem tempo e orçamento, uma integração de verdade é a resposta honesta de longo prazo — uma API é um contrato estável, e tudo o que vimos acima é um remendo para quem não tem uma.
Isso quebra nos sistemas que você não controla. Um engenheiro independente experiente resume isso como a primeira pergunta que faz em qualquer projeto de automação: existe uma API? Sistemas legados sem uma API forçam você a operar pela tela, e automação de tela é frágil por natureza.
Isso também quebra do lado dos fornecedores, porque nenhuma integração construída no seu lado consegue obrigar o ERP de um fornecedor externo a emitir um formato válido — e existe um caso bem documentado de um ERP atual, bem mantido, colocando o esquema de identificação errado num campo obrigatório e tendo sua própria saída rejeitada. Então "só modernizar a origem" não é a cura simples que parece. Esses projetos correm em trimestres, às vezes em anos.
5. Extração com IA mais RPA
Essa é a opção que serve para alto volume de sujeira não uniforme — exatamente o caso do varejo. Tem limites reais, e custo é o mais afiado deles — chego lá. Primeiro, como isso funciona de fato.
Como o loop funciona, na prática
O loop tem quatro etapas, e a ordem importa mais do que qualquer modelo individual dentro dele.
Um modelo de visão computacional lê o documento — qualquer layout, fotografado ou não — e retorna os campos junto com uma nota de confiança para cada um. Não uma nota única para a página inteira: uma por campo, porque um documento pode estar 95% legível no geral enquanto o CNPJ fica abaixo do limite aceitável e precisa de um olho humano.
Depois, uma segunda camada — código determinístico puro, não o modelo — reconfere as contas. Ela recalcula cada linha como quantidade vezes preço, soma as linhas contra o subtotal, aplica a alíquota declarada para verificar o imposto, e confirma o total geral, com uma tolerância de centavos de arredondamento para não disparar alarme falso.
Isso precisa ser código separado, porque um LLM prevendo um número está amostrando de texto que já viu, não calculando — pedir para o mesmo modelo checar a própria aritmética só adiciona um segundo palpite. A confiança flui da camada determinística para o modelo, nunca no sentido contrário.
O ponto de tudo isso é o "não tenho certeza" honesto.
Um modelo de visão, quando não consegue ler um valor, tende a inventar um que combine com o resto do documento e entregar com confiança total — e um valor errado entregue com confiança total, que entra direto no razão contábil, é bem mais perigoso do que um campo sinalizado para revisão humana. Por isso um campo duvidoso nunca segue silenciosamente para o receptor. Ele vai para uma estação de revisão, onde uma pessoa resolve.
A checagem determinística só pega números que se contradizem entre si; ela não pega um valor errado que seja internamente consistente — e é por isso que o humano continua no loop, e por isso "100% sem intervenção" é slide de vendas, não realidade operacional.
Construímos esse loop com o Primo AI Server para a extração e a confiança por campo, com o Primo RPA fechando as duas pontas — puxando dado de um sistema legado pela tela, quando não existe API para chamar, e digitando o registro final no receptor do jeito que uma pessoa digitaria. As mesmas duas peças cobrem o caminho inteiro, da pasta de digitalizações ruins até o registro que o sistema rigoroso aceita.
No nosso projeto de varejo, depois de entrar em produção, de 13% a 15% dos documentos foram para revisão humana — não 1%, e não zero. Um benchmark independente do setor de contas a pagar aponta uma taxa de exceção de 18,4% (Ardent Partners), então esse número é normal, não é falha. O piloto levou dois meses e foi direto para produção. A empresa evitou contratar quatro pessoas só para essa pasta.
Como escolher, e quando não usar IA
Eu vendo esse loop, então preste atenção na parte seguinte: em muitos fluxos, você não deveria comprá-lo.
IA no loop significa GPU, e uma GPU rodando a 10% de utilização custa cerca de dez vezes mais por unidade de trabalho do que uma mantida ocupada — e a entrada de documentos, com seus picos e semanas paradas, quase nunca mantém uma GPU ocupada.
Abaixo de mil a dez mil documentos por mês, num layout uniforme, OCR de template ou até uma pessoa ganha de longe, porque nesse volume o custo real é construir e monitorar o pipeline, bem acima do custo da própria leitura.
Hospedar seu próprio modelo só começa a compensar por volta de 50 mil a 100 mil páginas por mês de volume constante — e só se você já tiver um engenheiro de ML dedicado, ou pelo menos com um quarto do tempo alocado. E em um detalhamento de engenharia real, a fila de revisão humana sozinha respondia por US$ 0,75 de um custo de US$ 1,20 por documento — mais do que o OCR e a camada de IA somados.
Então, as quatro coisas que vale a pena medir antes de gastar qualquer coisa: quanto volume você realmente tem, quão uniformes são os documentos, se o sistema de origem tem API, e quão apertado é o prazo.
Conte primeiro. Se os números apontam para OCR de template, o fornecedor honesto te manda comprar OCR de template.
A linha que só você pode traçar
Onde o modelo para e o humano começa é uma linha real, e ela é diferente para cada fluxo de documentos.
Não consigo te dizer, a partir de um slide, se o seu caso vai ficar em 5% de revisão ou em 25% — e não confiaria em ninguém que dissesse que consegue.
A única forma que conheço de descobrir é pegar os seus próprios trinta documentos mais bagunçados — o Excel corrompido, a assinatura fotografada, a página com quatro digitalizações empilhadas — rodar pelo loop, e ver quantos a máquina devolve.
Traga-nos os seus trinta documentos mais problemáticos
É exatamente assim que começamos um piloto. Mande o pior do que seus fornecedores e sistemas produzem, e nós rodamos tudo pelo loop com Primo AI Server e Primo RPA, mostrando a confiança por campo, as exceções e a taxa de revisão honesta — antes de você se comprometer com qualquer coisa. Você vai ver o seu próprio número, não o nosso.
Solicitar um piloto / agendar demonstração →
Alexey Nikolaev trabalha na Primo RPA, onde o time constrói sistemas de automação de documentos e RPA para operações financeiras e de back office. A Primo RPA desenvolve o Primo AI Server e a plataforma Primo RPA.