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
A primeira são as customizações Z-fiscais com lógica de negócio incorporada. A maioria dessas customizações foi documentada como “ajuste técnico de sistema”, não como “regra fiscal”. A lógica fiscal que elas carregam só aparece quando são removidas e o cálculo muda. Em projetos de clean core, essas customizações são candidatas à descontinuação. O risco é descontinuar algo que estava compensando uma parametrização nativa incorreta sem perceber o que estava sendo compensado.
A segunda são as integrações com sistemas satélite com impacto fiscal não documentado. Sistemas de faturamento terceirizados, plataformas de e-commerce, ERPs legados de subsidiárias. Cada ponto de integração é um ponto onde dado fiscal entra ou sai. No ECC, essas integrações foram ajustadas ao longo do tempo por pessoas que já não estão mais no projeto. No S/4HANA, precisam ser revalidadas do zero. O risco é o comportamento fiscal da integração que funcionava no ECC não funcionar da mesma forma no S/4HANA sem que ninguém tenha mapeado o motivo.
A terceira são os processos manuais que corrigem o que o sistema gera. Em toda operação SAP com histórico longo, existem rotinas de fechamento que incluem correções de dado, ajustes de lançamento e validações manuais que fazem parte do processo sem que estejam documentadas em nenhum procedimento formal. Quando o S/4HANA entra, essas rotinas precisam ser identificadas e transformadas em configuração nativa, não descontinuadas por omissão.
A quarta são as regras de ICMS, ICMS-ST, PIS e COFINS que mudaram desde a implantação do ECC. Legislação estadual muda com frequência. Benefícios expiram. Protocolos interestaduais são revisados. Alíquotas de produtos são alteradas por reclassificação de NCM. Em muitas operações, essas mudanças foram absorvidas por ajuste manual sem que a parametrização nativa tivesse sido atualizada. O S/4HANA vai herdar essas defasagens se ninguém fizer o levantamento antes da migração.
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.
Na DFS PRO, 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 DFS PRO. Especialista em operações fiscais críticas em SAP e Guepardo Tax. Curitiba, 2025. DFS PRO IT Solutions