Existe uma crença no mercado fiscal que precisa ser desmontada com cuidado, porque ela é responsável por passivos tributários que aparecem de forma completamente inesperada.

A crença é esta: arquivo SPED aprovado no PVA é arquivo fiscal correto.

Não é!

Entendo de onde vem a confusão. O PVA, o Programa Validador e Assinador da Receita Federal, é uma ferramenta rigorosa. Ele percorre todos os blocos do arquivo, verifica campos obrigatórios, confere estrutura hierárquica, valida se as somas fecham, rejeita CST inválido, aponta referência ausente. Quando ele aprova, a equipe fiscal respira. O processo do mês está concluído. O arquivo foi transmitido com sucesso.

O problema é que o PVA valida estrutura. A Receita Federal cruza coerência. São duas coisas fundamentalmente diferentes.

Quando o PVA aprova um arquivo, ele está dizendo: "Este arquivo está tecnicamente bem formado." Quando a Receita cruza esse mesmo arquivo com a NF-e emitida no mesmo período, com o SPED Contribuições, com o e-Social, com a EFD-Reinf e com os dados do fornecedor, ela está perguntando outra coisa: "O que este arquivo declara é coerente com o que todas as outras fontes registraram sobre a mesma operação?"

São perguntas diferentes. Com respostas que podem ser completamente diferentes.

A autuação que chega meses depois de um SPED aprovado no PVA quase sempre nasce dessa distância entre estrutura correta e coerência tributária real.

Vou ser específico sobre o que isso significa na prática.

O registro C100 do SPED é o cabeçalho da nota fiscal. O C170 detalha os itens. O C190 consolida as tributações por CFOP e CST. Para que o arquivo seja estruturalmente correto, esses registros precisam estar presentes e matematicamente consistentes entre si. O PVA verifica isso. E aprova quando está certo.

O que o PVA não verifica é se o CST usado no C190 corresponde à operação real que gerou aquela nota. Não verifica se o CFOP declarado é compatível com a natureza fiscal da transação. Não verifica se o NCM do produto está correto no cadastro de materiais do SAP e se esse NCM está sendo usado de forma consistente na NF-e e na escrituração. Não compara o que foi declarado na escrituração de saídas com o que o destinatário declarou nas suas entradas.

Esse cruzamento acontece depois, no ambiente da Receita, de forma automática.

Aqui está o ponto central que quero desenvolver: na maioria dos casos que analiso em grupos industriais com SAP, a inconsistência não nasceu no momento da geração do arquivo SPED. Ela nasceu antes. Muito antes. Nasceu na configuração do SAP.

O SAP emite a NF-e usando grupos de impostos, esquemas de cálculo e tabelas de CFOP que foram configurados em algum momento do passado. O processo de geração do SPED usa outras referências, outros mapeamentos, outras tabelas. 

Quando esses dois processos foram configurados em momentos diferentes, por equipes diferentes, sem um trabalho de integração estruturada entre eles, é comum que existam pontos de divergência silenciosa.

A nota fiscal sai com um CST. O SPED registra a mesma operação com outro CST. Os dois arquivos são transmitidos. O PVA aprova os dois. A Receita cruza e encontra divergência. A autuação chega.

Não é descuido da equipe fiscal. É configuração.

Esta distinção é importante porque ela muda completamente o que precisa ser feito para resolver o problema. O mercado vende automação de SPED como solução. E automação ajuda, sem dúvida. Mas se a parametrização do SAP está errada, automação garante que o erro acontece mais rápido e em escala maior. Você automatiza a geração de um arquivo que está errado na origem.

O problema não é o arquivo. É o SAP que o alimenta.

Existem alguns padrões de inconsistência que aparecem com frequência em operações industriais com SAP. Não são universais, mas são recorrentes o suficiente para que valha a pena nomeá-los.

