2027 junta duas decisões: o fim da manutenção do SAP ECC e a CBS plena no mesmo calendário

Duas datas convergem para 2027 sem que a maioria das equipes de SAP as trate como a mesma decisão. A Lei Complementar 214/2025, no artigo 347, fixa a alíquota da CBS plena a partir de 1º de janeiro de 2027, reduzida em 0,1 ponto percentual durante o biênio de transição; o mesmo diploma revoga PIS e Cofins na mesma data, pelo artigo 542. Segundo imprensa técnica especializada (Baguete, 2024), o mesmo ano marca o encerramento da manutenção mainstream do SAP ECC, informação ainda não conferida em fonte oficial da SAP neste levantamento. Reforma tributária e fim de suporte do ERP convergem para o mesmo ano, e normalmente são tratadas por times diferentes, com calendários que nunca se encontram numa mesa só.

Duas decisões no mesmo ano não significam uma decisão só.

As duas datas de 2027, e de onde cada uma vem

A data da CBS plena tem fonte legal direta: o artigo 347 da LC 214/2025 trata dos fatos geradores ocorridos entre 1º de janeiro de 2027 e 31 de dezembro de 2028, fixando a alíquota da CBS com uma redução de 0,1 ponto percentual sobre o valor de referência definido no artigo 14. O artigo 542 da mesma lei revoga, na mesma data, a legislação de PIS e Cofins. Essa é norma pública, com identificação clara de artigo e vigência.

A data do fim da manutenção mainstream do ECC tem origem diferente: vem de cobertura de imprensa técnica especializada, que relata a meta da empresa de software de migrar a base instalada até 2027, quando deixaria de oferecer manutenção padrão para o produto. Essa informação não foi confirmada neste levantamento em comunicado oficial da própria SAP, o que não a torna falsa, mas exige tratá-la como fonte secundária, sujeita a atualização pela empresa que desenvolve o sistema.

O que importa não é qual das duas fontes é mais forte. É que as duas apontam para o mesmo ano, de origens completamente independentes: uma é decisão de política tributária do Congresso Nacional, a outra é decisão comercial de ciclo de vida de produto de uma empresa de software. A coincidência de calendário não foi planejada por nenhum dos dois lados, e justamente por isso pega desprevenida qualquer empresa que trate as duas agendas como projetos separados, com equipes, orçamentos e prioridades que não se falam.

Há ainda um terceiro fator que raramente entra nessa conta: cobertura de outra publicação técnica especializada (Convergência Digital, 2025) menciona o risco de parar a operação em janeiro sem adequação adequada à reforma, reforçando que o problema não é hipotético nem exclusivo de quem pensa em migrar. Mesmo quem decidir permanecer no ECC além de 2027 precisa resolver a adequação fiscal, independentemente da decisão de plataforma.

Essa cobertura é consistente em apontar o mesmo risco por ângulos diferentes: uma fala do fim de manutenção como decisão comercial da empresa de software, outra fala de risco de parada operacional sob a ótica fiscal. Convergência de ângulos independentes, ainda que vinda de fontes secundárias, é um sinal que merece atenção, mesmo sem confirmação em comunicado oficial.

O que a tropicalização fiscal carrega para o S/4HANA

Tropicalização fiscal é o conjunto de customizações, tabelas, exits e regras que adaptam o SAP padrão à legislação brasileira: determinação de ICMS, ICMS-ST, PIS, Cofins, regras de CFOP, cálculo de substituição tributária, e agora também IBS e CBS. Essa camada não é pequena, e normalmente acumula anos de ajuste incremental, feito por diferentes equipes e diferentes fornecedores de AMS ao longo do tempo.

A tropicalização fiscal de um ambiente ECC não migra automaticamente para o S/4HANA. Ela precisa ser reavaliada, porque o S/4HANA tem arquitetura de dados e modelo de determinação tributária diferentes do ECC clássico, mesmo quando a lógica de negócio é parecida. Migrar sem reavaliar essa camada é o erro mais caro: carregar para o ambiente novo uma customização pensada para um regime tributário que, a partir de 2027, já não existe mais na forma antiga.

O movimento que o mercado chama de clean core, adotar o S/4HANA com o mínimo possível de customização proprietária, reforçando a lógica padrão da SAP e isolando extensões em camadas bem definidas, torna essa reavaliação ainda mais relevante para a área fiscal. Uma customização de ICMS-ST feita há oito anos, por exemplo, pode ter sido necessária por uma limitação específica do ECC que o S/4HANA já resolve de forma nativa. Carregar essa customização para o ambiente novo sem questionar se ela ainda é necessária é desperdiçar exatamente o tipo de simplificação que o clean core promete entregar.

Isso cria um dilema de sequência genuíno. Adequar a CBS no ECC primeiro, e migrar para o S/4HANA depois, significa testar o desenho fiscal novo duas vezes: uma vez no ambiente antigo, outra vez no ambiente novo, porque a arquitetura diferente exige reteste completo, não apenas transporte de configuração. Migrar primeiro para o S/4HANA, e só depois adequar a CBS, significa migrar uma tropicalização que já está prestes a ficar obsoleta, desperdiçando esforço de migração numa camada que vai precisar de retrabalho logo em seguida.

