Validar automaticamente que base + IVA − retenção bate certo com o total da fatura

Se só vais automatizar uma verificação depois do OCR, que seja esta: base tributável + IVA − retenção na fonte = total da fatura, verificada ao cêntimo com uma tolerância explícita de um cêntimo por bloco de taxa. É a única regra que apanha o erro de extração mais caro: um valor *plausível* mas errado. Um nome de fornecedor mal lido salta à vista. Um total desviado 31,50 € não salta, e fica na contabilidade até que a reconciliação bancária falhe três semanas depois.

Esses 31,50 € não são um exemplo inventado: correspondem ao erro aritmético mais comum de toda a fatura. A retenção calcula-se sempre sobre a base, nunca sobre o valor com IVA. Numa fatura de serviços de 1.000 € com IVA a 23% e retenção de 25%, o total correto é 1.000 + 230 − 250 = 980,00 €. Se aplicares os 25% aos 1.230 € com IVA, obténs 307,50 € de retenção e um total de 922,50 €: um desvio de 57,50 € que não bate certo com nada e que ainda entregas mal na guia de retenções. As calculadoras que posicionam para esta pesquisa dão-te a fórmula; o que se segue é como transformá-la num portão automático que corre em cada documento extraído.

Porquê automatizar: o benchmark IOFM de 2025 aponta uma taxa média de erro na introdução manual de dados na ordem dos 3,6%, e os inquéritos do setor estimam em cerca de 53 dólares o custo médio de resolver um erro de fatura. Com 400 faturas por mês, esses 3,6% são cerca de 14 erros — a verificação não precisa de apanhar todos para se pagar.

A regra, escrita para uma máquina a executar

Para cada fatura extraída:

`soma(base_i) + soma(base_i × taxa_iva_i) − retenção − |total| ≤ tolerância`

E, em separado, por bloco de taxa:

`iva_i ≈ base_i × taxa_iva_i`
`retenção ≈ soma(base_i) × taxa_retenção`, calculada sobre a base, com o IVA de fora

Três coisas tornam isto mais difícil do que parece — e é exatamente aí que as implementações ingénuas partem.

1. Nunca fixes a taxa no código

Deduz a taxa a partir dos próprios valores e confronta-a com o conjunto de taxas legais. Em Portugal convivem IVA a 23 / 13 / 6% no continente (com taxas próprias nos Açores e na Madeira) e retenções de categoria B que não são um número único: 25% para as atividades da tabela do artigo 151.º do CIRS, 16,5% para propriedade intelectual e 11,5% para atividades fora dessa tabela, além da taxa geral reduzida introduzida em 2025 e da dispensa de retenção para quem estima rendimentos anuais abaixo dos 15.000 €. Um validador que assuma «25%» dispara falsos alarmes em metade dos fornecedores. Deixa a extração devolver a taxa impressa, recalcula-a a partir de base e valor, e assinala só quando as duas não coincidem.

2. Vários blocos de taxa na mesma fatura

Um fornecedor que fatura mercadoria a 23% e transporte a 6% produz dois blocos. Verifica cada um por si e depois soma. Se leres apenas a linha de IVA maior — o atalho típico de uma extração de campo único — obténs um total errado e um desvio fantasma que ninguém consegue explicar.

3. Linhas que estão no total mas não na base

Há valores que entram no total sem entrarem na base tributável nem na base de retenção:

Adiantamentos pagos em nome do cliente: fora da base, fora do IVA, fora da retenção.
Imposto do selo e outras taxas parafiscais: somam ao total e nunca tocam na base.
Descontos financeiros aplicados depois do subtotal: alteram a base em alguns casos e o total noutros, consoante como o fornecedor os emite.

Se a verificação se limitar a somar «tudo o que parece um número», estes casos geram falsos positivos constantes e a equipa acaba por ignorar os alertas — o que é pior do que não os ter.

Que diferença é aceitável

Usa ±0,01 € por bloco de taxa, mais ±0,01 € para a linha de retenção. Uma fatura de taxa única tolera 0,02 €; uma de duas taxas, 0,03 €. Não é laxismo, é aritmética: há fornecedores que arredondam o IVA linha a linha e outros sobre o subtotal do bloco, e os dois métodos divergem um ou dois cêntimos em faturas longas. Acima dessa tolerância já não é arredondamento: ou é um dígito mal lido ou é uma fatura genuinamente mal emitida.

Divide o resultado em três estados, não em dois:

Verde — dentro da tolerância. Lança-se. Nada a rever.
Amarelo — alguns cêntimos acima. Quase sempre diferença de arredondamento ou confusão entre vírgula e ponto decimal no OCR. Fila de revisão de cinco segundos.
Vermelho — desvio com padrão conhecido. Retenção calculada sobre o total com IVA, bloco de taxa perdido, dígito trocado (7↔1, 3↔8, 6↔5 são as confusões clássicas do OCR em digitalizações más). Volta à extração ou entrada manual.

O desvio *em si* é diagnóstico. Se for exatamente igual a `retenção × taxa de IVA`, encontraste o erro número um. Se for igual a um bloco inteiro, falta-te um bloco. Se for uma potência de dez limpa, alguém perdeu ou acrescentou um dígito.

Onde é que isto encaixa no fluxo

A verificação tem de correr no momento da extração, no mesmo segundo em que o dado nasce. Uma validação semanal dentro do software de contabilidade é um relatório; uma validação na extração é um portão. Com o WhappScan o sítio natural é logo à chegada do documento: o fornecedor ou um colega envia a foto ou o PDF para o número de WhatsApp, os campos voltam estruturados e a verificação aritmética corre sobre esses campos antes de qualquer coisa chegar ao Excel ou ao ERP. Se preferires montar isto numa pipeline própria, os mesmos campos saem por API e a validação pode viver do teu lado: vê como enviar as faturas para o Excel ou para o teu ERP via API e, do lado da captura, como automatizar a extração de faturas por WhatsApp.

Um detalhe prático: define a verificação sobre um modelo que já declare base, taxa de IVA, valor de IVA, taxa de retenção, valor retido e total como campos separados. Se a extração devolve um bloco de texto, não há nada para validar. Campos estruturados por bloco de taxa são o pré-requisito, não um extra — a mesma razão pela qual preparar bem as faturas de fornecedor antes de as entregar ao contabilista evita as idas e voltas do fecho do trimestre. Se trabalhas a partir de um gabinete, o fluxo completo — captura, extração, validação — é aquilo em torno do qual o WhappScan para contabilidade está construído.

A verificação seguinte a acrescentar

Quando a validação aritmética estiver consistentemente verde, a regra com melhor retorno é a deteção de duplicados: mesmo NIF de fornecedor, mesmo número de fatura, mesmo total. Custa quase nada calcular sobre campos já extraídos e apanha a classe de erro que a aritmética nunca verá — uma fatura perfeitamente correta lançada duas vezes. Está em como apanhar faturas duplicadas antes de as lançar.

Experimenta com uma fatura real

Pega na fatura mais incómoda que tens em cima da secretária — a das duas taxas de IVA e linha de retenção — e extrai-a. Depois faz tu a aritmética de três linhas e vê se os números coincidem.

Extrai gratuitamente os dados do teu documento, sem conta e sem instalar nada, em /pt/free.