Um diretor financeiro de uma tecelagem no Vale do Ave recebeu um aviso da AT: discrepância de 18 mil euros entre o SAF-T enviado e o movimento real de armazém. O ERP tinha registado tudo. O SAF-T também. Mas nenhum deles gritou quando o picking manual divergiu da codificação de lotes. A faturação foi correta. O imposto foi pago. O ficheiro que saiu da máquina estava "limpo". Ponto final. Só que não — porque o custeio de produto estava 7% acima da realidade, e ninguém tinha visto.

Esta é a verdade que nenhum software de conformidade fiscal avisa: o SAF-T pode estar impecável enquanto o seu ERP trabalha com dados fictícios. Em 2025, apenas 53,7% das empresas em Portugal (10+ pessoas) usavam software de gestão empresarial integrado — e dessas, a maioria trata o ERP como um registador de transações, não como um vigilante de integridade. Vemos isto com frequência em fábricas e armazéns com movimento de stock complexo (têxtil com cores e malhas, calçado com tamanhos e ajustes, componentes metal com série única): o SAF-T torna-se um espelho do que o ERP acredita que aconteceu. Não do que realmente aconteceu. E o custo dessa cegueira operacional não aparece na declaração fiscal — aparece no custeio de produto, na previsão de compra, no planeamento de produção, e finalmente na margem que o sistema diz que tem mas que não tem.

Conformidade fiscal não é a mesma coisa que precisão operacional. Um SAF-T correto pode vir de dados incorrectos.

O ERP não sabe o que não vê

Um ficheiro SAF-T é uma fotografia de transações: documento de entrada, código de artigo, quantidade, preço, movimento de caixa. O ERP extrai isto do seu banco de dados e monta o ficheiro. Tudo correto, do ponto de vista da máquina. Mas o ERP só regista o que foi digitado ou importado. Se uma operadora fez picking de 12 unidades quando o sistema pediu 15, e ninguém corrigiu a diferença no dia — talvez porque a encomenda foi parcial, talvez porque o lote tinha um defeito que foi descoberto tarde — o SAF-T vai reportar 15. Ninguém avisa que faltam 3.

Ou: um lote de matéria-prima chegou com uma nota de entrada manual (papel). O motorista entregou 500 kg, mas a pesagem do armazém registou 487 kg por humidade. O ERP recebeu 500 (conforme a guia). O SAF-T reporta 500. A Autoridade Tributária vê 500. A realidade? 487. E se esse lote alimentou uma série de produções, cada uma delas carrega um custo fictício que vai contaminar o custeio de toda a série seguinte.

Três pontos de fuga que ninguém mede

Primeiro: desajuste entre a receção e o armazém. A guia de transporte diz 100 unidades. O armazém pesa, conta ou verifica e descobre 97. Se o utilizador faz uma nota de crédito manual, o ERP fica ciente. Se não faz — talvez porque "é só 3%" ou porque a diferença vai ser absorvida no próximo movimento — o SAF-T sai com 100. Meses depois, uma auditoria interna vê que o stock físico não bate com o sistema. O SAF-T já foi enviado. A certidão de conformidade fiscal está feita. O corte de contas fica suspenso. Em projectos que acompanhamos, encontrámos empresas com taxa de divergência de receção entre 2% e 5% — o que significa que um armazém com movimento mensal de 50 mil euros acumula entre mil e 2.500 euros de "diferença" que ninguém formalizou.

Segundo: lotes com divergência de qualidade ou que ficam presos em quarentena. Uma compra de fio chega com defeito parcial. O lote fica em quarentena. A nota de entrada foi processada (o SAF-T vê a entrada). Mas a devolução foi feita por telefone, via email, ou documentada apenas no papel. O sistema nunca viu a saída. O stock de sistema inclui um lote que não existe no armazém — é sucata, é refugo, é um bem que se tornou passivo. O SAF-T reporta um bem que desapareceu fisicamente há semanas.

