A Reforma Tributária obriga seu SAP a calcular dois regimes tributários ao mesmo tempo.

Toda empresa que roda SAP no Brasil vai atravessar a Reforma Tributária dentro do próprio sistema, não ao lado dele. Isso é diferente de quase toda mudança fiscal que o SAP já absorveu neste país. Uma alteração de alíquota de ICMS, um novo layout de nota fiscal, uma obrigação acessória nova, tudo isso historicamente chegava como ajuste pontual dentro de uma estrutura que continuava sendo a mesma. A Reforma Tributária é outra categoria de mudança: ela substitui a lógica de determinação de imposto que o SAP usa desde que o sistema fiscal brasileiro atual foi desenhado, e faz isso em paralelo com o regime antigo, durante anos, não da noite para o dia.

Este guia existe para responder, de um lugar só, a pergunta que qualquer Diretor Fiscal, CFO ou gerente de projeto SAP já deveria estar fazendo: o que muda de fato dentro do sistema, quando muda, e o que precisa ser feito antes de cada mudança chegar. Ele não substitui os artigos técnicos mais específicos que este cluster de conteúdo já tem ou vai ter (sobre IBS/CBS na apuração, sobre Split Payment, sobre o que o S/4HANA entrega nativo, sobre customização fiscal na migração), ele os organiza e aponta para eles no momento certo. Quem cai direto aqui, vindo de uma busca, sai sabendo o suficiente para decidir o que aprofundar em seguida.

O que este guia não é

Este não é um texto de posicionamento tributário. Não vamos dizer qual regime, qual crédito, qual exceção setorial ou qual interpretação de benefício fiscal se aplica à sua operação. Essa é decisão do cliente, com o time jurídico-tributário próprio, sempre. O papel descrito aqui é outro: o que a legislação já determina, com fonte, e o que isso significa em comportamento de sistema, dentro do SAP.

Também não é um texto que promete que a transição vai ser simples, nem que reduz a Reforma a uma lista de tarefas de TI. A transição envolve legislação em elaboração, prazos que ainda não estão totalmente fechados em regulamentação infralegal, e decisões de arquitetura que dependem do ambiente de cada empresa. Onde a informação oficial ainda não existe, este guia diz isso explicitamente, em vez de inventar uma data ou uma regra que soa plausível.

Em uma frase: o que muda

A Reforma Tributária substitui, de forma gradual, quatro tributos (ICMS, ISS, PIS e Cofins) por dois tributos novos (CBS e IBS), com convivência entre os dois regimes por vários anos, e introduz um mecanismo de recolhimento diferente (Split Payment) que desloca parte do controle fiscal para o momento da liquidação financeira da operação. Dentro do SAP, isso não é uma troca de alíquota. É uma reconfiguração de cinco camadas ao mesmo tempo: cadastro fiscal, determinação de imposto, documento fiscal, apuração e obrigação acessória, todas rodando dois regimes em paralelo durante a transição.

Base legal: de onde vem cada regra

Duas normas sustentam tudo o que este guia descreve, e as duas são a única fonte primária que vale citar quando o assunto é prazo, alíquota ou dispositivo legal.

A Emenda Constitucional 132, de 2023 alterou a Constituição para criar a estrutura do novo sistema tributário sobre o consumo, autorizando a criação do IBS (tributo compartilhado entre Estados e Municípios) e da CBS (tributo federal), além de um Imposto Seletivo sobre bens e serviços prejudiciais à saúde ou ao meio ambiente. A emenda desenhou o modelo constitucional; ela não detalha, sozinha, alíquota, prazo operacional ou regra de transição, isso ficou para a lei complementar.

A Lei Complementar 214, de 2025 é quem regulamenta o modelo, artigo por artigo: define fatos geradores, alíquotas do período de teste, cronograma de substituição do ICMS e do ISS, mecanismo de não cumulatividade, regras de Split Payment, e a data geral de vigência da própria lei. É este o texto que qualquer conteúdo técnico sobre Reforma Tributária no SAP precisa citar quando afirma um prazo ou um número, e é o texto que este guia usou como fonte primária, lido direto no site do Planalto (planalto.gov.br/ccivil_03/leis/lcp/lcp214.htm), com o número do artigo exato citado ao lado de cada afirmação de cronograma abaixo.

Uma parte importante da regulamentação ainda depende de normas complementares que serão publicadas pelo Comitê Gestor do IBS (CGIBS, o órgão que vai administrar o novo tributo compartilhado) e pela Receita Federal. Onde este guia menciona esse tipo de pendência, é porque ela é real e verificada: a norma complementar específica ainda não existia na data de publicação.

Os dois tributos novos: IBS e CBS

CBS (Contribuição sobre Bens e Serviços) é o tributo federal, que substitui PIS e Cofins. IBS (Imposto sobre Bens e Serviços) é o tributo compartilhado entre Estados e Municípios, que substitui ICMS e ISS. Os dois seguem a mesma lógica de tributação sobre o valor agregado, com não cumulatividade ampla (o crédito tomado numa etapa da cadeia compensa o débito da etapa seguinte, de forma mais abrangente do que o regime de crédito atual permite hoje em vários pontos específicos).

Essa arquitetura de "dois tributos que nascem juntos, mas com administração e destinação diferentes" é o motivo pelo qual, dentro do SAP, IBS e CBS não podem ser tratados como um único código de imposto: são dois tributos distintos, com regras próprias de vigência, de alíquota e de transição, mesmo compartilhando a mesma base de cálculo na maior parte dos casos. Um projeto de parametrização que trate os dois como sinônimos, só porque "nascem juntos na Reforma", cria um problema de modelagem fiscal que só aparece depois, quando as alíquotas plenas divergirem entre os regimes federal e subnacional.

Existe também o Imposto Seletivo, previsto na EC 132/2023, incidente sobre produção, comercialização ou importação de bens e serviços prejudiciais à saúde ou ao meio ambiente. Este guia não detalha o Imposto Seletivo porque ele afeta um recorte específico de operações (não todas as empresas), e um tratamento raso do tema criaria mais confusão do que clareza; ele merece um conteúdo dedicado, à parte, quando houver demanda real de leitura sobre o assunto.

O cronograma, ano a ano, com o que muda em cada fase

Este é o bloco mais citado, e o mais fácil de errar quando a data não é conferida em fonte primária. Cada afirmação abaixo tem o artigo exato da LC 214/2025 por trás.

2026, o ano de teste

Para fatos geradores ocorridos entre 1º de janeiro e 31 de dezembro de 2026, a lei fixa alíquota de 0,1% para o IBS (art. 343 da LC 214/2025) e 0,9% para a CBS (art. 346 da mesma lei). O próprio texto legal prevê que o valor recolhido nesse período é compensado com PIS e Cofins apurados no mesmo intervalo (art. 348), de forma que o impacto na carga tributária efetiva da empresa, nesse ano de teste, não é relevante. O objetivo declarado desse desenho não é arrecadar, é permitir que o novo sistema (cadastro dos contribuintes, transmissão de dados ao Comitê Gestor, apuração dos dois tributos novos) rode de verdade, com dado real, antes da fase seguinte.

Isso tem uma implicação prática direta para quem decide cronograma de projeto de SAP: 2026 é a janela de menor risco financeiro para testar a parametrização de IBS e CBS em ambiente real, porque o valor em jogo, se algo sair errado no cálculo, é pequeno. Depois de 2026, o custo de um erro de parametrização deixa de ser simbólico.

2027 e 2028, o meio do caminho, não a alíquota cheia

