O PVA fechou a porta do seu SPED. O Fisco entra pela janela.

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?"

A malha de cruzamento que a Receita usa não é um único algoritmo comparando dois arquivos. É um conjunto de confrontos automáticos entre obrigações diferentes: EFD-Reinf com e-Social, ECF com ECD, a receita declarada com o total de NF-e emitidas no mesmo período, e o próprio SPED Fiscal com todas essas outras fontes ao mesmo tempo. Qualquer inconsistência relevante gera notificação automática, antes mesmo de um auditor humano abrir o processo. Fonte oficial: Portal SPED, Receita Federal, sped.rfb.gov.br, lido em 2026-09-08.

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.

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.

O ponto central é este: 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 ter nome próprio.

1. CFOP desalinhado entre emissão e escrituração: 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.

2. 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.

3. Bloco K divergente do consumo real: o padrã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.

No IBS e na CBS, a classificação errada não muda só a alíquota. Muda o crédito.

O que o CST errado custa hoje é a divergência no cruzamento. No IBS e na CBS, ele passa a custar crédito, e isso está escrito. O art. 51 da LC 214/2025 determina que a imunidade e a isenção acarretam a anulação dos créditos relativos às operações anteriores, de forma proporcional ao valor das operações imunes e isentas sobre o valor de todas as operações do fornecedor. Já o art. 52 diz o oposto para um caso vizinho: nas operações sujeitas a alíquota zero, os créditos das operações anteriores são mantidos.

Isenção e alíquota zero costumam ser tratadas no cadastro de material do SAP como se fossem a mesma coisa, porque nos dois casos o valor destacado é zero e o arquivo continua fechando. A partir de agora não são: uma anula crédito anterior, a outra preserva. Uma classificação trocada no cadastro não gera nenhuma mensagem de erro na emissão nem rejeição no validador. Ela aparece como saldo de crédito que não deveria existir, ou como crédito que foi anulado sem precisar.

O art. 54 fecha a conta com um prazo: o direito de utilização dos créditos se extingue após 5 anos, contados do primeiro dia do período subsequente ao de apuração em que ocorreu a apropriação. Um erro de classificação que só for descoberto na próxima fiscalização pode chegar ao diagnóstico já com parte do crédito fora do prazo de uso. A diferença entre achar isso em uma revisão de cadastro e achar isso numa autuação deixa de ser só multa: vira crédito que não volta mais.

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 (Emenda Constitucional 132/2023) 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.

A distinção que organiza tudo isso tem nome: 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 multiplica o que encontra

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.

E quando a notificação chega, a pergunta da diretoria não é para o SAP. É para quem, meses antes, recebeu o SPED aprovado no PVA e assinou o fechamento daquele mês como encerrado. A distância entre "o arquivo foi transmitido com sucesso" e "a operação está em conformidade" é exatamente onde a responsabilidade pessoal do Diretor Fiscal fica exposta, porque o PVA não emite parecer nenhum sobre isso, só sobre a estrutura do arquivo.

Se a sua equipe fiscal recebe o SPED aprovado no PVA como sinal de que a operação está em conformidade, o Diagnóstico Fiscal Estruturado testa essa premissa contra a parametrização real, antes do próximo cruzamento. O PVA fechou a porta. Mas o Fisco entra pela janela.

Esse mesmo gap entre estrutura correta e coerência tributária real aparece em outras duas frentes da NF-e: quando a nota está autorizada mas não está em conformidade, e quando o cClassTrib da Reforma Tributária não foi atualizado no cadastro de materiais do SAP. Na DFSpro, o Diagnóstico Fiscal Estruturado mapeia exatamente essa distância entre o que o SAP gera e o que o Fisco vai confrontar. Se faz sentido fazer esse mapeamento antes da próxima fiscalização, estou disponível.