Dois motores fiscais no SAP: decisão de arquitetura, não ajuste temporário

Existe uma pergunta simples que, no que vemos em operações em transição para IBS/CBS, quase nunca é feita de forma explícita: quem decidiu, formalmente, que o SAP vai rodar dois motores de cálculo fiscal em paralelo, um para o regime antigo e outro para o novo, pelo tempo que a cadeia de fornecedores levar para migrar por inteiro? Na prática, ninguém decidiu. O sistema chegou a esse estado sozinho, ajuste por ajuste, porque parte dos fornecedores já opera sob IBS/CBS e parte ainda não, e alguém precisou fazer o cálculo funcionar dos dois jeitos ao mesmo tempo.

A Reforma Tributária, segundo a Emenda Constitucional 132/2023 (art. 125 do ADCT), começa com um ano de teste em 2026, com alíquotas simbólicas de IBS e CBS; a cobrança plena da CBS entra em vigor a partir de 2027 (art. 126 do ADCT); e a coexistência com ICMS e ISS, em redução progressiva, se estende até 2032, com extinção desses dois tributos antigos só a partir de 2033 (arts. 128 e 129 do ADCT). Isso não é uma opinião: é o cronograma constitucional da transição, e ele deixa claro algo que o texto legal não precisa dizer com todas as letras, porque decorre da própria lógica do calendário: nenhuma cadeia de fornecedores migra no mesmo dia.

Este artigo não decide se sua empresa deve investir agora em consolidar essa convivência entre motores fiscais como arquitetura formal, ou se pode esperar mais um ciclo. Essa decisão de prioridade e orçamento é sempre do cliente. O que este artigo mostra é por que, decidida ou não, essa convivência já existe, no que observamos, em operações com cadeia de fornecedores longa, e por que tratá-la como uma sequência de ajustes pontuais, em vez de reconhecê-la como decisão de arquitetura, tem um custo que só aparece depois.

O que significa, na prática, "dois motores fiscais em paralelo"

Em uma operação com centenas ou milhares de fornecedores, a transição para IBS/CBS não acontece de forma sincronizada. Alguns fornecedores já emitem documento fiscal sob o novo regime; outros, por questões próprias de prazo, porte ou sistema, continuam operando pelo regime anterior por mais tempo. Do lado da empresa que recebe essas notas, o SAP precisa reconhecer os dois formatos, aplicar a regra de cálculo correta para cada um, e decidir, operação a operação, qual caminho de apuração vale.

Isso normalmente começa como um ajuste técnico pequeno: uma condição a mais numa rotina de determinação de imposto, um campo novo de identificação de regime no cadastro do parceiro, uma exceção tratada caso a caso pela equipe fiscal. Cada mudança, isoladamente, parece pequena o suficiente para não precisar de aprovação formal, orçamento dedicado ou dono nomeado.

O problema não é o primeiro ajuste, nem o segundo. É o acúmulo. Depois de algumas dezenas de exceções tratadas uma a uma, o que existe no sistema não é mais "um ajuste temporário": é uma arquitetura de fato, com dois caminhos de cálculo coexistindo, decisões condicionais sobre qual aplicar, e nenhum documento que diga, de forma explícita, que essa arquitetura foi escolhida, e não apenas acontecida.

Essa é a distinção central deste artigo: existe uma diferença grande entre "a empresa decidiu manter dois motores fiscais em paralelo, com prazo e plano de simplificação" e "a empresa se viu, sem perceber o momento exato, mantendo dois motores fiscais em paralelo, sem que ninguém tenha assumido essa decisão como tal".

Por que isso é arquitetura, não parametrização temporária

Uma parametrização temporária tem três características que a convivência entre motores fiscais, no que observamos na prática, quase nunca tem: prazo definido de encerramento, responsável nomeado pela decisão de mantê-la, e critério explícito de quando ela deixa de ser necessária. Sem essas três coisas, o que existe não é temporário: é permanente até prova em contrário, porque nada no processo força uma revisão.