Aqui está o ponto que mais precisa de precisão, porque é onde um rascunho interno já quase publicou uma informação errada antes desta verificação: a CBS não passa a operar em alíquota cheia já em 2027. O que a lei estabelece é diferente. A partir de 2027, a CBS passa a usar a alíquota de referência, que será fixada por resolução do Senado Federal (art. 349 da LC 214/2025). Só que, especificamente em 2027 e em 2028, essa alíquota de referência é reduzida em 0,1 ponto percentual (art. 347). O valor de referência integral, sem essa redução, só se aplica a partir de 2029.

Na prática, isso significa que 2027 e 2028 formam um degrau intermediário, nem o ano de teste simbólico de 2026, nem o regime pleno que começa em 2029. Qualquer conteúdo, planilha de projeto ou comunicação interna que afirme "CBS em alíquota cheia a partir de 2027" está descrevendo algo que a lei não diz, e isso pode levar a um cronograma de parametrização mal calibrado (adiantar demais um esforço que só precisa estar pronto em 2029, ou pior, atrasar um esforço que precisa estar funcionando já em 2027, mesmo que ainda não seja o valor final).

Toda a regulamentação de detalhe (valor exato da alíquota de referência, por exemplo) segue sujeita a normas complementares do CGIBS e da Receita Federal ainda não publicadas na data deste guia. Isso não é lacuna de conteúdo, é o estado real da regulamentação.

2029 a 2032, a substituição gradual de ICMS e ISS

A partir de 2029, o regime muda de figura outra vez, agora do lado dos tributos antigos que estão sendo extintos. A LC 214/2025 estabelece uma redução progressiva das alíquotas de ICMS e de ISS, tomando como base o valor vigente em 31 de dezembro de 2028:

• 2029: redução de 10% em relação à alíquota vigente em 31/12/2028 (art. 501 para o ICMS, art. 508 para o ISS).
• 2030: redução de 20%.
• 2031: redução de 30%.
• 2032: redução de 40%.

Ou seja, entre 2029 e 2032, ICMS e ISS não desaparecem de uma vez, eles encolhem em degraus previsíveis, enquanto IBS e CBS assumem o espaço fiscal deixado. Durante todo esse intervalo, o SAP precisa calcular e reconciliar dois regimes tributários ao mesmo tempo, para a mesma operação, sem que um substitua o outro de forma abrupta.

2033, a extinção completa

A lei prevê a extinção total de ICMS e de ISS em 2033. A partir desse ano, em tese, o ambiente fiscal do SAP para consumo se resume a IBS, CBS e Imposto Seletivo, sem a convivência com os quatro tributos antigos. Isso é o horizonte final do cronograma, não o próximo passo prático de nenhuma empresa em 2026: o trabalho real, hoje, está concentrado no período de transição, que dura mais tempo do que a maioria dos projetos de SAP costuma planejar de uma vez só.

Resumo visual do cronograma

Este quadro é o que este guia recomenda usar como referência interna de planejamento, porque cada linha tem um artigo específico por trás, em vez de uma data solta sem lastro.

O que cada tributo novo substitui, e o que não substitui

CBS substitui PIS e Cofins: dois tributos federais que hoje incidem sobre receita/faturamento, com regimes de apuração (cumulativo e não cumulativo) que já geram, por si só, uma quantidade relevante de regras de determinação dentro do SAP. IBS substitui ICMS e ISS: o tributo estadual sobre circulação de mercadorias e o tributo municipal sobre serviços, dois tributos com centenas de legislações estaduais e municipais diferentes hoje, cada uma com sua própria tabela de alíquota, benefício fiscal e regra de substituição tributária.

O que a Reforma não substitui, dentro do escopo deste guia: o Imposto de Renda, a Contribuição Social sobre o Lucro Líquido, o IPI (que passa por um tratamento próprio, reduzido a zero para a maioria dos produtos, com exceção dos que competem com a Zona Franca de Manaus, mas cujo detalhamento integral foge do escopo deste texto), as contribuições previdenciárias, e nenhum tributo sobre patrimônio ou renda. A Reforma Tributária de 2023/2025 é, no desenho legal, uma reforma do consumo, não uma reforma tributária geral.

Essa distinção importa dentro do SAP porque delimita o que precisa de reconfiguração de determinação de imposto e o que continua rodando exatamente como roda hoje. Um projeto que trate "a Reforma" como se ela tocasse todo o módulo fiscal, inclusive folha e IR, está superdimensionando o escopo real de mudança, e desviando esforço de onde a mudança de fato acontece.

O efeito prático em cada área do SAP

Aqui está o núcleo técnico deste guia: como a transição toca, de forma concreta, cada camada do ambiente fiscal dentro do SAP. Cada subseção corresponde a um tipo de trabalho de configuração distinto, e nenhuma delas se resolve isoladamente, das cinco.

Cadastro fiscal

Hoje, o cadastro de material, cliente e fornecedor carrega os atributos fiscais necessários para determinar ICMS, ISS, PIS e Cofins: classificação fiscal do produto, código de situação tributária, indicadores de regime especial, exceções por UF. Com IBS e CBS, esse cadastro ganha uma camada adicional, não substitui a anterior: novos atributos de classificação tributária sob a lógica do IBS/CBS precisam coexistir, campo a campo, com os atributos do regime antigo, durante todo o período de transição (2026 a 2032, no mínimo).

Isso é relevante porque cadastro fiscal é, historicamente, a área mais subestimada em projetos de mudança tributária. É fácil ajustar uma regra de cálculo num sistema de teste; é trabalhoso e lento revisar, campo a campo, o cadastro de milhares de materiais e parceiros de negócio para garantir que a classificação nova está correta desde a origem. Um erro de classificação no cadastro se propaga para toda determinação de imposto que depende dele, silenciosamente, até alguém notar na apuração ou, pior, na fiscalização.

Determinação de imposto

É aqui que a convivência dos dois regimes fica mais visível tecnicamente. A lógica de determinação de imposto (o procedimento de cálculo, as condições de preço e imposto que decidem qual alíquota se aplica a qual operação) precisa reconhecer IBS e CBS como códigos de imposto próprios, calculando em paralelo com ICMS, ISS, PIS e Cofins, não em substituição a eles, durante toda a transição.

Isso dobra, na prática, o número de regras de determinação ativas ao mesmo tempo no ambiente, porque cada operação passa a precisar de duas determinações simultâneas: a do regime antigo (ainda vigente, embora em redução) e a do regime novo (ainda em rampa de alíquota). Um ambiente que hoje já tem determinação de imposto complexa (múltiplos cenários de exceção estadual, substituição tributária, benefício fiscal) vai sentir esse efeito de forma mais aguda do que um ambiente simples, porque a complexidade existente se multiplica pela complexidade nova, não se substitui por ela.

Documento fiscal

NF-e e os demais documentos fiscais eletrônicos brasileiros precisam refletir os novos campos e totalizadores de IBS e CBS ao lado dos tributos existentes, durante todo o período em que os dois regimes coexistem. Isso depende do leiaute oficial vigente definido pela Nota Técnica da NF-e em cada momento específico, um detalhe técnico que muda de acordo com a evolução da regulamentação e que precisa ser conferido na nota técnica vigente antes de qualquer implementação real, não a partir de uma suposição de como o layout "provavelmente" vai ficar.

Um ponto que costuma passar despercebido: o documento fiscal não é só um formato de saída, ele é também prova de conformidade. Um documento emitido com o cálculo de IBS/CBS incorreto, ainda que o valor recolhido tenha sido corrigido depois manualmente em algum lugar, já é uma inconsistência registrada, e inconsistência registrada em documento fiscal tende a ser o primeiro lugar que uma fiscalização observa.

