SAP e Reforma Tributária: o baseline vem antes do leiaute do XML

Todo projeto de adequação do SAP à Reforma Tributária começa, na prática, pela mesma pergunta técnica: quais campos novos entram no XML, como fica o cadastro de produto e cliente, qual leiaute o Guepardo Tax precisa suportar para IBS, CBS e Imposto Seletivo. Essa pergunta é necessária, mas não é a primeira. A primeira pergunta, que a maioria dos projetos pula, é como a operação fiscal funciona hoje, de fato, não como o manual ou o desenho original do sistema diz que funciona.

A Emenda Constitucional 132/2023, promulgada em 20 de dezembro de 2023, fixou um cronograma que já está em curso: segundo o art. 125 do Ato das Disposições Constitucionais Transitórias (ADCT), 2026 é ano de teste, com IBS cobrado à alíquota estadual de 0,1% e CBS à alíquota de 0,9%. O art. 126 do ADCT determina que, a partir de 2027, a cobrança de CBS passa a ser plena e PIS e COFINS são extintos. Esse calendário não deixa margem para descobrir, no meio do caminho, que a parametrização nova foi construída sobre uma leitura equivocada de como a operação funciona hoje.

O que "mapear o estado atual" significa, na prática

Mapear o estado atual não é reler a documentação de implantação do SAP, é levantar, transação por transação relevante, como a determinação de imposto de fato acontece hoje: quais regras foram customizadas, quais exceções foram tratadas fora do sistema, em planilha paralela ou em ajuste manual, quais combinações de produto, estado e natureza de operação nunca foram testadas de verdade porque simplesmente não geraram problema até agora. Esse levantamento é o baseline, o ponto de partida documentado contra o qual toda parametrização nova de IBS e CBS deveria ser comparada.

Sem esse baseline, o time que parametriza o sistema para o novo regime trabalha a partir de uma suposição implícita: a de que o sistema atual já reflete corretamente a regra tributária vigente hoje, exceção por exceção. Essa suposição raramente é verdadeira em operações que cresceram, fizeram aquisição, mudaram de estado ou adicionaram linha de produto ao longo dos anos sem uma revisão fiscal completa e documentada.

Parametrizar o futuro sobre um estado atual não documentado não é economia de tempo. É transferir para dentro da nova arquitetura, de forma invisível, qualquer erro ou lacuna que já existia na antiga, com a diferença de que agora esse erro vem embutido numa arquitetura nova, mais difícil de auditar porque parece ter acabado de ser revisada.

Por que o Controller é quem mais sente essa lacuna

O Controller costuma ser a pessoa que primeiro percebe, na prática operacional, quando uma premissa de parametrização não bate com a realidade: é quem concilia o fechamento, quem explica uma divergência entre o esperado e o apurado, quem responde quando um número não fecha e precisa investigar a causa raiz antes que vire pauta do CFO. Quando o projeto de adequação à Reforma avança sem baseline documentado, é o Controller quem herda, meses depois, a tarefa de descobrir por que uma combinação específica de produto e estado está gerando um resultado inesperado sob o novo regime, sem ter, à disposição, um documento que diga como aquela mesma combinação era tratada antes.

Essa é a tensão real entre automação e controle que aparece neste tema: automatizar a nova parametrização é rápido e tecnicamente viável. Manter controle sobre o que, exatamente, está sendo automatizado, e sobre qual base de conhecimento essa automação foi construída, exige o trabalho mais lento e menos visível de documentar o estado atual antes de decidir o que muda. As duas coisas não competem entre si, mas a segunda costuma perder a disputa por atenção e prazo quando o projeto é tratado como tarefa técnica de TI, sem dono formal do lado fiscal.

Um cenário real: a exceção que ninguém documentou

Imagine uma distribuidora com operação em cinco estados, SAP implantado há oito anos, sem grande incidente fiscal recente. O time de TI e o time fiscal iniciam a parametrização de IBS e CBS com base na documentação de implantação original: o desenho técnico está correto, o cronograma do art. 125 e do art. 126 do ADCT está mapeado, os prazos estão sob controle. O que essa documentação original não registra é que, três anos atrás, uma exceção fiscal específica para um tipo de operação interestadual passou a ser tratada manualmente, fora do sistema, porque uma regra de determinação automática apresentava um comportamento considerado "estranho" por um analista, que decidiu contornar em vez de investigar a causa raiz, e nunca documentou essa decisão em lugar nenhum além da própria rotina da equipe.

