O incentivo fiscal expira. Se o SAP continuar aplicando, quem explica é o CIO.

Toda empresa com operações em estados que usam benefícios fiscais de ICMS para atrair investimento tem esses benefícios parametrizados no SAP. Tax Codes configurados. Regras de apuração ajustadas. Exceções mapeadas por estado e por produto.

Cada um desses benefícios tem prazo de expiração no texto da LC 214/2025 e nas regras de transição da Reforma Tributária (Emenda Constitucional 132/2023). Quando o prazo vencer, o benefício precisa sair da parametrização. A operação fiscal do SAP precisa refletir a mudança antes de o SPED do período ser transmitido.

O problema é que ninguém mapeou quantas dessas mudanças de configuração vão acontecer, em qual sequência, em qual prazo, e se existe um processo definido para executá-las sem criar risco de apuração incorreta entre a data de expiração do benefício e a data de atualização do SAP.

Esse gap de processo vai aparecer como erro de sistema. E o CIO vai ser chamado para explicar.

O que a Reforma faz com os incentivos fiscais regionais

A LC 214/2025 estabelece que os benefícios fiscais de ICMS concedidos pelos estados vão ser progressivamente eliminados durante o período de transição para o IBS. O mecanismo de eliminação considera dois componentes: a substituição do ICMS pelo IBS ao longo do período de coexistência, e a extinção dos benefícios estaduais à medida que o IBS assume a função do tributo que os originou.

Para empresas com múltiplos benefícios em múltiplos estados, isso significa que o cronograma da Reforma não é um evento único. É uma sequência de mudanças tributárias distribuídas ao longo de sete anos, cada uma com impacto em parametrização SAP específica.

O impacto não é uniforme por estado. Estados com maior dependência de incentivos fiscais para atrair investimento, como as regiões Norte, Nordeste e parte do Centro-Oeste, têm maior volume de benefícios de ICMS que precisarão ser eliminados. Estados com base tributária mais diversificada têm menos. Para grupo multiestadual com operações em estados de diferentes perfis de incentivo, o mapeamento precisa ser feito por unidade operacional, não no agregado.

Por que esse impacto vai aparecer no SAP antes de aparecer no time fiscal

O processo padrão de gestão de mudança tributária na maioria das empresas funciona assim: legislação muda, time fiscal identifica a mudança, time fiscal comunica para TI, TI abre chamado, chamado é atendido, SAP é atualizado.

Esse processo tem um intervalo de tempo entre a mudança legislativa e a atualização do sistema. Em mudanças de ICMS que acontecem com frequência mensal, esse intervalo é gerenciado porque o time fiscal e o time de TI têm rotina estabelecida de atualização.

A Reforma Tributária vai criar um tipo diferente de mudança: eliminações de benefícios fiscais com datas determinadas por lei, distribuídas ao longo de vários anos, em múltiplos estados, com diferentes regras de transição por tipo de benefício. Esse volume e essa distribuição temporal são diferentes do que o processo atual de gestão de mudança tributária está calibrado para absorver.

O que vai acontecer quando um benefício expirar e o SAP ainda não foi atualizado: o sistema vai continuar aplicando o benefício revogado. A apuração de ICMS vai estar incorreta. O SPED vai ser transmitido com o dado incorreto. O time fiscal vai descobrir quando a SEFAZ ou o Comitê Gestor do IBS questionar o aproveitamento do benefício que já expirou.

O CIO vai ser chamado quando o SPED voltar com problema ou quando a auditoria interna identificar que o sistema aplicou benefício após a data de expiração. A pergunta vai ser: por que o SAP não foi atualizado? E a resposta “o chamado estava na fila” não vai ser satisfatória quando o volume de benefícios expirados na fila for grande.

O que o Gerente SAP precisa saber que o time fiscal não vai contar

O time fiscal vai acompanhar a Reforma do ponto de vista jurídico-tributário: vai monitorar regulamentações, vai avaliar o impacto em cada benefício, vai comunicar as mudanças quando elas forem formalmente publicadas.

O que o time fiscal não vai mapear, porque não é função dele, é a consequência de cada mudança jurídica na configuração SAP: quais Tax Codes precisam ser revisados, qual o impacto em outras regras que dependem do Tax Code que está sendo eliminado, qual é o processo de teste antes de a mudança ir para produção, e qual é o prazo mínimo entre a comunicação da mudança e a atualização do sistema com teste completo.

Esse mapeamento é responsabilidade do Gerente SAP. E o Gerente SAP que não fez esse mapeamento vai descobrir o tamanho do problema quando o primeiro benefício expirar e a fila de chamados de configuração fiscal não tiver capacidade para processar a mudança no prazo necessário.

As três perguntas por benefício parametrizado

Há três perguntas que o Gerente SAP precisa conseguir responder agora sobre cada benefício fiscal de ICMS que está parametrizado no SAP :