Apuração e não cumulatividade

O crédito de IBS e de CBS segue uma lógica de não cumulatividade mais ampla do que o crédito de ICMS hoje permite em pontos específicos (a lei desenha um sistema em que, de forma geral, todo crédito de aquisição vinculado à atividade econômica gera direito a crédito, sem as restrições setoriais que hoje existem em vários regimes de ICMS). Isso significa que a apuração fiscal dentro do SAP e do motor fiscal integrado precisa reconciliar créditos tomados por aquisição com débitos apurados por saída, sob a lógica nova, em paralelo com a apuração do regime antigo ainda vigente.

O risco técnico concreto aqui não é o cálculo isolado de uma nota, é o fechamento do período: a apuração consolidada de um mês precisa bater, ao mesmo tempo, com a lógica de crédito do regime antigo e do regime novo, sem misturar as duas bases. Um erro de reconciliação nessa fase costuma só aparecer no fechamento, quando o número final não fecha, e nesse ponto o custo de investigar retroativamente já é maior do que teria sido prevenir com teste antecipado.

Obrigação acessória

O SPED e as demais obrigações acessórias passam a exigir informação compatível com os dois regimes tributários simultaneamente, durante toda a transição, até a extinção definitiva do regime antigo em 2033. Isso vale tanto para os arquivos periódicos (EFD ICMS/IPI, EFD- Contribuições, ECD, ECF, EFD-Reinf) quanto para qualquer relatório fiscal que hoje já consolida dado do regime tradicional.

Uma obrigação acessória que hoje já é complexa (porque cruza dado de várias origens dentro do SAP: fiscal, contábil, folha) fica mais complexa ainda quando precisa acomodar campos e totalizadores novos sem quebrar a estrutura que já funciona para o regime atual. Esse é, tipicamente, o ponto em que um projeto mal planejado descobre, tarde, que "só adicionar um campo novo" exigia revisar toda a lógica de extração de dado que alimenta aquele relatório.

O que o S/4HANA entrega nativo, e o que não entrega

Uma pergunta recorrente em avaliação de arquitetura, quando o assunto é Reforma Tributária: "se eu migro para o S/4HANA, o SAP já resolve isso nativamente?" A resposta não é sim nem não, é uma questão de escopo, e a distinção importa mais agora, no meio de uma transição tributária, do que nunca.

O SAP Document and Reporting Compliance (DRC) é a solução da própria SAP para a camada de geração e transmissão de documentos fiscais e relatórios estatutários: faturamento eletrônico, relatórios fiscais periódicos, troca de documentos eletrônicos, formatos de auditoria fiscal. Segundo documentação indexada do SAP Help Portal (lida em 2026-08-24) e conteúdo publicado oficialmente pela própria SAP em canais como SAP Blogs, o DRC é organizado em dois eixos: um framework de eDocument (compliance em nível de transação, como a nota fiscal eletrônica) e um framework de Relatórios Estatutários (arquivos periódicos agregados, como as declarações da família SPED). A SAP renomeou e absorveu, em outubro de 2021, o antigo produto ACR (Advanced Compliance Reporting) dentro do DRC, de forma que "ACR", hoje, é majoritariamente terminologia legada para a capacidade de Relatório Estatutário que já vive dentro do DRC.

O que essa arquitetura cobre para o Brasil, segundo o que está documentado: a parte de eDocument do DRC cobre nativamente a emissão e transmissão da NF-e, dentro do escopo padrão do produto. A parte de Relatório Estatutário cobre os relatórios da família SPED (EFD ICMS/IPI, EFD- Contribuições, ECD, ECF, EFD-Reinf) com uma estrutura e um conjunto de registros já preparados pela SAP. O ponto central, e a razão pela qual esta distinção precisa estar clara antes de qualquer decisão de arquitetura: "nativo" não é sinônimo de "completo". A SAP entrega o transporte, o formato e um núcleo de conteúdo pronto. O que se aplica à operação específica de cada empresa (benefício fiscal estadual, exceção setorial, regra de determinação combinando produto, operação e UF) continua sendo trabalho de parametrização, e é exatamente aí que entra a função de um motor fiscal integrado ao SAP, distinta da função de geração e transmissão de relatório que o DRC resolve.

Essa distinção fica mais crítica durante a transição da Reforma Tributária, não menos, porque o volume de parametrização nova (novos códigos de imposto, novos atributos de cadastro, nova lógica de crédito) é justamente o tipo de trabalho que o DRC não resolve sozinho: ele vai transmitir e formatar o que o motor de determinação calculou, correto ou não. Um ambiente que assume, sem diagnóstico prévio, que "o S/4HANA com DRC já resolve a Reforma Tributária" corre o risco real de descobrir a lacuna só no primeiro fechamento com IBS/CBS de valor relevante, ou na primeira fiscalização, quando o relatório gerado pelo standard não reflete a regra fiscal completa daquela operação, porque a parametrização daquele cenário específico nunca foi feita.

O papel do Guepardo Tax nesse desenho

O Guepardo Tax, cujos direitos pertencem à NTT DATA, é o motor fiscal integrado ao SAP que resolve a camada que o DRC não resolve: determinação e cálculo de imposto por operação, segundo a regra parametrizada no ambiente. Dentro do desenho da Reforma Tributária, isso significa uma função específica e delimitada: o Guepardo Tax calcula exatamente o que está configurado nele, nem mais, nem menos.

Duas consequências práticas decorrem dessa função:

Primeira, ele não antecipa mudança de legislação sozinho. Se o código de imposto e a condição de determinação para IBS e CBS ainda não existem, ou existem mas não foram testados, no ambiente, a chegada da data de vigência de uma alíquota nova não faz o Guepardo Tax passar a calculá-la por conta própria. A ferramenta segue a parametrização que existe, e a parametrização é trabalho humano de configuração, revisão e teste, feito antes da data em que a regra entra em vigor de verdade.

Segunda, ele não decide a tese fiscal. A estratégia tributária (como classificar uma operação específica, qual crédito tomar, qual exceção setorial aplicar) é decisão do cliente, com apoio jurídico-fiscal próprio. O Guepardo Tax executa a regra que foi configurada, com a mesma confiabilidade de execução, esteja a regra certa ou desatualizada. Essa distinção não é uma formalidade contratual: é o motivo pelo qual nenhuma consultoria técnica, incluindo a DFSpro, decide tese fiscal em nome do cliente. A DFSpro desenha, configura e prova o comportamento do sistema diante da regra que a empresa e seu time jurídico-tributário decidem adotar.

Durante a transição da Reforma Tributária, a função de governança contínua da parametrização fiscal ganha um peso adicional, porque o volume de mudança regulatória (novas normas do CGIBS, novos atos da Receita Federal, ajustes de leiaute de documento fiscal) é maior e mais frequente do que num período de estabilidade legislativa. Sem um responsável nomeado acompanhando essas mudanças e avaliando o impacto de cada uma na parametrização do Guepardo Tax, cada atualização de regulamentação vira retrabalho reativo, descoberto só no fechamento seguinte, em vez de trabalho planejado com antecedência.

Quem administra o tributo novo: o Comitê Gestor do IBS