Rodar dois caminhos de cálculo fiscal ao mesmo tempo multiplica, de forma direta, o esforço de manutenção, de teste e de auditoria. Cada mudança de regra, cada nova SAP Note relacionada a IBS/CBS, cada ajuste de alíquota de referência publicado pelo Senado Federal (previsto nos arts. 130, I e II, do ADCT, para assegurar equivalência de arrecadação frente aos tributos substituídos) precisa, em tese, ser avaliado nos dois motores, não em um só. No que observamos, o que costuma acontecer é que o motor novo recebe atenção prioritária, por ser o foco da conformidade com a Reforma, e o motor antigo passa a ser mantido de forma reativa, só quando algo quebra.

Isso é um problema de governança de sistema, não de tecnologia. O SAP não impõe que a convivência entre regimes vire uma decisão não assumida: ele só executa a regra que foi configurada. O ponto cego está em quem decide, e quando, se essa convivência é uma arquitetura deliberada (com prazo, dono e plano de simplificação) ou um estado que a empresa foi empurrada a aceitar, ajuste por ajuste, sem nunca ter formalizado a decisão.

Há um detalhe do próprio cronograma constitucional que reforça por que tratar essa convivência como "ajuste pontual" é um erro de leitura, não só uma escolha de prioridade. O art. 130 do ADCT (Emenda Constitucional 132/2023) determina que resolução do Senado Federal fixe as alíquotas de referência do IBS e da CBS de forma a assegurar, ano a ano, equivalência de arrecadação com os tributos que estão sendo substituídos: de 2027 a 2033, para a União, e de 2029 a 2033, para Estados e Distrito Federal. Isso significa que a alíquota de referência não é um número combinado uma vez, no início da transição, e mantido fixo até 2033. É um valor recalculado periodicamente, por resolução própria, enquanto o motor antigo (ICMS, ISS, PIS, COFINS, IPI, conforme o caso) segue operando em paralelo com sua própria legislação, que não para de mudar por conta da Reforma. Manter dois motores fiscais em paralelo não é, portanto, manter duas fotografias congeladas do sistema tributário: é manter dois alvos que se movem em velocidades e calendários diferentes, o que aumenta, e não reduz, o custo de tratar essa convivência como uma sequência de ajustes reativos sem dono formal.

O que vemos o mercado fazer e por que isso não resolve sozinho

A resposta mais comum, quando o assunto aparece, é tratar cada exceção de fornecedor como um chamado técnico isolado: identifica o problema, ajusta a regra, valida a nota, segue em frente. Isso resolve o caso individual. O que essa resposta não resolve é a pergunta maior: em que ponto o acúmulo de exceções pontuais deixou de ser exceção e passou a ser a regra de funcionamento do sistema.

A abordagem padrão trata cada chamado como um evento isolado porque, isoladamente, cada um realmente é pequeno. O resultado é que a empresa acumula uma arquitetura de convivência entre dois regimes fiscais sem que ninguém tenha, em algum momento, parado para perguntar: quanto tempo essa convivência deve durar, e quando vale a pena investir em simplificá-la de vez, em vez de continuar mantendo os dois caminhos vivos.

Framework de 4 perguntas para reconhecer a arquitetura que já existe

Antes de decidir se a convivência entre motores fiscais na cadeia de fornecedores precisa virar um projeto formal, quatro perguntas ajudam a trazer a decisão do nível de "ajuste técnico" para o nível de "decisão de arquitetura", que é onde ela de fato pertence:

1. Existe hoje um mapa de quantos fornecedores da cadeia já operam sob IBS/CBS e quantos ainda não? Sem esse número, a empresa não sabe se está lidando com uma exceção pequena ou com metade da base de fornecedores em formato misto.