Terceiro: produção com desperdício não-registado ou com transferências internas sem documento. Uma fábrica de calçado produz 80 unidades de um modelo. 5 saem com defeito (raspo, falha de costura). Essas 5 são destruídas. Mas a ordem de produção fechou com 80 no sistema. Ninguém criou um documento de "sucata" ou "destruição" no ERP. O SAF-T vê 80 saídas. O armazém tem 75. A diferença é absorvida como "variação de processo", que é um eufemismo para "não sabemos". Quando o CEO pergunta qual é o rendimento real de produção, a resposta vem inflacionada porque o sistema não vê a sucata.

O custo oculto da conformidade sem visibilidade

Quando um CEO pergunta "quanto custa-nos esta discrepância?", a resposta típica é: "Nenhum custo. O SAF-T passou, a AT aceitou, o imposto foi pago." É verdade. Mas é incompleto. O custo está noutro lado.

Está no custeio de produtos que fica inflacionado porque o lote de matéria-prima tem peso fictício. Está na previsão de compra que se baseia num stock que não é verdadeiro — e que leva a encomendar a mais ou a menos. Está no planeamento de produção que aloca recursos para fazer 100 unidades quando só 97 chegaram, gerando atrasos que ninguém consegue explicar. Está na margem que o sistema diz que tem mas que não tem realmente, porque o custo de produção foi calculado sobre uma quantidade que não é verdadeira. Um distribuidor que acompanhamos tinha um SAF-T impecável durante dois anos. Mas o seu sistema de custeio de produto estava 7% acima da realidade porque a receção de armazém tinha uma taxa de divergência de 3-4% que ninguém tinha formalizado. Quando decidiu fazer um ajuste de stocks, descobriu que tinha 140 mil euros de diferença acumulada. Não era defraudação fiscal. Era invisibilidade operacional — e custou-lhe uma redefinição completa de margens, uma revisão de preços de venda, e uma perda de confiança interna no sistema de planeamento.

A conformidade fiscal é necessária. Mas não é suficiente para gerir uma empresa.

O que o ERP deveria avisar (e muitas vezes não faz)

Um bom ERP deve ter controlos que disparem alertas quando há divergência entre o esperado e o registado. Alguns fazem isto bem. Muitos não. Um ERP verticalizado para indústria deveria avisar quando a receção de uma compra diverge mais de 2% da guia — não deixar o utilizador passar. Deveria avisar quando um lote fica em quarentena por mais de 30 dias sem movimento, porque isso é um ativo que está a apodrecer. Deveria avisar quando uma ordem de produção fecha com quantidades que não batem com o consumo de matéria-prima — porque isso significa que há sucata não-documentada. Deveria avisar quando um movimento manual de stock (ajuste) é superior a 1% do valor mensal movimentado, porque ajustes grandes e frequentes são um sintoma de falta de controlo. Deveria avisar quando uma devolução de fornecedor não tem documento de receção associado, porque isso é uma transação órfã.

Estes controlos existem. Mas exigem configuração cuidada. Exigem que o utilizador tenha definido previamente qual é a tolerância aceitável para cada tipo de divergência. Exigem que o ERP não seja apenas um registador de transações, mas um vigilante de integridade. A maioria das empresas que vemos usa o ERP como um ficheiro. Não como um controlador. E depois fica surpreendida quando descobre que o seu SAF-T está perfeito, mas os seus dados não são.

Honestidade sobre o nosso próprio erro

Há cinco anos, quando implementávamos o ERP MULTI, dizíamos aos clientes: "Certificamos o software na AT, o SAF-T sai automático, vocês têm conformidade garantida." Era verdade. Mas era incompleto. Não alertávamos para o facto de que a conformidade fiscal não é a mesma coisa que a precisão operacional. Um SAF-T correto pode vir de dados incorrectos. Aprendemos isto com implementações reais, com auditorias internas de clientes que descobriam discrepâncias, com CFOs que nos diziam: "O vosso sistema disse que tudo estava bem. Mas o meu stock não bate." Aprendemos isto com uma fábrica têxtil que tinha divergência de 4% entre o sistema e a contagem física, e que só o descobriu quando tentou fazer uma auditoria interna para candidatura a financiamento PT2030. Aprendemos isto com um distribuidor de componentes metal que tinha 23 devoluções de fornecedor documentadas apenas em papel, porque "o sistema não tinha campo para isso".