Uma peça de arquitetura institucional que ajuda a entender por que a regulamentação ainda está sendo publicada em etapas: o IBS, por ser um tributo compartilhado entre Estados e Municípios, não é administrado por uma única Secretaria de Fazenda estadual ou por um único órgão municipal, como acontece hoje com o ICMS e o ISS, cada um sob a competência do seu respectivo ente. A EC 132/2023 criou o Comitê Gestor do IBS (CGIBS), um órgão específico, com representação de Estados, Distrito Federal e Municípios, responsável por regulamentar, arrecadar, fiscalizar e distribuir a receita do IBS entre os entes federativos.

Essa arquitetura tem uma implicação direta para quem acompanha regulamentação de dentro do SAP: antes da Reforma, uma empresa que operava em vários Estados precisava acompanhar a legislação de ICMS de cada Secretaria de Fazenda estadual separadamente, cada uma com seu próprio calendário de mudança. Com o IBS, parte relevante dessa regulamentação passa a ser centralizada no CGIBS, o que tende a reduzir a fragmentação normativa ao longo do tempo, mas não elimina o trabalho de acompanhamento: o CGIBS ainda está publicando as normas complementares que faltam, e a CBS segue sob regulamentação da Receita Federal, um órgão federal distinto. Ou seja, quem acompanha regulamentação da transição precisa monitorar, no mínimo, duas fontes normativas diferentes (CGIBS para o IBS, Receita Federal para a CBS), além da legislação residual dos entes estaduais e municipais que ainda administram ICMS e ISS durante o período de convivência.

Este guia não detalha a estrutura interna de governança do CGIBS além do necessário para explicar por que a regulamentação chega em ondas, e não de uma vez: é assim que o desenho institucional da Reforma prevê que ela aconteça, com o órgão gestor publicando normas complementares à medida que o cronograma avança, não todas de uma vez no início da transição.

Impacto por área da empresa: Fiscal, TI e Financeiro

A transição raramente é resolvida bem quando é tratada como um problema de uma área só. Cada área enxerga uma fatia diferente do mesmo problema, e a ausência de comunicação entre elas é uma causa recorrente de retrabalho.

Fiscal é quem decide a tese tributária (classificação de operação, crédito, exceção setorial) e quem precisa validar se o resultado calculado pelo sistema corresponde ao que a legislação e a interpretação adotada pela empresa determinam. Sem envolvimento contínuo do Fiscal, um projeto de parametrização corre o risco de construir uma regra tecnicamente funcional, mas que não reflete a tese tributária real da empresa, porque ninguém do Fiscal validou o resultado, só a execução.

TI, dentro do SAP, é quem constrói e mantém a determinação de imposto, os campos de cadastro, a integração com o documento fiscal eletrônico e a extração de dado para as obrigações acessórias. TI não decide a regra fiscal, mas é responsável por garantir que o sistema calcule exatamente o que o Fiscal determinou, de forma testada, documentada e reprodutível. Um projeto sem essa responsabilidade bem delimitada tende a produzir configuração feita "de acordo com o que parecia fazer sentido tecnicamente", sem validação formal do Fiscal em cada regra.

Financeiro entra com mais peso a partir do momento em que o Split Payment se torna operação plena, porque o mecanismo desloca parte do controle tributário para o processo de pagamento e recebimento, historicamente domínio do Financeiro/Tesouraria, não do Fiscal. Antes disso, Financeiro já tem um papel relevante na reconciliação contábil entre o que foi apurado no regime antigo e no regime novo durante a convivência dos dois. Um projeto que trate o Split Payment como "assunto só de fiscal e TI" corre o risco de chegar à operação plena do mecanismo sem que a Tesouraria tenha mapeado o próprio impacto no fluxo de caixa.

A coordenação entre essas três áreas, com pontos de decisão explícitos (o que é tese fiscal, o que é configuração de sistema, o que é impacto financeiro), é o que costuma diferenciar um projeto de preparação bem-sucedido de um projeto que entrega tecnicamente, mas produz resultado fiscal incorreto porque a validação de negócio nunca aconteceu de forma estruturada.

Detalhamento por módulo: onde a parametrização de fato acontece

As cinco camadas descritas anteriormente (cadastro fiscal, determinação de imposto, documento fiscal, apuração, obrigação acessória) não vivem isoladas dentro do SAP: elas atravessam módulos diferentes, e essa distribuição é parte do motivo pelo qual um projeto de Reforma Tributária não é trabalho de uma equipe só.

SD (Sales and Distribution) é onde a determinação de imposto de saída normalmente é resolvida, no fluxo de vendas: pedido, entrega, fatura. É aqui que a condição de preço/imposto para IBS e CBS precisa estar corretamente configurada para que o documento fiscal de saída (a NF-e emitida ao cliente) carregue o valor correto dos tributos novos, calculado junto com os tributos antigos ainda vigentes.

MM (Materials Management) é onde a determinação de imposto de entrada é resolvida, no fluxo de compras: pedido de compra, entrada de mercadoria, fatura de fornecedor. É aqui que o crédito de IBS/CBS tomado numa aquisição precisa ser reconhecido corretamente, para alimentar a apuração de não cumulatividade descrita anteriormente.

FI (Financial Accounting) é onde a contabilização do tributo (débito e crédito) e, no futuro, a integração com o Split Payment, acontecem. É também onde vive boa parte da reconciliação entre o valor apurado pelo motor fiscal e o valor efetivamente contabilizado e, mais adiante, retido na liquidação financeira.

O motor fiscal integrado (Guepardo Tax, no caso desta consultoria) normalmente atua de forma transversal a SD e MM, centralizando a lógica de determinação de imposto que, no standard puro do SAP, ficaria mais fragmentada entre condições de preço nativas. É por isso que a parametrização de IBS/CBS dentro de um motor fiscal integrado tende a ser mais concentrada e mais fácil de auditar do que replicar a mesma lógica em condições de preço espalhadas pelo standard, mas isso não elimina a necessidade de testar a integração desse motor com SD, MM e FI, ponta a ponta, porque é essa integração, e não o motor isoladamente, que determina o resultado final no documento fiscal e na apuração.

Quem está em ECC e quem já está em S/4HANA: a diferença de exposição

A transição tributária não trata igual quem opera SAP ECC (a versão anterior, ainda amplamente usada) e quem já migrou para o S/4HANA. As diferenças relevantes, dentro do escopo deste guia, são de arquitetura e de prazo, não de "um sistema resolve e o outro não".

Quem está em ECC normalmente já convive com uma camada de customização fiscal acumulada ao longo dos anos (exit, user-exit, BAdI, tabela Z, lógica desenvolvida sob medida para resolver particularidades locais que o standard da época não cobria). Ao entrar numa transição tributária que exige nova parametrização em paralelo com a antiga, cada uma dessas customizações precisa ser inventariada e avaliada individualmente: ela continua necessária no regime novo, precisa ser adaptada, ou pode ser aposentada porque a regra que ela existia para resolver deixou de existir? Sem esse inventário, o risco comum é que a parametrização nova de IBS/CBS seja construída sem considerar que uma customização antiga já está interceptando o mesmo fluxo de cálculo, gerando um resultado inesperado que só aparece quando as duas lógicas colidem.

Quem já está em S/4HANA tem, em tese, um ambiente mais próximo do standard atual, com menos customização acumulada e com acesso ao DRC como framework nativo de documento e relatório. Isso reduz parte do trabalho de reconciliação de customização legada, mas não elimina o trabalho de parametrização de determinação de imposto descrito nas seções anteriores: o DRC transmite e formata, ele não decide a regra de cálculo. Um ambiente S/4HANA sem a parametrização fiscal de IBS/CBS testada está exatamente na mesma situação de exposição que um ambiente ECC sem essa parametrização: o sistema não vai calcular sozinho.

