O projeto de migração para S/4HANA não começa como projeto fiscal. Começa como projeto de TI: modernização de plataforma, roadmap de fornecedor, pressão de suporte ao ECC, demanda de negócio por sistema mais atual. O fiscal entra depois. Como área consultada. Como validador de escopo. Como alguém que vai “homologar o fiscal” numa das últimas fases.
Esse sequenciamento tem uma consequência que raramente aparece no plano de projeto: o SAP ECC não é um sistema que mostra seus problemas. É um sistema que aprende a conviver com eles.
Quando a migração acontece, o que estava convivendo para de existir. E o que estava sendo sustentado aparece.
O que o ECC aprendeu a não mostrar
Todo SAP ECC com mais de cinco anos de operação acumula camadas. Não por descuido, mas por sobrevivência operacional. Uma customização Z criada para contornar uma limitação de parametrização nativa que nunca foi corrigida. Um processo manual de fechamento que ajusta o que o sistema gera antes de entrar no SPED. Um Tax Code de ICMS que parou de ser revisado quando o consultor que o mantinha saiu da empresa. Uma integração com sistema satélite que funciona porque alguém no time de TI sabe exatamente qual campo mapear manualmente quando o dado chega inconsistente.
Essas camadas não aparecem como problema no ECC porque o ECC, ao longo do tempo, foi adaptado para sustentá-las. O sistema processa, o fechamento acontece, o SPED sai. O que está errado fica escondido atrás do que está funcionando.
O S/4HANA não tem essas camadas de compensação. Ele não sabe que a customização Z existia para compensar uma parametrização incorreta. Não sabe que o processo manual corrigia o que o Tax Code gerava de errado. Não sabe que a integração dependia de um campo mapeado manualmente que não foi documentado.
Quando o S/4HANA entra, ele processa a regra fiscal que está parametrizada. Sem compensação. Sem ajuste. Sem o processo manual que existia no lado do ECC. O que estava escondido aparece no primeiro fechamento pós-go-live. Com data. Com operação identificada. Com volume de nota que o time de fiscal precisa explicar.
Por que a fase de homologação não pega o que importa
O sequenciamento mais comum em projetos de S/4HANA: escopo definido por TI com base em funcionalidades e módulos. Fiscal entra na fase de homologação para validar que as operações estão processando corretamente. Go-live aprovado quando o sistema fecha sem erro sistêmico aparente.
O problema está no critério de aprovação. “Sem erro sistêmico aparente” é o critério certo para validar que o sistema está funcionando tecnicamente. É o critério errado para validar que a arquitetura fiscal está correta.
O que a fase de homologação não consegue identificar num prazo de teste reduzido: Tax Codes transportados do ECC sem revisão de legislação vigente para o período atual. CFOPs que foram assumidos como corretos porque o ECC estava usando aqueles CFOPs. Regras de ICMS-ST com MVA desatualizado que foram migradas sem verificação de tabela estadual atual. Customizações Z declaradas fora de escopo de clean core que continham lógica de negócio fiscal não documentada em nenhum outro lugar.
Quando o time fiscal encontra esses problemas na homologação, o projeto já tem data de go-live aprovada, escopo fechado e mudança de escopo é change request com custo e resistência. O que era diagnóstico preventivo vira negociação de projeto.
As quatro dependências que nenhum escopo de S/4HANA documenta espontaneamente
Na DFSpro, chamamos essas quatro dependências de As 4 Dependências Ocultas.
1. Customização Z-fiscal com lógica de negócio incorporada: a maioria foi documentada como ajuste técnico de sistema, não como regra fiscal. A lógica que ela carrega só aparece quando é removida e o cálculo muda. Em projeto de clean core, essas customizações são candidatas à descontinuação, e o risco é descontinuar algo que estava compensando uma parametrização nativa incorreta sem ninguém perceber o que era compensado.
2. Integração com satélite de impacto fiscal não documentado: faturamento terceirizado, plataforma de e-commerce, ERP legado de subsidiária. Cada ponto de integração é um ponto onde dado fiscal entra ou sai. No ECC essas integrações foram ajustadas ao longo de anos por gente que já saiu do projeto; no S/4HANA precisam ser revalidadas do zero. O risco é o comportamento fiscal mudar sem que ninguém tenha mapeado o motivo.
3. Processo manual que corrige o que o sistema gera: em toda operação SAP com histórico longo existem rotinas de fechamento com correção de dado, ajuste de lançamento e validação manual que fazem parte do processo sem estar em procedimento formal nenhum. Na migração, elas precisam ser identificadas e viradas em configuração nativa, nunca descontinuadas por omissão.
4. Regra de ICMS, ICMS-ST, PIS e Cofins que mudou desde a implantação do ECC: legislação estadual muda, benefício expira, protocolo interestadual é revisado, alíquota muda por reclassificação de NCM. Em muitas operações essas mudanças foram absorvidas por ajuste manual sem atualizar a parametrização nativa. O S/4HANA herda a defasagem se o levantamento não for feito antes.
O que sobra do ECC dentro do S/4HANA, e o que não sobra
Vale nomear onde essa transferência acontece de fato, porque "migrar o fiscal" é uma expressão que esconde três movimentos diferentes, com riscos diferentes. O primeiro é o procedimento de cálculo: uma operação que rodava no procedimento baseado em jurisdição, o TAXBRJ, e passa para o TAXBRA, ou que já estava em TAXBRA mas com anos de ajuste em cima, não leva junto o histórico de por que cada decisão foi tomada. O que viaja é o resultado, não o motivo.
O segundo é o cadastro que alimenta esse cálculo, mantido pela J1BTAX e pela FTXP ao longo de anos por pessoas diferentes, com critérios que nunca foram escritos. O terceiro é a camada de BAdI e customização Z construída para cobrir o que os dois primeiros não resolviam. É a terceira que o projeto de clean core mira primeiro, e é justamente a que carrega a regra fiscal que ninguém documentou.
A pergunta operacional que separa um levantamento de verdade de uma homologação de escopo cabe numa linha: para cada combinação crítica de operação, produto e estado, quem consegue explicar por que o resultado é esse, apontando o objeto onde a regra mora? Se a resposta depende de uma pessoa específica, o objeto existe mas a documentação não, e a migração vai transportar o resultado sem transportar o entendimento.
A colisão de calendário que quase nenhum plano de projeto trata
Há um agravante de 2026 que muda o peso de tudo o que foi dito até aqui, e ele não aparece no plano de projeto porque pertence a outra conversa dentro da empresa. A LC 214/2025 fixa, para os fatos geradores de 1º de janeiro a 31 de dezembro de 2026, IBS a 0,1% (art. 343) e CBS a 0,9% (art. 346). Valores baixos, que sustentam a leitura de que este é um ano de ensaio. O art. 348 desmonta essa leitura por um caminho que raramente é citado: pelo § 1º, fica dispensado o recolhimento de IBS e CBS em 2026 apenas em relação aos sujeitos passivos que cumprirem as obrigações acessórias previstas na legislação.
Ou seja: a dispensa não é automática, é contrapartida. O que compra a dispensa de 2026 é a declaração correta. E a declaração correta sai do mesmo sistema que o projeto de migração está trocando.
É aí que os dois calendários colidem. Uma empresa que migra para S/4HANA durante 2026 fica, por alguns meses, com duas bases em movimento ao mesmo tempo: a arquitetura fiscal mudando de ambiente e a obrigação acessória nova sendo gerada por esse ambiente em mudança. Quando aparecer uma divergência na apuração paralela, a pergunta inevitável vai ser se ela veio da regra nova ou da migração. Sem levantamento prévio, a resposta honesta é que não dá para saber, e essa é a pior resposta possível para quem assina o fechamento.
O ponto prático para quem está montando cronograma: o diagnóstico fiscal prévio deixa de ser só uma proteção contra o primeiro fechamento pós go-live e passa a ser também a linha de base que permite separar, depois, o efeito da migração do efeito da Reforma. Sem essa linha de base medida antes, os dois efeitos ficam misturados no mesmo número, e o time perde a capacidade de explicar qualquer um dos dois.
O custo que aparece no primeiro fechamento pós-go-live
O primeiro fechamento pós-go-live de S/4HANA sem diagnóstico fiscal prévio tem um padrão previsível: apuração inconsistente com o que o ECC gerava no período equivalente. SPED com diferenças que o time não consegue explicar porque não sabe o que mudou entre os dois ambientes. Tax Codes que estavam funcionando no ECC gerando resultado diferente no S/4HANA por causa de diferença de comportamento do módulo.
Esse momento é o pior para fazer o diagnóstico porque a operação está rodando no sistema novo sem margem para parar, o time do projeto já foi desmobilizado, e cada ajuste vira change request de suporte pós-go-live com custo e prazo que o orçamento não contemplou.
O mesmo diagnóstico feito antes do go-live, na fase de design, custa uma fração do esforço. E entrega algo que o diagnóstico pós-go-live não consegue: tempo para corrigir antes de o sistema entrar em produção com regra fiscal errada.
A empresa que faz o diagnóstico antes do go-live ainda vai ter trabalho. Mas vai ter tempo para fazer esse trabalho com método. A empresa que faz depois vai fazer com urgência, com operação impactada e com a pressão de explicar ao CIO por que o go-live funcionou tecnicamente e falhou fiscalmente.
Esse é o tipo de explicação que o Gerente SAP não quer estar dando.
Esse mesmo mapeamento de combinações tributárias críticas é o que sustenta o plano de teste fiscal que garante que o go-live não aprova só a parte técnica. Na DFSpro, o Diagnóstico Fiscal Estruturado antes de projetos de S/4HANA mapeia exatamente essas dependências: o que o ECC está sustentando que o S/4HANA não vai sustentar automaticamente. Se o projeto está em planejamento ou em andamento, ainda há janela. Depois do go-live, o diagnóstico revela o problema. Antes, ele evita.
TAKEAWAYS
- O S/4HANA não é destino de chegada. É revelador.
- O que o ECC estava sustentando aparece no novo sistema no primeiro fechamento, sem as camadas de compensação que tornavam o problema invisível.
- Migração sem diagnóstico fiscal não entrega clean core.
- Entrega o mesmo risco em plataforma nova, com menos margem de ajuste e com go-live aprovado como evidência de que “estava funcionando”.
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