O primeiro é o desalinhamento entre a lógica de CFOP usada na emissão da NF-e e a lógica de mapeamento usada na escrituração do SPED. Em operações com múltiplos estados, isso se torna mais complexo porque os CFOPs variam por UF de destino. Um SAP mal configurado para operações interestaduais pode estar gerando escriturações com CFOP incorreto em parte dos estados atendidos, sem que nenhum alarme apareça internamente.

O segundo é o uso de CST inconsistente com a natureza da operação. O CST é o Código de Situação Tributária. Ele informa ao Fisco como aquela mercadoria está sendo tratada para fins de ICMS ou IPI. Quando o SAP foi originalmente configurado, os CFOPs e CSTs foram definidos para o cenário de operação da época. Se a empresa expandiu para novos mercados, adicionou novos produtos ou passou por mudanças regulatórias sem uma revisão sistemática das tabelas fiscais no SAP, é comum que existam CSTs que deixaram de ser corretos para determinadas operações.

O terceiro padrão, e o mais crítico para indústrias que têm o Bloco K obrigatório, é a divergência entre o consumo de insumos declarado no SPED e o que os dados de produção no SAP indicam. O Bloco K exige que a empresa informe, mês a mês, quais insumos foram consumidos em quais ordens de produção. Quando o SAP PP e o SAP MM não estão integrados de forma correta com o processo de geração do SPED, a ficha técnica declarada no Bloco K pode divergir do que o ERP registrou como consumo real. O Fisco interpreta divergência de estoque como indício de omissão de receitas.

E aqui está o risco que a maioria das equipes fiscais não consegue ver: essas inconsistências não aparecem no PVA. Passam mês após mês. São transmitidas. São acumuladas. E são encontradas quando o cruzamento automático da Receita decide comparar o que você declarou com o que outras fontes registraram.

Em 2026, com a Reforma Tributária adicionando novos campos ao SPED para CBS e IBS, a superfície de cruzamento aumentou. A Receita agora tem mais pontos de comparação, mais camadas de verificação, mais bases de dados para confrontar com o que a empresa declarou. A inconsistência que passava despercebida no ambiente anterior pode ter peso diferente no ambiente atual.

Existe um conceito que resume bem o que estou descrevendo: a diferença entre conformidade formal e conformidade material. A conformidade formal é atingida quando o arquivo está tecnicamente correto e o PVA aprova. A conformidade material é atingida quando o que foi declarado reflete com precisão a realidade econômica das operações. O PVA verifica a primeira. O Fisco exige a segunda.

O que faço quando começo um trabalho com um grupo industrial que usa SAP é mapear exatamente essa distância. Não começo pelo arquivo SPED. Começo pela configuração fiscal do SAP: grupos de impostos, esquemas de cálculo, tabelas de CFOP, mapeamento de CST por tipo de operação, integração entre MM e PP para o Bloco K, lógica de geração do registro C100 e C190.

Esse mapeamento revela onde estão os pontos de divergência potencial entre o que o SAP gera e o que o Fisco vai confrontar. Só depois de identificar e corrigir esses pontos o processo de escrituração passa a ser confiável de forma estruturada.

Automação em cima de configuração correta é eficiência. Automação em cima de configuração errada é risco em escala.

A diferença entre os dois cenários não está no processo de geração do arquivo. Está nos meses ou anos de diagnóstico que alguém fez, ou deixou de fazer, antes.

Se a sua equipe fiscal recebe o SPED aprovado no PVA como sinal de que a operação está em conformidade, vale revisitar essa premissa. O PVA fechou a porta. Mas o Fisco entra pela janela.

Artigo escrito por Emanuel Kaufman, Head of Business da DFS PRO Especialista em operações fiscais críticas em SAP e Guepardo Tax - Curitiba, 2026 ( DFSpro IT Solutions )

#SPEDFiscal #FiscalSAP #GestaoFiscal #ReformaTributaria #ComplianceFiscal #SAPFI #DiretorFiscal #GovernancaFiscal #EFD #ICMS