A decisão sobre migrar para S/4HANA antes, durante ou depois da transição tributária é uma decisão de arquitetura e de risco do cliente, que depende de fatores fora do escopo deste guia (cronograma de projeto já em andamento, orçamento, dependência de outros módulos). O que este guia recomenda, independentemente dessa decisão, é que o inventário de parametrização fiscal (o que já existe, o que falta, o que está em teste) seja feito antes de decidir a arquitetura, não depois.

Erros comuns de preparação

Alguns padrões de erro se repetem, por serem consequência direta da forma como a transição está desenhada (dois regimes convivendo, regulamentação ainda incompleta, prazo longo). Eles não são específicos de nenhum ambiente, e reconhecer o padrão antes de cometê-lo é mais barato do que corrigir depois.

Tratar 2026 como "não vale a pena testar porque a alíquota é simbólica". É exatamente o contrário: a alíquota simbólica é o motivo pelo qual 2026 é a janela de menor custo para descobrir problema de parametrização. Um erro descoberto em 2026, com IBS a 0,1% e CBS a 0,9%, custa uma fração do que o mesmo erro custaria descoberto em 2029, quando os valores em jogo já são maiores.

Confundir "alíquota de referência" com "alíquota cheia" em 2027. Como já detalhado na seção de cronograma, esse é um erro que já quase entrou em conteúdo publicado nesta própria consultoria antes de ser corrigido por verificação em fonte oficial. Um cronograma de projeto baseado nessa confusão tende a superestimar a urgência de 2027 e subestimar 2029, quando o valor de referência se torna integral.

Assumir que o S/4HANA com DRC "já resolve" a Reforma Tributária. Como detalhado na seção anterior, o DRC resolve transporte e formato, não determinação e cálculo. Essa suposição costuma aparecer em avaliações de arquitetura feitas sem diagnóstico prévio, e o custo dela só aparece no primeiro fechamento real com valor relevante.

Não inventariar customização fiscal legada antes de parametrizar o regime novo. Relevante principalmente para ambientes ECC com anos de customização acumulada, mas também presente, em menor escala, em ambientes S/4HANA que herdaram lógica de projetos de migração anteriores. Uma regra nova construída sem visibilidade sobre uma regra antiga que já intercepta o mesmo fluxo gera resultado inesperado, e esse tipo de conflito raramente aparece em teste isolado, só em cenário de ponta a ponta.

Tratar cadastro fiscal como tarefa secundária em relação à regra de cálculo. É comum priorizar a construção da lógica de determinação de imposto e deixar a revisão do cadastro de material, cliente e fornecedor para depois, "quando der tempo". Como a determinação de imposto depende inteiramente da classificação correta no cadastro, uma regra de cálculo tecnicamente perfeita, mas alimentada por cadastro desatualizado, produz resultado errado, e o erro não é da regra, é do dado de entrada.

Não nomear um responsável para acompanhar a regulamentação em elaboração. Parte relevante da Reforma Tributária ainda depende de normas complementares do CGIBS e da Receita Federal. Um ambiente sem responsável nomeado para acompanhar essas publicações trata cada atualização como surpresa, descoberta depois que ela já deveria ter sido incorporada à parametrização.

Testar só a execução técnica, não o resultado fiscal. Um teste de migração ou de parametrização que confirma apenas que "o processo rodou sem erro técnico" não confirma que o valor calculado está correto para a legislação vigente. São duas validações diferentes, e a segunda é a que de fato protege contra risco fiscal.

Split Payment: o mecanismo que muda o momento do recolhimento

O Split Payment é o mecanismo previsto na LC 214/2025 (arts. 31 a 35) pelo qual o valor de IBS e CBS devido numa operação é segregado e recolhido diretamente na liquidação financeira do pagamento, em vez de ser apurado e recolhido pela empresa depois, no fechamento fiscal periódico. Pela regra geral de vigência da lei (art. 544, inciso VI), esse conjunto de artigos está formalmente em vigor desde 1º de janeiro de 2026, junto com o restante do texto legal: a LC 214/2025 não lista o Split Payment entre os dispositivos com data de vigência diferenciada.

Dito isso, é preciso ser preciso sobre o que essa vigência formal significa na prática: a operação técnica plena do mecanismo (quais meios de pagamento estarão cobertos, qual o papel dos intermediadores financeiros e adquirentes, quais exceções existirão) depende de regulamentação infralegal do CGIBS e da Receita Federal que ainda não foi publicada na data deste guia. Não é possível, com a informação disponível hoje, afirmar uma data específica em que o recolhimento via Split Payment passará a acontecer de fato, no dia a dia das operações, de forma plena. Este guia trata esse ponto como não conferido, propositalmente, em vez de estimar um ano.

O que já dá para descrever, com base no próprio desenho do mecanismo na lei, é o tipo de impacto técnico esperado dentro do SAP, quando a operação plena chegar. Hoje, o sistema calcula e registra o tributo no momento do documento fiscal, e o recolhimento é um evento posterior, dentro do calendário fiscal. Com Split Payment, o valor do tributo é retido no momento da liquidação financeira, o que exige que o processo fiscal (determinação de imposto) e o processo financeiro (execução de pagamento e recebimento) passem a trocar informação no mesmo evento, em vez de operarem, como hoje na maioria dos ambientes, de forma desacoplada no tempo.

Isso cria, no mínimo, três frentes de trabalho técnico quando a operação plena entrar em vigor: integração entre o motor de determinação de imposto e o processo de tesouraria/pagamento; reconciliação entre o valor bruto e o valor líquido já retido, tanto na entrada quanto na saída de caixa; e uma nova camada de reconciliação fiscal-financeira no fechamento, comparando o que o motor fiscal apurou como devido com o que de fato foi retido e recolhido pelo mecanismo. Nenhuma dessas frentes é trivial de improvisar depois que a regra já estiver em operação; todas se beneficiam de mapeamento antecipado, mesmo enquanto a regulamentação de detalhe ainda está sendo publicada.

Este guia não detalha o Split Payment além do necessário para situar o leitor: um artigo dedicado ao tema, dentro deste mesmo cluster, trata a fundo o impacto em fluxo de caixa e reconciliação.

Checklist de prontidão

Um checklist não substitui um diagnóstico completo, mas ajuda a identificar, rapidamente, se uma operação está partindo do zero ou já tem alguma base construída. Cada item abaixo corresponde a um sinal concreto, verificável dentro do próprio ambiente SAP, não a uma impressão subjetiva.

