São nove e meia de uma segunda-feira e a caixa de correio partilhada da contabilidade tem cento e quarenta mensagens novas. Há faturas de fornecedores habituais, algumas digitalizadas de lado, um PDF com três faturas e uma guia de remessa coladas no mesmo ficheiro, uma segunda via de uma fatura que já foi lançada na semana passada e um aviso de pagamento que parece uma fatura mas não é. Na caixa comercial, ao lado, estão as notas de encomenda dos clientes: umas em PDF gerado pelo ERP deles, outras em Excel, e uma escrita no corpo do email com a frase "repetir a encomenda de março, tirando o que estava esgotado".
Alguém vai passar o dia a abrir isto tudo, a copiar valores para o ERP e a confirmar que o preço bate com a encomenda. A maior parte do trabalho é mecânica. Uma parte pequena, e é essa que custa dinheiro quando falha, exige atenção: o fornecedor que mudou de IBAN, o preço unitário que subiu sem aviso, a quantidade faturada que não corresponde à que entrou no armazém.
Este artigo é sobre como pôr inteligência artificial a fazer a parte mecânica e a apontar a parte que exige atenção, sem criar um sistema que lança erros no ERP com toda a confiança.
Resposta curta
A IA lê faturas de fornecedores, notas de encomenda e guias em PDF, mesmo em formatos que nunca viu, mas a leitura é a parte fácil. O que evita erros silenciosos no ERP são as verificações à volta: o NIF existe e bate com a ficha, a soma das linhas dá o total, o preço corresponde à encomenda e o documento não é um duplicado. O que não passa vai para uma fila de exceções, e no início os documentos entram no ERP como rascunho. Um primeiro processo em produção situa-se tipicamente entre 7.500€ e 15.000€.
Ler é fácil, validar é o projeto
Há cinco anos, o problema difícil era ler. O OCR transformava a imagem em texto, mas para saber que aquele número no canto superior direito era o total era preciso configurar um modelo por fornecedor, que deixava de servir quando o fornecedor mudava de software de faturação.
Os modelos de linguagem mudaram isto. Leem um documento que nunca viram, percebem que "Valor a pagar", "Total EUR" e "Montante" são o mesmo campo e lidam com tabelas partidas entre páginas e digitalizações fracas. A leitura passou a ser a parte barata e previsível.
O risco também mudou. O OCR antigo falhava de forma visível, com campos em branco. Um modelo de linguagem, quando se engana, devolve um valor plausível, bem formatado e errado.
Por isso, o trabalho de engenharia está quase todo depois da leitura: verificar o que foi lido contra o que a empresa já sabe, decidir o que segue sozinho e o que passa por uma pessoa, e deixar registo de tudo.
Quando o volume já justifica um projeto
Os sinais mais fiáveis de que o problema tem dimensão para um projeto:
- a empresa recebe centenas ou milhares de documentos por mês, de dezenas ou centenas de emissores diferentes;
- há pessoas cuja função é, na prática, copiar dados de PDFs para o ERP;
- o fecho do mês atrasa porque há faturas por lançar ou por conferir;
- a empresa já pagou uma fatura em duplicado, ou pagou um preço diferente do acordado, e só deu por isso mais tarde;
- as encomendas de clientes ficam à espera de serem introduzidas e o prazo de entrega começa a contar com horas de atraso;
- a conferência entre encomenda, receção e fatura é feita por amostragem, porque não há tempo para a fazer a todas;
- o volume cresce e a resposta tem sido contratar mais uma pessoa para a mesma tarefa.
Se três ou quatro destes pontos são reconhecíveis, há quase sempre um caso de negócio.
OCR, IA e fatura estruturada: o que cada um resolve
| OCR com modelos fixos | Extração com modelos de linguagem | Fatura eletrónica estruturada | |
|---|---|---|---|
| Layouts novos | Exige configurar cada um | Lê sem configuração prévia | Não se aplica, os dados vêm em campos |
| Tipo de erro | Campos em branco, visíveis | Valores plausíveis e errados | Raros, vêm do emissor |
| Encomendas, guias, declarações | Fraco | Bom | Só se o emissor enviar em formato estruturado |
| Validação contra o ERP | Tem de ser construída | Tem de ser construída | Tem de ser construída |
A última linha é a que mais se esquece: mesmo um XML perfeito não confirma que o preço é o acordado nem que a mercadoria entrou.
As verificações que tornam isto fiável
É aqui que se separa uma demonstração de algo que aguenta um fecho de mês.
Identidade do emissor
Primeiro, o NIF. Um NIF português tem dígito de controlo, por isso uma leitura com um algarismo trocado é apanhada sem consultar nada. Depois, o NIF tem de existir na base de fornecedores do ERP. Se não existir, o documento não segue: ou é um fornecedor novo, que precisa de ficha criada por alguém com autoridade para isso, ou é um engano.
O IBAN merece atenção própria. Um IBAN diferente do que está na ficha do fornecedor é um padrão clássico de fraude por email, em que alguém se faz passar pelo fornecedor. Este caso vai sempre para uma pessoa, com o alerta bem visível.
Coerência interna do documento
A soma das linhas tem de dar o subtotal, a base mais o IVA tem de dar o total, e as taxas de IVA têm de fazer sentido para o tipo de produto e para a região. Nas faturas emitidas em Portugal há uma ajuda que pouca gente aproveita: o código QR obrigatório traz, em formato estruturado, o NIF do emitente e do adquirente, a data, o número do documento, o ATCUD e os totais de base e de IVA por taxa. Ler o QR e comparar com o que o modelo extraiu do texto é uma verificação dupla quase gratuita. O QR não traz as linhas nem a referência da encomenda, e não existe em faturas de fornecedores estrangeiros, por isso não dispensa a extração, mas apanha muitos erros nos totais.
Duplicados
Uma segunda via, um reenvio do mesmo PDF ou a mesma fatura enviada para dois endereços diferentes são casos comuns. A verificação óbvia é o par NIF e número de documento. A menos óbvia é o mesmo valor, do mesmo fornecedor, em datas próximas e com números diferentes, que pode ser legítimo ou não e deve ir para revisão.
Conferência com encomenda e receção
Para faturas de compra, a verificação que mais valor tem é a conferência a três: a encomenda que a empresa fez, o que entrou no armazém e o que está a ser faturado. É aqui que aparecem os problemas reais: o fornecedor fatura à caixa e a encomenda foi feita à unidade, a entrega foi parcial mas a fatura é do total, o preço subiu meio ponto, os portes não estavam previstos. Cada empresa tem as suas tolerâncias, e definir quais são é uma conversa de gestão que fazemos logo no início.
Com um portal onde os fornecedores faturam contra a encomenda, parte desta conferência acontece antes de o documento chegar. Para quem continua a enviar PDF por email, a lógica é a mesma, aplicada depois.
Encomendas de clientes: o outro lado
Nas notas de encomenda o desafio é outro. O cliente usa os códigos dele, por isso é preciso uma tabela de correspondência que o sistema alimenta com cada confirmação. Caixas e unidades têm de ser convertidas, "na próxima semana" tem de passar a uma data concreta, e a alteração que chega por resposta ao email tem de ser ligada à encomenda original. É aqui que os modelos de linguagem mais se distanciam do OCR, porque metade destas encomendas nem tem layout.
Confiança e fila de exceções
Um modelo de linguagem consegue indicar o quão seguro está de uma leitura, mas pode estar muito seguro de um valor errado. Por isso, a confiança que usamos para encaminhar é sobretudo a que resulta das verificações: um documento em que o NIF bate, o QR confirma os totais e a encomenda corresponde tem uma confiança medida, que nenhum modelo consegue declarar sobre si próprio.
O que não passa vai para uma fila de exceções. A qualidade desse ecrã decide se o projeto é adotado ou contornado. Tem de mostrar o PDF ao lado dos campos lidos, com a zona do documento de onde veio cada valor, e dizer porque é que o documento parou: "preço unitário 4,2% acima da encomenda", não "erro de validação". Cada correção feita ali fica registada e serve de exemplo para os documentos seguintes do mesmo emissor.
O objetivo não é eliminar a fila, é que a equipa use o tempo nos casos que precisam de critério.
Lançamento no ERP e auditoria
O documento validado tem de chegar ao ERP. Primavera, PHC, SAP e Sage têm formas de integração documentadas, mas o que está disponível varia com a versão, o licenciamento e o parceiro que gere a instalação: umas vezes há uma ligação pronta, outras um módulo de importação. Descrevemos estas opções no artigo sobre integrar IA no software que a empresa já usa.
No início, os documentos entram como rascunho ou pendentes de aprovação. A passagem a lançamento direto faz-se fornecedor a fornecedor, quando o histórico mostra semanas de leituras sem correções.
Para auditoria, cada documento guarda o original, os valores extraídos, as verificações que passaram e falharam, quem aprovou e a versão do modelo e das regras. Quando o revisor oficial de contas pergunta porque é que uma fatura foi paga, a resposta está num ecrã e não na memória de alguém.
A fatura eletrónica vai resolver isto sozinha?
Em parte, e mais devagar do que se esperava. Em Portugal, as faturas em PDF continuam a ser aceites como faturas eletrónicas para efeitos fiscais, e esse prazo tem sido prorrogado sucessivamente; a proposta de Orçamento do Estado para 2027, ainda em discussão, prevê nova prorrogação até ao fim desse ano. Na contratação pública, a fatura eletrónica estruturada já é exigida às grandes empresas, mas a obrigação para as PME tem sido adiada ano após ano. Ao nível europeu, o pacote ViDA, aprovado em 2025, prevê fatura eletrónica estruturada nas operações B2B intracomunitárias a partir de 2030. A tendência é clara, mas o calendário para as operações nacionais entre empresas continua em aberto, e convém confirmar o estado de cada obrigação com o contabilista certificado.
Na prática, quando um fornecedor enviar XML estruturado, o sistema importa-o e salta a extração, mas as verificações e a fila de exceções mantêm-se. Um projeto bem desenhado hoje não fica obsoleto com a fatura estruturada. Fica mais barato de operar.
Uma nota sobre dados pessoais: faturas de empresários em nome individual, declarações e guias com nomes e moradas são dados pessoais ao abrigo do RGPD. Por isso, por defeito, usamos modelos com processamento na União Europeia, contrato de subcontratação e garantia de que os dados não servem para treino. Desenvolvemos o tema no artigo sobre RGPD e AI Act antes de pôr IA em produção.
Como fazemos
1. Diagnóstico gratuito, depois documentos reais
Uma conversa de 30 minutos, gratuita, sobre os documentos que chegam, os volumes e o ERP. Se houver caso, o levantamento começa por uma amostra de algumas centenas de documentos reais, para ver a distribuição: que tipos, quantos emissores, quantos formatos, quantos chegam digitalizados. Vemos também como se chega ao ERP. No fim, a empresa sabe se o caso compensa e por onde começar, sem obrigação de avançar.
2. Um tipo de documento, em paralelo
Começamos por um só tipo, normalmente faturas de fornecedores. Durante algumas semanas o sistema processa em paralelo com a equipa, que trabalha como sempre, e afinamos as verificações sem risco para a operação.
3. Fila de exceções e lançamento em rascunho
A equipa passa a trabalhar a partir da fila e os documentos validados entram no ERP para aprovação. Aqui mede-se quanto passa sem intervenção e quanto tempo se poupa por documento.
4. Autonomia progressiva e novos tipos
Com histórico, os fornecedores mais regulares passam a lançamento direto, e acrescentam-se encomendas de clientes ou guias sobre a mesma base.
Quanto custa e quanto demora
Um primeiro processo em produção, por exemplo faturas de fornecedores com validação e lançamento num ERP, situa-se tipicamente entre 7.500€ e 15.000€, com seis a dez semanas até produção. Quando o projeto abrange vários tipos de documento ligados entre si, como encomendas de clientes, faturas de compra e conferência com o armazém, o investimento sobe para 15.000€ a 35.000€.
Neste tipo de projeto, o que mexe no valor é sobretudo o que está nos documentos: quantos tipos diferentes entram no âmbito, que parte chega digitalizada ou escrita no corpo do email, e quantas exceções às regras de conferência a empresa tem, como fornecedores com acordos de preço próprios ou tolerâncias diferentes por família de produto. A ligação ao ERP pesa também, como explicamos no artigo sobre quanto custa implementar IA numa empresa. O que faz descer é começar estreito: um tipo de documento, um ERP, regras claras.
Cada vez mais empresas chegam com um protótipo feito no ChatGPT, no Claude ou no Gemini que já lê algumas faturas. Isso ajuda: mostra que documentos e campos interessam, encurta o levantamento e baixa o preço. O que esse protótipo não traz é quase tudo o que este artigo descreve, ou seja, as verificações contra o ERP, a fila de exceções, as contas de acesso, as cópias de segurança e os testes. É a diferença que explicamos no artigo sobre levar um protótipo feito com IA a produção.
O custo de operação dos modelos cresce com o número de páginas processadas, e não com o número de faturas. Um PDF de vinte páginas com anexos técnicos custa muito mais a ler do que uma fatura de uma página, por isso medimos isto na amostra do levantamento e, quando compensa, o sistema separa as páginas que interessam antes de as enviar ao modelo.
Quando não compensa
Há situações em que a resposta honesta é não avançar com um projeto à medida:
- Poucos documentos. Com algumas dezenas de faturas por mês, o tempo poupado não paga o investimento.
- Um só formato dominante. Se oitenta por cento dos documentos vêm de três fornecedores, falar com eles sobre envio estruturado pode resolver mais depressa.
- Fornecedores que já enviam fatura estruturada. Nesse caso o que falta é importar, não ler.
- Necessidade que acaba no lançamento contabilístico. Vários ERPs e gabinetes de contabilidade já oferecem digitalização de faturas, e para faturas portuguesas sem conferência com encomendas isso pode chegar.
O projeto à medida faz sentido quando há volume, variedade de formatos e regras próprias, como a conferência com receções ou as encomendas de clientes.
Antes de pedir uma proposta
- Quantos documentos chegam por mês, de que tipos e de quantos emissores?
- Quantas horas por semana se gastam hoje a copiar e a conferir?
- Que erros já custaram dinheiro: duplicados, preços, quantidades, IBAN?
- Que tolerâncias são aceitáveis na conferência com encomendas?
- Quem gere o ERP e que formas de integração estão disponíveis?
- Que decisões podem ser automáticas e quais têm sempre de passar por alguém?
Este tipo de projeto cruza duas coisas que fazemos todos os dias: a automação de processos e a integração de IA nos sistemas da empresa. Se a sua equipa passa horas a copiar documentos para o ERP, pode pedir um diagnóstico gratuito. Olhamos para os documentos que recebe e para o ERP, sem compromisso, e devolvemos uma proposta com âmbito, prazo e investimento definidos.