Hoje sabemos que a responsabilidade não é só certificar o ficheiro. É ajudar o cliente a ter dados verdadeiros antes de o ficheiro sair. É configurar alertas que gritem quando há anomalia. É treinar o utilizador a ver o ERP não como um arquivo, mas como um controlador de realidade.

O que fazer agora

Se é CEO ou COO de uma empresa industrial, faça três perguntas na próxima reunião de IT. Um: qual é a taxa de divergência entre a receção de compras (guia) e o registo de armazém? Se é superior a 1%, tem um problema de integridade de dados que está a contaminar o custeio. Dois: quando foi a última vez que fizemos uma contagem física completa de stocks (e comparámos com o sistema)? Se foi há mais de 12 meses, o vosso SAF-T pode estar a reportar fictício. Três: o vosso ERP tem alertas configurados para movimentos anómalos — compras com divergência, devoluções sem receção, ajustes acima de threshold, lotes em quarentena há mais de 30 dias? Se não tem, está a trabalhar no escuro.

O SAF-T é um ficheiro. O que importa é o que vai dentro dele. E o que vai dentro dele é determinado pela integridade dos dados que o ERP viu — ou que fingiu ver.

Leia também: Planeamento de capacidade produtiva: o que o ERP calcula e o que falha, MES sem integração ERP: o custo oculto que o COO não vê, e ERP e private label: rastreabilidade e custeio em produção por conta de outrem.

Perguntas frequentes

O que é uma discrepância SAF-T e por que razão o ERP não a deteta?

Uma discrepância SAF-T ocorre quando o ficheiro enviado à AT reflete dados que o ERP registou, mas que não correspondem à realidade operacional. O ERP só vê o que foi digitado ou importado — se um picking manual divergiu da codificação de lotes ou se uma receção não foi formalizada, o sistema não avisa porque não tem informação dessa divergência.

Qual é a diferença entre conformidade fiscal e precisão operacional?

Conformidade fiscal significa que o SAF-T está correto e a AT o aceita. Precisão operacional significa que os dados no ERP correspondem à realidade do armazém e da produção. Um SAF-T pode estar impecável enquanto o ERP trabalha com dados fictícios, causando erros no custeio de produtos e planeamento.

Quais são os três principais pontos de fuga de dados em produção industrial?

Primeiro: desajuste entre receção e armazém (guia diz 100, armazém tem 97). Segundo: lotes em quarentena ou com defeito não formalizados como devolução. Terceiro: desperdício de produção não-registado — por exemplo, 5 unidades defeituosas destruídas mas o sistema fechou a ordem com 80. Nenhum destes gera alerta fiscal, mas todos afetam o custeio.

Como é que uma divergência de receção afeta o custeio de produtos?

Se um lote chega com 487 kg mas o ERP regista 500 kg (conforme a guia), cada produto fabricado a partir desse lote carrega um custo fictício. Esse custo contamina toda a série de produções seguintes, inflacionando o custeio real. Meses depois, o stock físico não bate com o sistema, mas o SAF-T já foi enviado.

Qual é o impacto financeiro real de uma discrepância não-formalizada?

O impacto não aparece na declaração fiscal, mas afeta o custeio de produto, a previsão de compra, o planeamento de produção e a margem reportada. Uma empresa com taxa de divergência de 3-4% na receção pode acumular dezenas de milhares de euros de diferença, levando a revisão de preços de venda e perda de confiança no sistema.

Por que razão um lote em quarentena se torna um problema no SAF-T?

A nota de entrada é processada (o SAF-T vê a entrada), mas se a devolução foi feita por telefone, email ou apenas em papel, o sistema nunca regista a saída. O stock de sistema inclui um lote que não existe fisicamente no armazém, tornando-se um bem que desapareceu mas que o SAF-T continua a reportar.

O que deveria avisar um ERP quando há divergência entre o esperado e o registado?

Um bom ERP deveria disparar alertas quando a receção de uma encomenda não bate com a guia, quando um lote fica em quarentena sem documento de devolução formal, ou quando a produção real diverge da ordem de produção. Muitos ERP tratam-se como registadores de transações e não como vigilantes de integridade operacional.