1. Existe algum código de imposto ou condição de determinação para IBS e CBS criada, mesmo em ambiente de teste? Se a resposta é não, a parametrização ainda não começou, mesmo que o projeto já esteja em andamento em outras frentes.
2. O cadastro de material, cliente e fornecedor tem, ao menos, um plano de campo definido para a classificação tributária de IBS/CBS? "Plano de campo" aqui significa que alguém já decidiu onde essa informação vai morar no cadastro, mesmo que o preenchimento em massa ainda não tenha começado.
3. Existe um inventário de customização fiscal legada (exit, BAdI, tabela Z) que intercepta o fluxo de determinação de imposto atual? Relevante especialmente em ambiente ECC ou em S/4HANA migrado com herança de customização.
4. Existe um plano de convivência formal para o período em que ICMS/ISS/PIS/Cofins e IBS/CBS calculam em paralelo? Não basta saber que os dois regimes vão coexistir, é preciso que exista uma decisão registrada de como o ambiente vai representar essa coexistência tecnicamente.
5. A validação pré-transmissão dos arquivos SPED já foi adaptada para checar os dois regimes ao mesmo tempo, ou ainda valida só o regime atual? Uma validação que não cobre o regime novo deixa passar erro que só vai aparecer depois de transmitido.
6. Existe um responsável nomeado para acompanhar as publicações do CGIBS e da Receita Federal e avaliar o impacto de cada uma na parametrização? Sem esse papel definido, cada atualização de regulamentação vira surpresa reativa.
7. O período de alíquota simbólica de 2026 está sendo usado para testar de verdade, com dado real de operação, ou está passando sem nenhum teste prático? Essa é a janela de menor custo para encontrar erro, e é a mais fácil de desperdiçar por parecer "não urgente".
8. Existe algum teste que valide o resultado fiscal calculado, não só a execução técnica do processo? Um processo que roda sem erro técnico não prova que o valor calculado está correto.
9. Há clareza sobre o que é responsabilidade do standard SAP/DRC (transporte e formato de relatório) e o que é responsabilidade do motor fiscal integrado (determinação e cálculo)? Sem essa clareza, é comum que uma lacuna de parametrização seja tratada como se fosse um problema do DRC, atrasando a correção real.
10. Existe integração testada, mesmo que preliminar, entre o processo fiscal e o processo financeiro, pensando no Split Payment? Ainda que a operação plena dependa de regulamentação futura, o mapeamento de onde essa integração vai precisar existir pode começar antes.

Uma operação que responde "não" a mais da metade desses itens está numa posição de risco real de exposição, não porque a transição em si seja incomum, mas porque o volume de trabalho necessário para responder "sim" a todos costuma ser maior do que o tempo restante até cada marco do cronograma sugere à primeira vista.

Diferenças por tipo de operação: indústria, serviço e varejo

A profundidade do impacto dentro do SAP não é igual para todo tipo de operação, porque a base de incidência de ICMS, ISS, PIS e Cofins hoje já é diferente entre indústria, prestação de serviço e varejo, e essa diferença de ponto de partida se reflete no volume de parametrização necessário para IBS e CBS. Este guia descreve o padrão geral, sem especificar números ou percentuais que não foram conferidos em fonte oficial para cada segmento.

Indústria normalmente já opera com a maior complexidade de determinação de imposto hoje, pela combinação de ICMS (com suas regras interestaduais, substituição tributária e benefícios fiscais estaduais) e IPI. Com IBS e CBS, essa indústria precisa reconciliar, ao mesmo tempo, a determinação de imposto para o regime antigo (ainda em vigor, com todas as suas exceções) e para o regime novo (mais uniforme entre operações, mas ainda em rampa de alíquota). O volume de cenários de teste tende a ser maior aqui do que em operações mais simples, exatamente porque o número de combinações produto/operação/UF que hoje já existe no ambiente se multiplica pela camada nova.

Prestação de serviço hoje lida principalmente com ISS, um tributo municipal com legislação fragmentada entre milhares de municípios, cada um com sua própria alíquota e regra de retenção. Com IBS assumindo o papel do ISS na Reforma, a expectativa de desenho da lei é reduzir parte dessa fragmentação, centralizando a administração no CGIBS, mas a transição em si exige que o ambiente SAP calcule ISS (regime antigo, ainda vigente) e IBS (regime novo) em paralelo durante todo o período de convivência, para o mesmo tipo de operação de serviço.

Varejo, operando com alto volume de transação e margem apertada por unidade, tende a sentir com mais intensidade qualquer atraso na parametrização, porque o volume de documento fiscal emitido por dia é maior, e um erro sistemático de cálculo se propaga rapidamente por um número grande de notas antes de ser percebido, comparado com uma operação de menor volume e maior valor por transação, onde um erro pontual tende a ser notado mais cedo.

Nenhum desses três padrões substitui um diagnóstico real do ambiente específico de cada empresa. Eles servem para ilustrar por que "a Reforma Tributária no SAP" não tem um único nível de esforço de preparação: o esforço real depende da complexidade fiscal que a operação já carrega hoje, antes mesmo de qualquer tributo novo entrar em cena.

Glossário rápido para quem está lendo este guia pela primeira vez

Um conjunto pequeno de termos aparece o tempo todo neste guia e no restante do cluster de conteúdo sobre Reforma Tributária. Reunir as definições curtas aqui evita que quem está lendo pela primeira vez precise abrir um segundo texto só para entender um termo.

IBS (Imposto sobre Bens e Serviços): tributo compartilhado entre Estados e Municípios, criado pela Reforma Tributária para substituir o ICMS e o ISS de forma gradual até 2033.

CBS (Contribuição sobre Bens e Serviços): tributo federal criado pela Reforma Tributária para substituir o PIS e a Cofins.

Imposto Seletivo: tributo previsto na EC 132/2023, incidente sobre bens e serviços prejudiciais à saúde ou ao meio ambiente, com escopo restrito a um recorte específico de operações, não tratado em detalhe neste guia.

Alíquota de referência: valor de alíquota fixado por resolução do Senado Federal para a CBS a partir de 2027, com redução de 0,1 ponto percentual em 2027 e 2028, tornando-se integral a partir de 2029 (arts. 347 e 349 da LC 214/2025).

Não cumulatividade ampla: regra de crédito tributário do IBS e da CBS que, de forma geral, reconhece crédito para toda aquisição vinculada à atividade econômica da empresa, com menos restrições setoriais do que o regime de crédito de ICMS hoje aplica em pontos específicos.

Split Payment: mecanismo previsto na LC 214/2025 (arts. 31 a 35) pelo qual o valor de IBS e CBS devido numa operação é segregado e recolhido diretamente na liquidação financeira do pagamento, em vez de apurado e recolhido depois.

CGIBS (Comitê Gestor do IBS): órgão criado pela EC 132/2023, com representação de Estados, Distrito Federal e Municípios, responsável por regulamentar, arrecadar, fiscalizar e distribuir a receita do IBS.

DRC (SAP Document and Reporting Compliance): solução nativa da SAP para geração e transmissão de documentos fiscais e relatórios estatutários, incluindo, para o Brasil, cobertura de NF-e e da família SPED.

ACR (Advanced Compliance Reporting): nome do produto anterior da SAP para relatório estatutário centralizado, renomeado e absorvido pelo DRC em outubro de 2021, hoje majoritariamente terminologia legada.

Guepardo Tax: motor fiscal integrado ao SAP, cujos direitos pertencem à NTT DATA, responsável pela determinação e cálculo de imposto por operação, segundo a regra parametrizada no ambiente.

AMS Fiscal: suporte contínuo de governança da parametrização fiscal, distinto e complementar ao suporte técnico de produto prestado pela NTT DATA.

Um glossário mais completo, com termos adicionais do vocabulário fiscal SAP, existe como conteúdo próprio dentro deste cluster.

O que este guia recomenda observar nos próximos meses

Como parte relevante da regulamentação ainda está sendo publicada, este guia recomenda um pequeno conjunto de sinais para acompanhar, sem depender de estimar uma data que a legislação ainda não fixou.

O primeiro sinal é a publicação de normas complementares do CGIBS sobre a operação técnica do Split Payment: enquanto essas normas não existirem, qualquer plano de integração entre fiscal e financeiro para esse mecanismo continua sendo trabalho de mapeamento preparatório, não de implementação final, porque o detalhe operacional exato (quais meios de pagamento, qual o papel de cada intermediador financeiro) ainda depende dessas normas.

