Customização fiscal Z pode migrar sem erro técnico para o S/4HANA. E calcular o imposto errado.

Customização Z é qualquer desenvolvimento próprio (programa, campo, regra de determinação de imposto, exit, enhancement) criado sobre o SAP standard para atender uma necessidade específica da empresa que o sistema padrão não cobria. Na migração de ECC para S/4HANA, cada customização fiscal precisa ser triada individualmente antes da migração, porque o S/4HANA muda a arquitetura de dados subjacente (Universal Journal, novo modelo de dados fiscal, Clean Core como princípio de arquitetura), uma customização que funcionava no ECC pode simplesmente não existir mais como opção, ou pode existir e calcular diferente, sem gerar erro visível até o primeiro fechamento real no novo ambiente.

Onde a decisão para de ser técnica

A decisão de manter, remover ou reescrever cada customização depende do ambiente real de cada empresa e da tese tributária que ela adota, e essa parte segue sendo do cliente. O que a consultoria técnica entrega é a prova do comportamento do sistema em cada cenário: o que o código faz hoje, o que ele passa a fazer depois da migração, e onde os dois resultados divergem.

Por que customização fiscal exige atenção redobrada na migração

Diferente de uma customização de relatório ou de interface, uma customização na camada fiscal (determinação de imposto, cálculo de tributo, geração de obrigação acessória) tem uma característica perigosa: quando ela falha, frequentemente não falha com erro técnico visível, falha calculando um valor tecnicamente válido, mas fiscalmente incorreto. Um teste de migração que só verifica "o sistema processou sem erro" não detecta esse tipo de falha; só um teste que verifica "o resultado corresponde à regra tributária vigente para aquela combinação específica" detecta.

No ECC, a lógica de determinação de imposto costuma viver em tabela de condição do esquema de cálculo (o caso brasileiro tipicamente usa TAXBRJ ou TAXBRA como esquema base), e a customização Z entra como rotina de cálculo adicional ou user exit acoplado a esse esquema, lendo e escrevendo em tabelas clássicas de contabilidade (BSEG, BKPF) e de faturamento. No S/4HANA, o Universal Journal (a tabela ACDOCA) substitui boa parte dessa segregação de tabelas: os dados que antes viviam espalhados em BSEG, FAGLFLEXT e tabelas de totalizador agora convergem para uma fonte única. Uma customização Z que lia direto de uma tabela clássica continua compilando e rodando depois da migração técnica, porque a transação de entrada não muda, mas o dado que ela lê pode não estar mais naquele lugar com a mesma granularidade, e o retorno vazio ou parcial não gera erro de execução, só um resultado fiscal incompleto.

A ferramenta de SAP Readiness Check e o processo de Custom Code Migration apontam quais objetos customizados são tecnicamente afetados pela mudança de arquitetura (o que deixa de compilar, o que referencia um campo obsoleto, o que usa uma tabela simplificada ou eliminada). O que essas ferramentas não fazem é avaliar se a lógica de negócio fiscal continua correta depois de ajustada para compilar. Um relatório de Custom Code Migration limpo (sem erro de sintaxe ou de referência) prova que o código roda no S/4HANA, não prova que o valor que ele calcula ainda corresponde à regra tributária vigente.

Teste de regressão fiscal, nesse contexto, tem um critério objetivo e diferente do teste técnico padrão: não basta rodar a mesma massa de dados nos dois ambientes e confirmar ausência de erro (dump, short dump, mensagem de erro de sistema). É preciso comparar o valor calculado campo a campo, operação a operação, entre o ambiente ECC de origem e o S/4HANA de destino, para a mesma combinação de produto, operação e estado. Uma divergência de poucos centavos numa base de cálculo, replicada em volume, é estatisticamente invisível num teste que só verifica execução e financeiramente relevante num fechamento real.

A regra que quebra customização antiga: o crédito passa a depender de COMO o débito foi extinto

Existe uma mudança de modelo de dados que nenhuma ferramenta de código customizado aponta, porque ela não está no ABAP, está na lei. O art. 27 da LC 214/2025 lista cinco modalidades de extinção do débito de IBS e CBS: compensação com créditos, pagamento pelo contribuinte, recolhimento na liquidação financeira da operação (split payment), recolhimento pelo adquirente, e pagamento por quem a lei atribuir responsabilidade.

O parágrafo único é a parte que muda o desenho. Nas hipóteses de compensação e de pagamento pelo contribuinte, a extinção é imputada aos débitos não extintos do período de apuração na ordem cronológica do documento fiscal. Nas hipóteses de split payment e de recolhimento pelo adquirente, ela é vinculada à respectiva operação. São duas lógicas diferentes convivendo no mesmo período: uma trabalha por fila cronológica do período, a outra por amarração documento a documento.

Uma rotina Z escrita na lógica antiga trata a apuração como um agregado do período e não guarda, por operação, qual modalidade extinguiu o débito. Ela vai continuar compilando no S/4HANA e vai continuar devolvendo um número. O número é que deixa de significar a mesma coisa, porque o art. 47 condiciona o crédito do adquirente à extinção do débito daquela operação. Sem o vínculo operação a operação, não há como provar quando o crédito nasceu, e o prazo de 5 anos do art. 54 começa a correr de qualquer forma. Esse é o tipo de divergência que nenhum teste de execução sem erro encontra, e que um teste de regressão fiscal encontra na primeira comparação campo a campo.

O checklist de triagem de customização Z

Cada customização fiscal identificada no ambiente ECC deveria passar por esta triagem antes da migração:

1. Mantém: a customização atende uma necessidade real, ainda vigente, que o S/4HANA standard não cobre, e a lógica dela é compatível com a nova arquitetura de dados (Universal Journal, novo modelo fiscal). Critério de decisão: a necessidade de negócio que originou a customização ainda existe hoje?

2. Remove: a customização resolvia uma limitação do SAP standard antigo que o S/4HANA já resolve nativamente, ou atendia uma regra de negócio ou legislação que não existe mais. Critério de decisão: se a customização fosse desligada hoje, algum processo real quebraria?

3. Reescreve: a necessidade de negócio ainda existe, mas a lógica original não é compatível com a nova arquitetura (por exemplo, lê uma tabela que muda de estrutura no S/4HANA, ou depende de um campo que migra para outro modelo de dados). Critério de decisão: a lógica de negócio se mantém, mas a implementação técnica precisa ser refeita para a nova arquitetura.

Onde a triagem costuma falhar

1. Customização de determinação de imposto: lógica própria de cálculo de tributo, condição de preço customizada. Alto risco, porque o resultado incorreto raramente gera erro técnico visível.

Isso vale com força extra para customizações que alimentam a integração entre o SAP e o Guepardo Tax: se a origem do dado muda de estrutura no S/4HANA e a interface com o motor fiscal não é retriangulada, o Guepardo pode continuar recebendo um dado formalmente válido e processando normalmente, sem qualquer sinal de erro do lado dele, porque o problema nasceu antes, na camada de extração do SAP.

2. Customização de leitura direta de tabela: comum em relatórios fiscais próprios construídos direto sobre tabela ECC, quando essa tabela muda de estrutura no S/4HANA. Costuma falhar silenciosamente, retornando dado incompleto ou desatualizado sem erro de execução.

3. Enhancement em geração de obrigação acessória: SPED, NF-e. Precisa ser retestado contra o leiaute vigente na data da migração, não só contra o leiaute que existia quando a customização foi criada originalmente.

4. Regra fiscal hardcoded: valor, alíquota ou condição fixada diretamente no código, sem parametrização. O risco típico aqui é a regra sobreviver à migração tecnicamente intacta, mas desatualizada em relação à legislação vigente, porque nada no processo de migração aciona uma revisão de conteúdo fiscal.

Quando uma dessas divergências aparece só no primeiro fechamento real do ambiente novo, quem precisa explicar a diferença não é o time de Basis que executou a migração técnica, é o Diretor Fiscal ou o Head de Tax que assina o resultado daquele ciclo. A migração para S/4HANA costuma ser tratada, no cronograma do projeto, como um marco de TI: sistema no ar, performance validada, usuários treinados. A triagem de customização Z fiscal raramente aparece como marco formal de aceite, o que significa que, sem essa triagem explícita, o go-live técnico é assinado antes de qualquer prova de que o cálculo fiscal se manteve correto na travessia.

Sinais de que a triagem ainda não foi feita

Antes de aceitar o go-live técnico, vale medir quantos destes quatro sinais estão presentes. Três ou mais é o cenário em que o Diagnóstico Fiscal Estruturado costuma entrar antes da virada, e não depois dela.

• Não existe um inventário completo das customizações fiscais ativas no ambiente ECC atual, sem isso, não é possível nem começar a triagem.
• O plano de teste de migração não distingue teste técnico (processa sem erro) de teste fiscal (resultado correto para a legislação vigente).
• Nenhuma customização foi ainda mapeada contra o princípio de Clean Core do S/4HANA (minimizar customização no core, mover extensão para camada apropriada).
• A decisão de manter/remover/reescrever está sendo feita por critério de esforço de desenvolvimento, sem antes verificar se a necessidade de negócio original ainda existe.

Perguntas frequentes

Toda customização Z precisa ser removida no S/4HANA?
Não. O princípio de Clean Core recomenda minimizar customização no core do sistema, mas isso não significa remover toda customização, significa avaliar cada uma e, quando necessário, mover a lógica para uma camada de extensão apropriada em vez do core.

Quem decide se uma customização deve ser mantida, removida ou reescrita?
A avaliação técnica (a lógica ainda é necessária? é compatível com a nova arquitetura?) é trabalho da consultoria técnica. A decisão final, principalmente quando envolve tese tributária, é sempre do cliente.

Um teste de migração bem-sucedido garante que a parametrização fiscal está correta?
Não necessariamente. Um teste que só verifica execução sem erro não captura erro de cálculo fiscal. É preciso teste específico que valide o resultado contra a regra tributária vigente para cada combinação relevante de produto, operação e estados.

Isso é diferente de reescrever a customização "igual, mas em ABAP moderno"?
Sim. Reescrever com a mesma lógica de negócio, só trocando a sintaxe técnica, não resolve o problema se a lógica de negócio original já estava desatualizada em relação à legislação vigente, a triagem precisa avaliar a lógica de negócio, não só a sintaxe.

Esse checklist de triagem é o mesmo checklist de auditoria fiscal SAP já publicado no site?
Não. O checklist de auditoria fiscal SAP (publicado em Diagnóstico Fiscal SAP) avalia o ambiente fiscal em geral, incluindo reconciliação, retrabalho e rastreabilidade. A triagem descrita aqui é específica para a decisão de manter, remover ou reescrever cada customização Z identificada num contexto de migração ECC para S/4HANA.

Se sua empresa está migrando para o S/4HANA e ainda não tem o inventário completo das customizações fiscais triado, o Diagnóstico Fiscal Estruturado mapeia esse risco antes do primeiro fechamento no novo ambiente.

Veja também a página de Migração ECC → S/4HANA e a metodologia completa da DFSpro.