Como ler e lançar faturas de fornecedor automaticamente (e o que corre mal)

A extração e a conferência das faturas automatizam-se bem; onde a coisa trava é no lançamento dentro do ERP e nos casos-limite da própria fatura, e é aí que se decide se vale mesmo a pena.

"Automaticamente" não quer dizer que ninguém olha. Quer dizer que o trabalho mecânico (abrir o PDF, copiar os campos, conferir com a guia, lançar e arquivar) deixa de ser feito à mão, e a pessoa fica só onde é precisa: a decidir o que está em dúvida. A diferença entre uma automatização que dura e uma que é abandonada ao fim de um mês está quase toda nos detalhes abaixo.

Os passos, e porque cada um é mais difícil do que parece

• Ler os campos da fatura: fornecedor, NIF, número, data, base, IVA, total, e as linhas. Numa fatura nativa em PDF é directo. Numa digitalização torta, numa foto tirada ao balcão, ou numa fatura de duas páginas com a tabela a partir-se, deixa de ser.
• Conferir com a realidade. Uma fatura não se lança só porque foi lida. Confere-se contra a encomenda e contra a guia de remessa (o "three-way match"): foi isto que pedimos, foi isto que chegou, é isto que estão a cobrar. É aqui que se apanham cobranças a mais, quantidades que não bateram e entregas parciais.
• Lançar no ERP: criar o documento de compra com as linhas, o IVA certo e a conta.
• Arquivar com o original ligado ao registo, para auditoria.

Onde corre mal (a parte que interessa)

Na leitura:

• Totais que não fecham por cêntimos. O IVA arredonda por linha ou sobre o total, e consoante o fornecedor dá um cêntimo de diferença. Um sistema que exige que bata ao cêntimo rejeita faturas boas; um que não verifica deixa passar erros.
• Várias taxas de IVA na mesma fatura (23, 13 e 6 em Portugal). Se a extração colapsa tudo numa taxa, o valor lançado fica errado e só se descobre no fecho.
• Linhas vs total. Ler o total é fácil. Ler as linhas, com descrições longas, unidades e descontos, é onde a extração falha mais, e é precisamente o que é preciso para conferir com a guia.
• O mesmo fornecedor, dez formatos. Cada fornecedor tem o seu layout, e muda-o sem avisar. Uma solução que depende de "templates" por fornecedor parte-se ao primeiro redesenho.

Na conferência:

• Dados mestre desalinhados. O nome do artigo na fatura não é o nome no vosso sistema, as unidades diferem (caixa vs unidade), e o fornecedor na fatura não casa com a ficha. Sem resolver isto, o match automático falha mais do que acerta.
• Entregas parciais e guias múltiplas. Uma fatura pode cobrir três guias, ou meia guia. A conferência tem de somar o que faz sentido, não comparar um para um.
• Duplicados. A mesma fatura entra duas vezes (email e papel). Sem detecção de duplicados por fornecedor mais número, paga-se duas vezes.

No lançamento (o verdadeiro travão):

• Escrever num ERP como o Primavera ou o PHC é possível, mas depende da versão e do acesso. No Primavera, por exemplo, há API de escrita para documentos de compra, mas exige a Web API instalada no servidor do cliente, um utilizador do ERP, acesso de rede, e na prática passa pelo parceiro Primavera da empresa.
• Por isso o nosso primeiro passo em qualquer projecto é validar esse acesso antes de prometer prazos. A experiência honesta da maioria das integrações começa por leitura; a escrita automática confirma-se caso a caso, não se assume.
• Lançar faturas de fornecedor não toca na certificação da AT. Essa certificação é para quem emite faturas, não para quem as regista. É uma confusão comum que trava projectos sem razão.

Como decidir se vale a pena

A conta é simples e honesta: volume vezes tempo por fatura. A 600 faturas por mês e dez minutos cada, há muito a ganhar. A 40 faturas por mês, o retorno é duvidoso e às vezes a resposta certa é não automatizar. O tempo por fatura tem de o dar quem faz o trabalho, não um modelo a adivinhar, senão a poupança é ficção.

E há um limite que convém dizer: a parte que nunca desaparece por completo é a decisão sobre o que ficou em dúvida. O objectivo não é zero humanos; é a pessoa deixar de transcrever e passar a decidir sobre o que o sistema já lhe pôs à frente, conferido.

Como a CAIS AI aborda isto

Começamos sempre por um diagnóstico, antes de dar preço ou prazo. Olhamos para três coisas: o acesso real aos sistemas (o que o ERP deixa ler e escrever, em que versão, com que utilizador e que rede), o volume e o tempo verdadeiros por fatura (medidos com quem faz o trabalho, não estimados), e os formatos que entram de facto (quantos fornecedores, quantos layouts, quanto chega em papel ou foto). É deste diagnóstico que sai se vale a pena, por onde começar, e o que fica para depois.

A seguir, construímos por camadas, da mais segura para a mais exposta. Primeiro a leitura e a conferência, que dão valor sem tocar no ERP e sem risco de lançar algo errado. Só depois, e só depois de validar o acesso, a escrita automática. Uma automatização que lança por cima dos dados do cliente sem essa validação é o que mais estraga a confiança, por isso não a assumimos: provamo-la antes.

A aprovação humana fica onde o dinheiro muda de mãos. O sistema lê, confere, e põe à frente da pessoa só o que está em dúvida (um total que não bateu, uma guia que não casou, um duplicado provável). O resto corre sozinho. É assim que a equipa passa de transcrever para rever.

E o que construímos fica vosso: à medida do processo que já têm, sem obrigar a mudar o ERP, e sem licenças mensais pela parte feita à medida. As faturas de fornecedor são só um processo; a mesma abordagem (ler, conferir, lançar, com o humano onde importa) aplica-se a relatórios, reconciliações e ao fecho do mês.

Se quiserem ver a conta para o vosso caso, há um agente no nosso site que a faz a partir de uma descrição, em caisai.tech. E o primeiro passo de um projecto é sempre a conversa de diagnóstico, não uma proposta às cegas.

In English

Reading and posting supplier invoices automates well at the extraction and reconciliation steps; it stalls at posting into the ERP and at the invoice edge cases, and that is where the decision to automate is really made. "Automatic" does not mean no one looks: the mechanical work goes away, and the person stays where judgment is needed. The hard parts are line-item extraction, VAT rounding and multiple rates, matching against delivery notes with mismatched master data, duplicate detection, and ERP write access, which depends on version and access and must be validated before any deadline is promised. Posting received invoices does not touch Portuguese AT invoice-issuing certification. CAIS AI starts with a diagnosis of access, real volumes and formats, builds in layers from safe to exposed (reading and reconciliation first, automatic ERP posting only after access is validated), keeps human approval where money changes hands, and the custom software stays the client's.