O segundo sinal é a evolução da Nota Técnica da NF-e para os campos e totalizadores específicos de IBS e CBS: o leiaute de documento fiscal é um dos pontos mais sensíveis a mudança de detalhe técnico, e qualquer implementação feita antes da nota técnica final correspondente corre o risco de precisar de retrabalho quando o leiaute definitivo for publicado.

O terceiro sinal é a fixação da alíquota de referência pelo Senado Federal para o período 2027 a 2033, prevista no art. 349 da LC 214/2025: esse valor específico ainda não está determinado na data deste guia, e uma vez publicado, deve ser incorporado à parametrização de determinação de imposto sem demora, dado que rege diretamente o cálculo da CBS a partir de 2027.

Um ambiente que acompanha esses três sinais, com responsável nomeado e processo definido para avaliar o impacto de cada publicação na parametrização já existente, reduz o risco de tratar cada novidade regulatória como uma surpresa isolada, e passa a tratá-la como mais uma etapa esperada de um processo de transição que, por desenho legal, é gradual e publicado em partes.

Perguntas frequentes

A Reforma Tributária já está em vigor? Sim, parcialmente. Desde 1º de janeiro de 2026, IBS e CBS já são cobrados, em caráter de teste, com alíquotas simbólicas (0,1% e 0,9%, respectivamente), sem impacto relevante na carga tributária efetiva porque o valor é compensado com PIS e Cofins apurados no mesmo período. A substituição completa dos tributos antigos é gradual, e só se conclui, segundo o cronograma legal, em 2033.

O ICMS e o ISS deixam de existir em 2026? Não. A redução gradual das alíquotas de ICMS e de ISS só começa em 2029 (10% de redução), avança em degraus até 2032 (40%), e a extinção completa está prevista para 2033. Até lá, os regimes convivem, e o SAP precisa calcular os dois em paralelo.

A CBS entra em alíquota cheia em 2027? Não. Em 2027 e em 2028, a CBS opera com a alíquota de referência fixada pelo Senado Federal, mas reduzida em 0,1 ponto percentual em relação ao valor de referência integral. O valor pleno só se aplica a partir de 2029. Essa distinção é importante porque uma versão incorreta dessa informação ("alíquota cheia já em 2027") já circulou internamente antes de ser corrigida por verificação direta na Lei Complementar 214/2025.

O S/4HANA com DRC resolve a Reforma Tributária sozinho? Não integralmente. O DRC (SAP Document and Reporting Compliance) resolve a camada de geração e transmissão de documentos fiscais e relatórios estatutários, incluindo cobertura nativa para NF-e e para os relatórios da família SPED, segundo documentação oficial da SAP. O que ele não substitui é a determinação e o cálculo de imposto específicos de cada operação, papel de um motor fiscal integrado ao SAP, como o Guepardo Tax.

O Guepardo Tax já calcula IBS e CBS automaticamente, sem eu configurar nada? Não. O Guepardo Tax calcula exatamente o que está parametrizado no ambiente. Se o código de imposto e a condição de determinação para IBS/CBS ainda não existem ou não foram testados, a chegada da data de vigência de uma alíquota não faz o sistema calcular sozinho.

Quem decide como minha empresa deve tratar IBS/CBS fiscalmente? Sempre o cliente, com o time jurídico-tributário próprio. A DFSpro desenha, configura e prova o comportamento do sistema diante da regra que a empresa decidir adotar; a tese fiscal em si nunca é decisão da consultoria.

Faz diferença estar em ECC ou já ter migrado para S/4HANA? Faz diferença de arquitetura e de exposição a customização legada, não de "um sistema resolve e o outro não". Ambientes ECC costumam ter mais customização acumulada que precisa ser inventariada antes da parametrização nova. Ambientes S/4HANA têm acesso ao DRC nativo para transporte e formato, mas ainda precisam da mesma parametrização de determinação de imposto que qualquer outro ambiente.

O Split Payment já está afetando o caixa das empresas? Formalmente, o conjunto de artigos que cria o mecanismo está em vigor desde 2026, pela regra geral de vigência da lei. A operação técnica plena, com recolhimento automático de fato acontecendo na liquidação financeira das operações, depende de regulamentação infralegal do CGIBS e da Receita Federal ainda não publicada, e por isso não é possível afirmar hoje uma data exata em que esse impacto de caixa vai começar a acontecer na prática.

Por onde uma empresa deveria começar essa preparação? Por um diagnóstico que mapeie, camada por camada (cadastro fiscal, determinação de imposto, documento fiscal, apuração, obrigação acessória), o que já está parametrizado, o que falta, e o que priorizar antes de cada marco do cronograma legal, com o período de alíquota simbólica de 2026 usado como janela de teste de menor risco.

Isso é trabalho pontual ou contínuo? Os dois, em momentos diferentes. Existe um trabalho inicial de diagnóstico e parametrização, e existe um trabalho contínuo de governança, porque a regulamentação segue sendo publicada em etapas ao longo da transição, e cada publicação nova pode exigir ajuste na parametrização já existente.

Quem administra o IBS, se ele é compartilhado entre Estados e Municípios? O Comitê Gestor do IBS (CGIBS), órgão criado pela EC 132/2023 com representação de Estados, Distrito Federal e Municípios, responsável por regulamentar, arrecadar, fiscalizar e distribuir a receita do tributo entre os entes federativos. A CBS, por ser tributo federal, segue sob regulamentação da Receita Federal, um órgão distinto.

Toda empresa sente o mesmo nível de impacto dentro do SAP? Não. O volume de parametrização necessário depende da complexidade fiscal que a operação já carrega hoje. Indústria, prestação de serviço e varejo partem de bases de incidência diferentes (ICMS e IPI para indústria, ISS fragmentado por município para serviço, alto volume de documento fiscal para varejo), e essa diferença de ponto de partida se reflete no esforço de preparação, sem que isso mude o desenho geral do cronograma legal, que é o mesmo para todos os setores.

O que muda entre Fiscal, TI e Financeiro nesse processo? Fiscal decide a tese tributária e valida o resultado calculado. TI constrói e mantém a parametrização dentro do SAP, garantindo que o sistema calcule exatamente o que o Fiscal determinou. Financeiro entra com peso crescente à medida que o Split Payment avança para operação plena, porque o mecanismo desloca parte do controle tributário para o processo de pagamento e recebimento. Um projeto que não coordena essas três áreas de forma explícita tende a entregar tecnicamente, sem garantir que o resultado fiscal está correto.

Existe algum sinal específico que valha acompanhar nos próximos meses, sem esperar uma data que a lei ainda não fixou? Sim, três: a publicação de normas complementares do CGIBS sobre a operação técnica do Split Payment, a evolução da Nota Técnica da NF-e para os campos de IBS/CBS, e a fixação, pelo Senado Federal, da alíquota de referência da CBS para o período 2027-2033 (art. 349 da LC 214/2025). Nenhum desses três já está definido na data deste guia.

Como esse trabalho se organiza, na prática

O ponto de partida sempre é um diagnóstico: mapear, dentro do ambiente real do cliente, o que já existe de parametrização para IBS e CBS, o que falta, onde há customização legada que precisa ser avaliada, e qual o nível de exposição em cada uma das cinco camadas descritas neste guia. Esse diagnóstico não presume uma resposta antes de medir; ele existe justamente para substituir suposição por dado real do ambiente.