Há um terceiro risco, mais silencioso: customizações que atravessam módulos. Uma regra de determinação fiscal que hoje interage com o módulo de vendas, o módulo de faturamento e o módulo financeiro num ambiente ECC não necessariamente preserva essa mesma interação no S/4HANA, porque a arquitetura unificada do HANA muda a forma como esses módulos trocam dado em tempo real. Mapear cada ponto de interação antes da migração evita que uma regra funcione isoladamente em teste, mas falhe quando os três módulos interagem em produção.

Vale ainda considerar o papel da solução fiscal acoplada, quando houver, nessa equação. Uma solução de terceiro parametrizada há anos sobre o ECC carrega seu próprio conjunto de regras e versões de compatibilidade, e migrar o ERP sem verificar se essa solução já tem versão homologada para S/4HANA pode travar a migração inteira num componente que ninguém tratou como crítico até o momento do corte.

Compatibilidade de versão não é detalhe de rodapé de contrato.

Sequência possível, e o custo de cada escolha

Não existe sequência sem custo. A pergunta certa não é "qual sequência evita custo", é "qual sequência o custo é menor e mais previsível para a sua operação específica".

Uma primeira sequência possível é desenhar a adequação fiscal da CBS já pensando no modelo de dados do S/4HANA, mesmo que a implementação técnica aconteça primeiro no ECC como solução de transição. Isso exige que o time de arquitetura fiscal participe do desenho da migração desde o início, não seja chamado depois para "ajustar o fiscal" num cronograma já fechado por TI.

Uma segunda sequência possível é acelerar a decisão de migração para que ela aconteça antes da virada de 2027, com a tropicalização da CBS sendo desenhada diretamente no ambiente novo, evitando o retrabalho de adequar o ECC para um regime que vai durar pouco tempo naquele ambiente. Essa rota exige decisão de orçamento e cronograma muito mais rápida do que a maioria das empresas está acostumada a tomar para um projeto de migração de ERP.

Uma terceira possibilidade, menos discutida, é permanecer no ECC além de 2027 mediante contrato de manutenção estendida, quando disponível, enquanto a migração é planejada com mais calma. Essa rota reduz a pressão de prazo, mas não elimina a necessidade de adequar a CBS no ambiente atual, e normalmente tem custo de manutenção mais alto do que o contrato padrão, o que precisa entrar na conta ao comparar as três rotas.

Comparar o custo total de cada rota exige mais do que orçamento de licença ou de serviço de migração.

Entra também o custo de oportunidade de manter dois ambientes em modo de transição por mais tempo do que o necessário, com equipe dividida entre sustentar o legado e aprender a plataforma nova, o que raramente aparece como linha explícita em nenhuma das três propostas orçamentárias comparadas. Esse custo tende a crescer, não encolher, quanto mais a decisão é adiada, porque a pressão de prazo encurta as janelas disponíveis de homologação em qualquer uma das três rotas escolhidas.

Qualquer que seja a sequência escolhida, ela precisa ser uma decisão única, documentada, e não a soma de duas decisões tomadas separadamente por times que não conversaram entre si. O custo real da falta de sequência não é financeiro apenas: é o risco de o ambiente fiscal falhar justamente no momento em que a CBS entra plena, porque ninguém testou o cenário de transição completo, do início ao fim.

O encerramento da manutenção mainstream do ECC pela SAP não é um prazo técnico de software; é um ultimato de negócios. E no Brasil, ele chega com uma camada adicional de complexidade.

O que decidir em 2026, e a governança da sequência

A pergunta executiva que a diretoria de TI e a diretoria fiscal precisam responder juntas, ainda em 2026, é direta: na linha do tempo da empresa, a adequação da CBS acontece antes ou depois da decisão de plataforma, e quem responde pela sequência escolhida?

Se essa pergunta não tem resposta hoje, a decisão está sendo tomada por omissão: cada área seguindo seu próprio cronograma, sem que ninguém tenha comparado os dois calendários lado a lado e decidido qual vem primeiro.

Um inventário de customizações fiscais é o primeiro passo concreto, independentemente da sequência que a empresa escolher depois. Esse inventário lista cada customização de tropicalização hoje ativa no ambiente, classifica se ela é específica do ECC, se tem equivalente nativo no S/4HANA, ou se precisa ser redesenhada do zero, e estima o esforço de retestar cada uma, seja no ambiente atual, seja no ambiente novo.

Um critério de verificação direto: pergunte ao CIO ou Head de SAP se existe hoje, em algum documento, a comparação lado a lado dos dois calendários, com data prevista de adequação da CBS e data prevista de decisão de migração. Se essa comparação só existe na cabeça de quem está acompanhando os dois assuntos separadamente, a governança da sequência ainda não existe de fato.

Sem esse inventário, qualquer decisão de sequência é feita no escuro, baseada em estimativa genérica de esforço, não no levantamento real do que existe hoje no ambiente. E o tempo até 2027 é exatamente o que resta para fazer esse levantamento com calma, em vez de sob pressão de prazo dobrado.

Onde isso converge para uma decisão concreta

A localização fiscal brasileira, tanto no ECC quanto no S/4HANA, e a solução fiscal acoplada que a sustenta, é o centro da decisão de sequência entre reforma e migração. O apoio à migração de ECC para S/4HANA com foco em arquitetura fiscal é exatamente o trabalho de alinhar essas duas agendas numa única linha do tempo, com um dono nomeado para a decisão.

O Diagnóstico Fiscal SAP inventaria as customizações fiscais existentes antes da decisão de plataforma ser tomada, para que a escolha de sequência seja baseada no que o ambiente real exige, não numa estimativa genérica de esforço de migração.