2. Quem é o responsável formal por decidir quando a convivência entre os dois motores deixa de ser necessária? Se a resposta demorar para vir, ou se não existir um nome claro, isso já é sinal de que a decisão nunca foi assumida como decisão, só aconteceu por acúmulo.

3. Cada nova regra de IBS/CBS (SAP Note, alíquota de referência publicada, ajuste de cronograma) está sendo avaliada nos dois motores, ou só no motor novo? Se só o motor novo recebe atenção sistemática, o motor antigo virou um passivo de manutenção não gerenciado.

4. Existe um critério objetivo, e não apenas uma expectativa informal, de quando a convivência será encerrada? "Quando a Reforma acabar" não é um critério operacional. Um critério real depende do ritmo de migração real dos fornecedores da própria cadeia, não do calendário legal isolado.

O papel do suporte reativo nessa história, e por que ele não resolve o problema de fundo

Um padrão comum, em operações que já acumularam essa convivência entre dois motores fiscais, é o suporte de SAP reagir a cada exceção de fornecedor como um chamado isolado: nota travou, ajusta a regra, libera a nota, fecha o chamado. Esse modelo funciona para o problema do dia, mas ele estrutura o incentivo errado: o time de suporte é medido por tempo de resolução do chamado individual, não por redução do número de exceções que a arquitetura de dois motores continua gerando mês após mês.

Um contrato de AMS Fiscal, diferente de um suporte tradicional por chamado, tem espaço para olhar o padrão por trás dos chamados, não só o chamado em si. Se o mesmo tipo de exceção de fornecedor aparece repetidamente, isso é sinal de que a convivência entre os dois motores não está sendo tratada como arquitetura, e sim resolvida, chamado a chamado, sem que ninguém acumule o aprendizado sobre onde a regra de determinação de imposto ainda depende de intervenção manual. Essa distinção entre corrigir o sintoma repetido e reconhecer o padrão por trás dele é, na prática, o que separa um suporte reativo de uma governança fiscal contínua.

Como funciona um caminho estruturado para essa decisão

O caminho que vemos funcionar, quando esse tipo de situação já foi bem diagnosticado, começa por medir, não por presumir: levantar o percentual real de fornecedores que já migraram, mapear cada rotina do SAP que hoje trata os dois formatos de forma condicional, e verificar se cada mudança de regra da Reforma está sendo aplicada aos dois motores ou só a um. Só depois desse mapeamento é possível decidir, com informação real, se vale investir em consolidar a convivência como arquitetura formal (com plano de simplificação e prazo) ou se o ritmo de migração da cadeia ainda não justifica esse investimento agora.

Um Diagnóstico Fiscal Estruturado é o primeiro passo lógico para esse mapeamento: ele mostra, com dado real e não com percepção, em que estado está a convivência entre regimes na sua cadeia de fornecedores, que rotinas do SAP carregam esse risco de manutenção duplicada, e que decisões de arquitetura estão sendo tomadas por omissão, sem que ninguém tenha assumido isso formalmente.

A decisão continua sendo sua, com o problema nomeado corretamente

A convivência entre dois motores fiscais, durante o período de coexistência entre o regime antigo e o novo, não é um defeito de projeto: é uma consequência esperada de uma transição legal que, segundo o cronograma da Emenda Constitucional 132/2023, se estende até 2033. O problema não é a convivência existir. É ela existir sem que ninguém tenha decidido, formalmente, que ela deveria existir daquela forma, por aquele tempo, sob aquela responsabilidade.

A decisão de quando e como consolidar essa arquitetura é sempre da empresa, nunca de quem desenha ou configura o sistema. O que este artigo propõe é nomear o problema pelo nome certo: não é um conjunto de ajustes temporários, é uma decisão de arquitetura pendente de dono e prazo. Vale perguntar, hoje: a convivência entre os dois motores fiscais na sua cadeia de fornecedores foi reconhecida como decisão de arquitetura, com dono e prazo definidos, ou continua sendo tratada como uma sequência de ajustes técnicos sem revisão marcada?