Sem um baseline que capturasse esse tipo de exceção viva, o time que parametriza IBS e CBS trabalha com a premissa de que a determinação automática do sistema já cobre esse cenário corretamente, porque é isso que a documentação original diz. A exceção manual, que existe há três anos na rotina real da equipe mas nunca em nenhum documento formal, simplesmente desaparece da nova arquitetura, porque ninguém perguntou sobre ela antes de desenhar o novo leiaute. O problema só aparece de novo quando a mesma operação interestadual acontecer sob o regime novo, e alguém perceber, tarde demais para corrigir antes do fechamento, que o comportamento automático voltou a se repetir exatamente como antes, agora sem a correção manual que vinha sendo aplicada informalmente há três anos por uma única pessoa da equipe.

O que um baseline mínimo precisa conter

Um mapeamento de estado atual, para servir de fato como referência antes da parametrização de IBS e CBS, precisa registrar pelo menos três camadas de informação. A primeira é o inventário de regras de determinação de imposto realmente ativas no sistema hoje, incluindo customizações Z que alteram o comportamento padrão, com a lógica de cada uma explicada em linguagem que alguém fora do time técnico consiga entender. A segunda é o inventário de exceções tratadas fora do sistema, seja em planilha paralela, seja em ajuste manual recorrente no fechamento, porque essas exceções são exatamente o tipo de conhecimento que se perde quando a atenção do time vai inteira para a parametrização nova.

A terceira camada é o registro de combinações de operação, produto, estado e natureza fiscal que nunca foram efetivamente testadas, porque não geraram volume relevante até agora. Uma combinação rara sob o regime atual pode deixar de ser rara sob o regime novo, ou pode continuar rara mas crítica o suficiente para que sua ausência de teste vire um problema real no primeiro fechamento sob IBS e CBS. Sem essa terceira camada mapeada, o time só descobre a lacuna quando ela já aconteceu na operação real, não antes.

Onde essa disciplina se conecta com o motor fiscal

Num ambiente que já usa um motor fiscal integrado ao SAP, como o Guepardo Tax, o baseline documentado tem um segundo uso, além de servir de referência para a parametrização de IBS e CBS: ele vira o material de conferência para validar se a nova configuração produz o mesmo resultado que a operação real produzia antes, transação por transação, nas combinações mapeadas como críticas. Sem esse material de referência, testar a nova parametrização vira um exercício de "parece razoável" em vez de um exercício de comparação objetiva contra um comportamento documentado. Com ele, cada teste de cenário pode responder a uma pergunta concreta: esse resultado bate com o que a operação de fato fazia, ou é uma mudança de comportamento que precisa ser explicada e aprovada antes de seguir?

Essa diferença importa especialmente durante o período de coexistência entre os regimes antigo e novo, que vai de 2026 a 2033 segundo o cronograma do ADCT. Um baseline bem documentado permite que o time compare, lado a lado, o resultado sob o regime atual e o resultado sob IBS e CBS, para a mesma operação, e identifique com precisão onde a diferença é esperada, porque a lei mudou, e onde a diferença é sintoma de uma parametrização que não capturou corretamente uma exceção que já existia antes da Reforma.

O caminho prático: baseline antes do leiaute

Isso não significa atrasar o projeto de parametrização técnica, o cronograma constitucional do art. 125 e do art. 126 do ADCT não espera. Significa inverter a ordem de duas tarefas que costumam rodar em paralelo sem hierarquia clara: primeiro, um levantamento estruturado e documentado do estado atual, ainda que rápido e focado nas operações de maior volume e maior risco; só depois, ou em paralelo já orientado por esse levantamento, a parametrização técnica do novo leiaute. A diferença prática entre as duas ordens é que, na segunda, cada decisão de parametrização pode ser confrontada contra um documento real de como a operação funciona hoje, em vez de contra a memória de quem participou da implantação original do SAP, anos atrás.

Um Diagnóstico Fiscal Estruturado, quando aplicado nesse momento do projeto, tem exatamente essa função: produzir o baseline documentado, com as três camadas descritas acima, priorizadas pelo volume e pelo risco de cada operação, antes que a parametrização de IBS e CBS avance sobre uma base que ninguém revisou formalmente. A decisão sobre qual tese tributária adotar em cada exceção mapeada continua sendo inteiramente do cliente; o papel da consultoria é entregar o mapeamento completo que torna essa decisão possível de tomar com informação real, em vez de suposição herdada de anos atrás.

A pergunta que vale levar para o próximo status de projeto é direta: existe hoje um documento que descreve como a determinação de imposto realmente funciona na operação, com exceções e customizações mapeadas, ou o time está parametrizando o leiaute novo direto sobre a memória de como o sistema foi implantado originalmente? Se fizer sentido produzir esse baseline completo antes do próximo ciclo de parametrização, estou disponível para conversar.