A partir do diagnóstico, o trabalho técnico de configuração e teste segue a mesma lógica descrita para o Guepardo Tax: desenhar, configurar e provar o comportamento do sistema diante da regra que a empresa decidiu adotar, nunca decidir a regra em si. Depois de um projeto de estabilização (parametrização testada, cadastro revisado, validação de resultado fiscal, não só de execução técnica), a manutenção contínua dessa arquitetura, incluindo o acompanhamento das próximas etapas do cronograma legal e das normas complementares que ainda serão publicadas pelo CGIBS e pela Receita Federal, é o escopo do que esta consultoria chama de AMS Fiscal: suporte contínuo, distinto do suporte técnico de produto prestado pela NTT DATA, e complementar a ele.

Nada disso substitui o parecer jurídico-tributário do cliente sobre qual tese fiscal adotar em cada cenário. O que este trabalho garante é que, uma vez que a tese foi decidida, o sistema calcule exatamente o que foi decidido, de forma testada e documentada, com um responsável acompanhando as mudanças de regulamentação que vão continuar chegando ao longo de toda a transição.

Por que testar em ambiente separado, antes de tocar produção

Um ponto de disciplina técnica que vale registrar explicitamente, porque a pressão de prazo do cronograma legal costuma empurrar equipes a pular essa etapa: toda parametrização nova de IBS e CBS, toda mudança em determinação de imposto, cadastro fiscal ou validação de SPED, deveria ser construída e testada primeiro em um ambiente separado do ambiente de produção, com dado representativo da operação real, antes de qualquer promoção.

A razão não é burocrática. Uma regra de determinação de imposto errada, promovida direto para produção sem teste em ambiente isolado, não gera um erro visível na hora: ela gera um documento fiscal emitido com valor incorreto, que só é percebido no fechamento do período, ou pior, na comparação entre o que foi apurado e o que uma fiscalização entende como devido. Nesse ponto, o custo de corrigir já inclui retificação de documento fiscal, ajuste de obrigação acessória já transmitida, e o risco de exposição a autuação, comparado com o custo de corrigir a mesma regra ainda em ambiente de teste, antes de qualquer documento real ter sido emitido com o erro.

O período de alíquota simbólica de 2026 é, de novo, a oportunidade mais barata para essa disciplina de teste em ambiente separado: mesmo que a parametrização já esteja rodando em produção com dado real de 2026, o valor financeiro em jogo, se algo estiver errado, é pequeno, porque a alíquota em si é pequena. Usar esse período só para "cumprir a obrigação legal de transmitir" sem aproveitar a oportunidade de validar o resultado fiscal, calculado com dado real, é desperdiçar a janela mais segura de todo o cronograma de transição.

Onde aprofundar cada tema

Este guia foi escrito para se sustentar sozinho, mas cada seção acima tem, ou vai ter, um artigo próprio, mais detalhado, dentro deste mesmo cluster de conteúdo:

• IBS e CBS no SAP, camada por camada: o artigo dedicado detalha determinação de imposto, cadastro mestre, documento fiscal, apuração e obrigação acessória, com o mesmo rigor de fonte oficial usado neste guia.
• Split Payment e SAP: impacto detalhado em fluxo de caixa, reconciliação fiscal-financeira e integração entre módulos fiscal e financeiro.
• S/4HANA nativo, o que DRC e ACR realmente entregam: detalhamento da distinção entre a camada de transporte/formato e a camada de determinação/cálculo, com as fontes oficiais da SAP.
• Customizações fiscais na migração para S/4HANA: como inventariar e decidir o destino de cada customização legada antes de uma migração.
• Governança Fiscal SAP e Guepardo Tax: os processos contínuos de manutenção da parametrização fiscal, aplicáveis tanto ao regime atual quanto ao regime em transição.
• Glossário DFSpro: definições curtas de IBS, CBS, Split Payment, Guepardo Tax e AMS Fiscal, para quem precisa de uma referência rápida de termo.

Continue por este cluster

Este guia organiza o assunto do começo ao fim. Para aprofundar pontos específicos, os seguintes conteúdos tratam cada tema em detalhe:

• Reforma Tributária, CBS e IBS, a especialidade completa da DFSpro para o tema.
• Guepardo Tax para a Reforma Tributária, como o motor de apuração se adapta ao IBS/CBS.
• Customizações fiscais na migração para S/4HANA, o que revisar antes de levar BAdIs e User Exits para o ambiente novo.
• S/4HANA nativo: o que DRC e ACR realmente entregam em compliance fiscal, o limite entre o que o sistema já resolve sozinho e o que ainda depende de configuração.
• Split Payment não é detalhe técnico. É redesenho de caixa, crédito e reconciliação, o aprofundamento do mecanismo descrito neste guia.
• Glossário, para os termos técnicos usados ao longo deste texto.

Metodologia e limites deste guia

Toda afirmação de cronograma, alíquota ou dispositivo legal usada neste texto foi conferida contra o texto da Lei Complementar 214/2025 e da Emenda Constitucional 132/2023, lidas diretamente no site do Planalto, com o artigo exato citado ao lado de cada afirmação.

Onde a informação oficial ainda não existe (regulamentação infralegal do CGIBS e da Receita Federal pendente, leiaute exato de documento fiscal para IBS/CBS, data operacional plena do Split Payment), este guia tratou o ponto como não conferido e evitou afirmar um número ou uma data que não tivesse lastro em texto legal ou em fonte oficial equivalente. A descrição do DRC e do ACR se apoia em documentação indexada do SAP Help Portal e em conteúdo publicado oficialmente pela SAP em canais próprios (SAP Blogs), não em opinião de terceiros sobre o produto.

Como a regulamentação da Reforma Tributária ainda está em elaboração, este guia precisa ser revisado periodicamente, à medida que novas normas do CGIBS e da Receita Federal forem publicadas. Nenhuma data ou alíquota aqui deve ser reafirmada, no futuro, sem reconferir a fonte oficial na data real de cada revisão.

Este guia também não teve nenhuma afirmação suavizada com a expressão "a confirmar" para contornar a exigência de verificação: onde uma informação não pôde ser confirmada em fonte oficial, a opção foi remover a afirmação do texto, não publicá-la com uma ressalva. Isso significa que este guia é, deliberadamente, menos detalhado em alguns pontos (data exata de operação plena do Split Payment, valor final da alíquota de referência da CBS, leiaute definitivo de documento fiscal para IBS/CBS) do que um texto que aceitasse citar fonte secundária ou estimativa de mercado seria. Essa é uma escolha editorial explícita desta consultoria: entre um texto mais completo com lastro fraco e um texto mais restrito com lastro forte, o segundo é o que sustenta a credibilidade do conteúdo ao longo do tempo, inclusive quando a regulamentação que falta hoje for publicada e este guia precisar ser atualizado com a informação nova, sem precisar desdizer nada do que já foi afirmado.

Por fim, um registro de escopo que vale deixar explícito: este guia cobre a Reforma Tributária do consumo (IBS, CBS e, de forma breve, o Imposto Seletivo), dentro do ambiente SAP de uma empresa que já opera ou está migrando para essa plataforma. Ele não é um guia geral de reforma tributária brasileira, não cobre tributação sobre renda, patrimônio ou folha, e não substitui o acompanhamento de um profissional tributário habilitado para a operação específica de cada empresa. O objetivo, do começo ao fim deste texto, foi único: descrever com precisão o que a legislação já determina, e o que isso significa em comportamento real de sistema, sem misturar fato verificado com previsão de mercado.

Para quem opera fiscal dentro do SAP e quer transformar este mapeamento num plano de ação para o próprio ambiente, o Diagnóstico Fiscal Estruturado é a forma de aplicar este guia à operação real, com prioridade e prazo.

---

Emanuel Kaufman Head of Business, DFSpro Boutique de missão crítica em SAP Fiscal e Guepardo Tax