A SEFAZ autorizou. O SAP processou. O XML está arquivado. O mês fechou.
Para a maioria das operações, esse encadeamento encerra o assunto. O que poucos percebem é que ele encerra o assunto errado.
Autorização de NF-e é um julgamento tecnológico: XML íntegro, assinatura digital válida, CNPJ ativo, numeração em sequência, campos obrigatórios presentes. A SEFAZ não julga, no momento da autorização, se o CFOP está correto para aquela operação, se o Tax Code de ICMS reflete a legislação estadual vigente, se o benefício fiscal aplicado ainda tem amparo regulatório, se a base de cálculo corresponde à regra aplicável.
Esses são critérios de conformidade fiscal. Eles não entram no processo de autorização. Entram no processo de fiscalização, que tem prazo decadencial de até cinco anos para ocorrer.
A empresa que opera com esses dois julgamentos confundidos está acumulando exposição em cada nota emitida, sem que nenhum sinal sistêmico dispare.
O que o SAP faz com a configuração errada
O SAP tem uma característica que define seu valor e seu risco em contexto fiscal ao mesmo tempo: ele executa com fidelidade e escala o que foi configurado.
Essa característica é a maior força do sistema quando a configuração está correta. E o maior risco quando não está.
Um Tax Code de ICMS-ST configurado com MVA desatualizado não gera um erro por mês. Gera o mesmo erro em cada transação que passa por aquele fluxo, em cada filial que usa aquela regra, em cada nota que aquela parametrização produz. A SEFAZ autoriza todas. O SPED acumula todas. O passivo cresce em proporção direta ao volume da operação.
Em diagnósticos que realizamos, o padrão que aparece com mais consistência não é empresa que desconhece a norma. É empresa que tinha a parametrização desatualizada desde uma mudança de MVA estadual de dezoito meses atrás, gerou 40 mil NF-e com base de cálculo incorreta, e nunca recebeu nenhum alerta sistêmico, porque o sistema estava executando exatamente o que havia sido configurado. Com fidelidade. Com escala.
O erro sistemático é, por definição, invisível. O SAP não sabe que a regra mudou. Ele executa a regra que tem.
O que a fiscalização vê que o sistema não mostra
Quando a SEFAZ ou a Receita Federal realiza uma fiscalização eletrônica, o que está sendo cruzado não é apenas o XML da NF-e. É a consistência entre a NF-e, o SPED, a apuração declarada e a legislação vigente no período.
Esse cruzamento encontra coisas que o sistema de autorização nunca vai encontrar: CFOP que não corresponde à natureza da operação declarada na nota; benefício fiscal aplicado em período posterior à revogação do decreto que o ampara; alíquota de ICMS interestadual incorreta para a combinação de estados; ausência de destaque de ICMS-ST em operação onde ele é obrigatório por protocolo.
Nenhum desses problemas interrompeu o fluxo de autorização da SEFAZ. Todos eles são passíveis de autuação com prazo decadencial a partir da emissão de cada nota.
A empresa que descobre esse gap numa fiscalização enfrenta dois problemas simultâneos: o passivo calculado com base no volume de notas com erro, e a ausência de documentação que demonstre que o erro foi processual e não intencional. Quando a inconsistência é sistemática e de longa data, a defesa fica estruturalmente mais difícil.
Por que a revisão periódica não acontece
A suposição que sustenta o gap: se está autorizado, está certo. Essa suposição tem lógica operacional. O problema é que ela confunde dois sistemas com propósitos completamente diferentes.
A SEFAZ não tem como saber, no momento da autorização, se o CFOP declarado corresponde à operação real. Ela valida o documento. O Fisco julga a substância da operação quando inicia o processo de fiscalização.
Além da suposição, existe um problema de invisibilidade estrutural. Erros de parametrização fiscal no SAP não geram sintoma visível no fluxo de trabalho. A nota sai, o sistema não reclama, o mês fecha. A inconsistência só aparece quando alguém vai comparar a parametrização com a legislação vigente, o que raramente faz parte da rotina operacional de uma equipe fiscal já sobrecarregada com fechamento e obrigações acessórias.
O resultado: parametrizações ficam desatualizadas por meses ou anos, acumulando volume de exposição que só vai ser quantificado quando a fiscalização o fizer.
O que conformidade fiscal exige que autorização não exige
Conformidade fiscal real tem quatro camadas. Nenhuma delas é verificada no processo de autorização da SEFAZ.
A primeira é atualização da regra fiscal aplicada. Tax Code, CFOP, alíquota, base de cálculo e benefício fiscal precisam refletir a legislação vigente para aquela operação específica, considerando produto, estado de origem, estado de destino e natureza jurídica. A legislação muda. A parametrização do SAP não muda automaticamente. Esse gap precisa de processo.
A segunda é consistência entre NF-e, SPED e apuração. O que está na nota fiscal precisa ser consistente com o que foi apurado no SPED e declarado nas obrigações acessórias. Divergência entre esses três pontos é o primeiro cruzamento que a fiscalização eletrônica realiza. O SAP precisa garantir essa consistência por design, não por verificação manual posterior.
A terceira é rastreabilidade da decisão fiscal. Para cada regra aplicada, precisa existir registro de qual foi a base legal, quando foi configurada e qual versão da legislação estava vigente. Sem rastreabilidade, a empresa não consegue demonstrar boa-fé técnica num processo de contestação onde a consistência do erro vai ser usada como evidência.
A quarta é detecção proativa de desvio. Em ambiente SAP com legislação estadual dinâmica e volume alto de NF-e, monitoramento retroativo por auditoria chega tarde. A identificação de desvio precisa acontecer antes da nota sair, não quando a fiscalização já cruzou cinco anos de SPED.
O caminho antes de a fiscalização fazer o diagnóstico
A sequência que funciona começa pelo mapeamento mais desconfortável: comparar o que está configurado no SAP com o que a legislação vigente exige para cada categoria de operação, produto e UF de destino. Não uma auditoria de conformidade geral. Um mapeamento de parametrização por regra, com verificação do prazo de atualização.
O padrão que aparece nesse mapeamento é quase sempre o mesmo: regras que nunca foram atualizadas após mudança de protocolo interestadual, benefícios aplicados após revogação de decreto, alíquotas de produto com NCM reclassificado que não foi propagado para o Tax Code.
O segundo passo é priorização por risco. Volume de operação com aquela parametrização, prazo decadencial do período afetado e exposição por UF de destino definem onde agir primeiro.
O terceiro passo é correção com rastreabilidade. Corrigir parametrização sem documentar o que foi corrigido, em que data, com base em qual norma e com aprovação de qual responsável é trocar um problema por outro. A documentação da correção é a base da defesa para o período anterior.
Na DFS PRO, o diagnóstico começa por esse gap: o que está autorizado versus o que está em conformidade. Para operações com volume alto, essa diferença tem nome e valor. Se faz sentido quantificar antes que a fiscalização o faça, estou disponível.
TAKEAWAYS
Autorização é tecnológica. Conformidade é jurídica. O SAP executa o que foi configurado com fidelidade e escala. Se o que foi configurado não corresponde à legislação vigente, a fidelidade do sistema é exatamente o problema. A consistência do erro é o que vai ser apresentado como evidência quando a fiscalização cruzar os dados.
Artigo escrito por Emanuel Kaufman, Head of Business da DFS PRO. Especialista em operações fiscais críticas em SAP e Guepardo Tax. Curitiba, 2025. DFS PRO IT Solutions