1. Qual é a data prevista de expiração desse benefício conforme as regras de transição da Reforma? Se a resposta depender de o time fiscal consultar a legislação, o processo de gestão da mudança ainda não foi desenhado do ponto de vista sistêmico.
2. Quantas mudanças de configuração SAP essa expiração vai exigir? Tax Code de ICMS, regras de apuração, exceções por produto, integrações com Guepardo Tax, relatórios de controle que dependem dessa regra. O volume de configurações afetadas determina o prazo mínimo necessário para atualização com teste adequado.
3. Terceira: existe um processo definido para executar essa mudança antes de a data de expiração acontecer, com tempo suficiente para teste? Se não existe, a primeira expiração vai ser gerenciada em modo emergência, com risco de apuração incorreta no intervalo.

O que precisa existir antes de o calendário de expirações começar

Quatro processos precisam estar definidos antes de os primeiros benefícios fiscais regionais começarem a ser eliminados pela Reforma.

1. Inventário de benefícios por estado e por configuração SAP: para cada benefício fiscal de ICMS parametrizado no SAP, um registro que mostre: qual é o benefício, em qual estado, para qual produto ou operação, em qual Tax Code está configurado, e quais outras configurações SAP dependem desse Tax Code. Esse inventário não existe na maioria das operações porque nunca foi necessário. Com a Reforma, ele se torna o ponto de partida para qualquer gestão de mudança.

2. Calendário de expiração ligado ao inventário: para cada benefício do inventário, qual é a data prevista de eliminação sob as regras de transição da Reforma? Esse calendário precisa ser alimentado pelo time fiscal e gerenciado como backlog de mudanças SAP, não como lista de alterações legislativas.

3. Processo de atualização com prazo definido: quando o time fiscal comunicar que um benefício vai expirar em determinada data, qual é o tempo mínimo necessário para atualizar o SAP com teste completo? Esse prazo precisa estar acordado entre Fiscal e TI antes da primeira expiração, não negociado em modo de urgência quando a data estiver chegando.

4. Processo de verificação pós-atualização: depois de cada mudança de configuração SAP decorrente de expiração de benefício, existe uma verificação de que a apuração do período seguinte está correta, antes de o SPED ser transmitido? Essa verificação precisa ser parte do processo, não uma ação de contingência.

O que a DFSpro faz nesse ponto específico

A gestão de mudança de configuração SAP decorrente de eliminação de benefícios fiscais regionais pela Reforma não é trabalho de consultoria tributária. É trabalho de arquitetura fiscal SAP com conhecimento da Reforma.

Esse mesmo tipo de gap de configuração sem dono aparece quando o Guepardo roda sem processo de revisão de regra, e o cronograma de expiração de benefícios é parte do mesmo histórico fiscal que está sendo gravado com data e assinatura desde 2026Na DFSpro, o mapeamento de impacto da Reforma em configurações SAP começa pelo inventário de benefícios parametrizados e pelo calendário de expiração. O resultado é um backlog de mudanças SAP com prazo, volume de configurações afetadas e processo de atualização por mudança. Se faz sentido ter esse mapeamento antes de o primeiro benefício expirar sem processo definido, o Diagnóstico Fiscal Estruturado começa exatamente por esse inventário.

O benefício não desaparece sozinho, e a compensação não é automática

Existe uma leitura tranquilizadora que circula sobre esse tema: os benefícios acabam, mas há um fundo de compensação, então o impacto está coberto. A letra da LC 214/2025 impõe três condições a essa frase, e cada uma delas tem consequência direta no que precisa estar parametrizado e documentado.

A primeira está no sujeito. O art. 384 determina que sejam compensadas as pessoas físicas ou jurídicas titulares de benefícios onerosos relativos ao ICMS, em função da redução do nível desses benefícios decorrente do art. 128 do ADCT. Benefício oneroso é aquele em que houve contrapartida assumida pelo titular. Quem tem benefício concedido sem contrapartida não está descrito nesse artigo.

A segunda está na janela. A compensação alcança a redução no período entre 1º de janeiro de 2029 e 31 de dezembro de 2032. É um intervalo fechado, com início e fim, e não cobre o que acontecer fora dele.

A terceira é a que mais impacta a rotina, e é a que costuma ser esquecida: a compensação segue os critérios e limites para apuração do nível de benefícios e de sua redução, e os procedimentos de análise dos requisitos para habilitação do requerente. Habilitação é processo, com requisito a comprovar. Não é consequência automática de ter o benefício.

Junte as três e o problema deixa de ser tributário e vira documental. Para se habilitar, a empresa precisa demonstrar o nível do benefício e a redução dele. Isso exige saber, por período e por operação, qual benefício foi aplicado, com que fundamento e em que medida. Essa informação nasce na parametrização, e morre com ela se o Tax Code for alterado sem registro do que valia antes.

É aí que o risco de configuração encontra o risco de compensação. Um benefício que continua sendo aplicado depois da expiração gera passivo, que é o assunto até aqui. Um benefício que foi aplicado corretamente, mas sem trilha que permita demonstrar o nível dele, gera outra coisa: perda de direito por falta de prova. O primeiro aparece em autuação, o segundo aparece como um pedido de habilitação que não se sustenta, e nenhum dos dois dispara alerta no sistema enquanto acontece.

Artigo escrito por Emanuel Kaufman, Head of Business da DFSpro. Especialista em operações fiscais críticas em SAP e Guepardo Tax. Curitiba, 2026. DFSpro