Risco fiscal em SAP: o imposto que muda depois da nota, e o gatilho que o motor fiscal ainda não tem

O motor fiscal do SAP decide o imposto no momento em que a operação acontece. A nota fiscal sai, o esquema de cálculo roda, a alíquota e a situação tributária ficam definidas, e o documento segue seu caminho contábil como se aquela decisão fosse definitiva. Para a esmagadora maioria das operações, ela é. A LC 214/2025 introduz um conjunto de regras em que essa decisão não é definitiva: o imposto correto na emissão pode se tornar incorreto depois, em função de um fato que acontece fora da nota, fora do sistema e fora do controle de quem emitiu o documento. Este documento descreve esse mecanismo a partir de dois dispositivos com o texto lido por inteiro, caput a último parágrafo, e explica por que ele exige uma resposta diferente da que o SAP já sabe dar para "imposto que depende de terceiro".

A objeção que qualquer gerente de SAP vai levantar primeiro

Antes de qualquer coisa, uma objeção precisa ser nomeada, porque quem já rodou um projeto fiscal brasileiro vai fazê-la de qualquer forma: "isso não é novo, o ICMS-ST já fazia o imposto depender de dado de terceiro." A objeção está certa, em parte. Substituição tributária, diferimento e alíquota interestadual já obrigam o motor fiscal a olhar para fora da própria operação: o substituto recolhe pela cadeia inteira, a alíquota interestadual depende do estado do destinatário, o diferimento depende do uso que o adquirente vai dar ao insumo. O SAP resolve isso há anos, com condição de parceiro e tabela de determinação. Se a tese fosse só "a Reforma faz o imposto depender de dado de terceiro", ela cairia na primeira frase de qualquer revisão técnica.

Não é essa a tese. O que o ICMS-ST não tinha, e que aparece em pelo menos dois dispositivos com o texto lido por inteiro na LC 214/2025, é um desenho em dois momentos: o imposto se decide na operação, do jeito de sempre, e depois, dentro de um prazo definido em lei, um evento externo confirma ou desfaz essa decisão. O ICMS-ST decide tudo com o dado que já está disponível no instante da operação. Os casos abaixo decidem parte do imposto num instante, e revisam essa decisão num segundo instante, que não está sob controle de quem emitiu a nota.

Dois casos, lidos por inteiro, não uma lista

Os dois casos abaixo têm os dois dispositivos legais lidos caput a último parágrafo, o que sustenta o exemplo nomeado. Podem existir outros dispositivos com desenho parecido na LC 214/2025, mas eles não entram aqui como exemplo, porque exemplo nomeado exige o texto conferido por inteiro, não uma lista de candidatos.

Art. 106, §§ 2º e 3º, suspensão que vira alíquota zero, ou volta a ser devida, para beneficiário do Reidi. O caput do art. 106 restringe esse regime a quem já é beneficiário habilitado do Regime Especial de Incentivos para o Desenvolvimento da Infraestrutura (Reidi): a importação e a aquisição no mercado interno de máquinas, aparelhos, instrumentos e equipamentos novos, e de materiais de construção, destinados a obra de infraestrutura para o ativo imobilizado, saem com suspensão do pagamento do IBS e da CBS. O § 2º condiciona a conversão dessa suspensão em alíquota zero a um evento que só se confirma depois da operação: a efetiva utilização ou incorporação do bem, do material de construção ou do serviço na obra. Se esse evento não acontecer, o § 3º não deixa dúvida sobre a consequência: o beneficiário fica obrigado a recolher o IBS e a CBS que estavam com o pagamento suspenso, acrescidos de multa e juros de mora, contados da data do fato gerador original, não da data em que alguém percebeu a falta. No SAP, a nota de aquisição já foi emitida com a suspensão aplicada no momento zero; não existe, hoje, um gatilho automático que pergunte, semanas ou meses depois, "esse bem foi mesmo incorporado à obra dentro do prazo, e a suspensão que virou, ou devia virar, alíquota zero ainda está correta". Fora do universo de beneficiários do Reidi, este mecanismo específico não se aplica: não é um risco genérico de "qualquer bem incorporado a uma obra", é um risco concreto para quem já opera dentro desse regime especial, um público menor, mas exposto a exatamente o padrão de segunda decisão descrito acima.

Art. 445, § 4º, entrada física na Zona Franca de Manaus. Texto literal: "Caso não haja comprovação de que os bens destinados à Zona Franca de Manaus ingressaram no destino, nos prazos estabelecidos em regulamento, o contribuinte deverá recolher o valor de IBS e de CBS que seria devido caso não houvesse a redução a zero de alíquotas, com os acréscimos legais cabíveis, na forma do § 2º do art. 29 desta Lei Complementar". A operação sai com um tratamento tributário favorecido, próprio do destino Zona Franca, decidido na emissão. O que confirma, ou derruba, esse tratamento é um fato logístico que acontece depois, fora do documento fiscal: o bem chegou fisicamente ao destino, dentro do prazo, ou não chegou. Se não chegou, o imposto que a nota tratou como não devido volta a ser devido, e alguém precisa perceber isso, dentro do prazo do regulamento, para não deixar a cobrança avançar sem resposta.

Os dois casos compartilham a mesma estrutura: decisão na emissão, evento externo depois, prazo definido em lei para esse evento se confirmar ou não. Nenhum dos dois é sobre calcular errado. Os dois são sobre decidir certo num momento e não ter, no sistema, quem verifique se aquela decisão ainda é válida no momento seguinte.

O contraste: quando o dado já existe, só está no lugar errado

Para não deixar a impressão de que toda a LC 214/2025 é evento futuro, vale mostrar o contraste com casos de outro tipo, o de dado de terceiro comum, o mesmo território que o ICMS-ST já ensinou o SAP a resolver.

Art. 169, § 1º, II, crédito presumido de frete. O artigo trata do crédito presumido de IBS e CBS sobre frete pago a transportador autônomo pessoa física ou MEI. O § 1º distingue dois cenários pela forma como o frete é cobrado do adquirente: o inciso I mantém o crédito quando o adquirente paga o frete como cobrança própria, destacada, de serviço de transporte; o inciso II nega o crédito quando o valor do transporte está embutido no valor da operação principal, mesmo que discriminado em separado no documento. Não é um caso de "quem contratou o frete". É um caso de composição de base de cálculo, o tipo de regra que no SAP costuma viver em condição de preço, não em cadastro de parceiro: o dado já está na nota, só que precisa ser lido do lugar certo.

Art. 223, II, a, seguro e regime do segurado. O tratamento depende de o segurado ser ou não contribuinte do regime regular, um atributo que pertence ao terceiro, não à operação em si. É o mesmo desenho do ICMS-ST: o SAP já resolve isso com determinação por atributo de parceiro de negócio.

Art. 144, II, comprador órgão público ou entidade CEBAS. O tratamento depende de uma qualificação cadastral do comprador. É um caso de habilitação, resolvido com campo novo e mantido no cadastro de cliente, checagem no momento da venda, sem segundo evento depois.

Art. 57, § 3º, IV, f, plano de saúde por acordo coletivo. O crédito só existe quando o plano de saúde decorre de acordo ou convenção coletiva de trabalho, uma condição que normalmente não mora no SAP, mora em RH e em jurídico. É dado de terceiro que exige integração entre sistemas, não só configuração dentro do módulo fiscal.

Os quatro casos acima reforçam a mesma linha: dado de terceiro, mesmo quando espalhado entre módulos e departamentos diferentes, é problema que o SAP já sabe nomear e resolver, com condição de parceiro, campo de cadastro, integração de sistema. O risco novo, o que os dois primeiros casos mostram, é outro: não é a origem do dado, é o momento em que ele se confirma.

Onde essa regra vive hoje no SAP, e onde não vive

Vale ser preciso sobre nome de objeto, porque um nome errado destrói a credibilidade do documento na primeira linha lida por quem trabalha com isso todo dia. Material técnico publicado pela própria SAP sobre o impacto da Reforma Tributária brasileira nos usuários SAP registra, em texto literal, os seguintes nomes: TAXBRA e TAXBRJ, esquemas de cálculo usados em modificações de montante base para CBS e IBS; RVAB, o procedimento de determinação de preços associado a essas modificações; e BAdI (Business Add In), o mecanismo usado para determinar a situação tributária de CBS e IBS, com campo próprio adicionado à estrutura correspondente. A distinção funcional exata entre TAXBRA e TAXBRJ não ficou explícita no material lido, e não há fonte que defina qual se aplica a qual cenário.

Sobre obrigação acessória, o SAP S/4HANA Advanced Compliance Reporting (ACR) tem escopo declarado pela própria SAP: criação, geração e entrega de obrigações acessórias para as autoridades fiscais, no prazo e no formato corretos. É reporte, não determinação de imposto na operação e não reabertura de documento já emitido. O SAP Document and Reporting Compliance (DRC) aparece confirmado como nome de produto real em material da própria SAP, mas o escopo funcional específico dele não ficou confirmado nas fontes que lemos, e por isso não descrevemos o que o DRC faz.

Fora esses nomes confirmados, a regra que decide alíquota e situação tributária costuma viver, na prática de projeto, em tabela de parametrização e em desenvolvimento próprio, mas não há, em fonte oficial, confirmação de que o termo de mercado usado para nomear esse objeto seja o correto para o contexto de CBS e IBS. O mecanismo fica descrito; o nome do objeto fica de fora, por falta de fonte.

O que nenhuma fonte lida descreve: reabertura automática

No material técnico disponível publicamente sobre ACR, DRC e sobre o SAP em geral, não há descrição de um mecanismo que reabra automaticamente um documento fiscal já emitido quando um evento posterior confirma ou desfaz o tratamento tributário aplicado na emissão. A ausência é de descrição pública, e ausência de sinal não é prova de que a funcionalidade não exista em algum lugar do produto. O que se pode afirmar com precisão é o estado da documentação: nas fontes públicas disponíveis, esse mecanismo não está descrito.

Sobre o Guepardo Tax, produto da NTT DATA, nenhuma fonte pública conhecida descreve tratamento específico para evento futuro pós-operação. O que o produto faz ou deixa de fazer nesse ponto segue sem fonte pública que sustente qualquer afirmação.

Declaramos aqui, sem rodeio, o próprio interesse: a DFSpro vende exatamente esse tipo de trabalho, desenho, configuração e prova de comportamento do sistema fiscal em SAP e Guepardo Tax. Um documento que finge neutralidade que não existe vale menos do que um documento que diz de onde fala.

Quem decide quando o evento acontece

Um risco fiscal que depende de evento futuro só é gerenciável se existir um processo formal por trás dele, com dono definido. Isso não é achado de pesquisa de mercado, é julgamento nosso, baseado no que os dois casos conferidos exigem na prática: alguém precisa confirmar que o bem foi incorporado à obra, ou que o bem entrou fisicamente na Zona Franca, dentro do prazo. Alguém precisa acionar a correção quando o prazo passa sem confirmação. E precisa ficar registrado quem confirmou o quê, e quando.

Sem esse processo, a lacuna descrita nas seções anteriores não vira um risco de configuração de sistema, vira um risco de governança: o sistema pode até ter o campo certo, mas ninguém olha para ele no momento certo. É o tipo de falha que não aparece em nenhum teste técnico convencional, porque o teste técnico convencional roda no momento da operação, não semanas depois, quando o evento externo acontece ou deixa de acontecer.

Como se testa isso antes do próximo fechamento

Um cenário de teste fiscal tradicional simula a operação e confere se o imposto saiu certo naquele instante. Isso não é suficiente para os dois casos descritos aqui, porque o erro que importa não acontece na emissão, acontece na ausência de uma segunda checagem depois. Testar de verdade exige simular também o evento futuro: o bem chegou à Zona Franca dentro do prazo, ou não chegou; o bem foi incorporado à obra, ou não foi. E depois verificar, com o mesmo rigor que se aplica ao teste da operação original, se o sistema reabre e corrige o documento sozinho, ou se depende de alguém lembrar de olhar, sem gatilho nenhum apontando para aquele documento específico.

Enquanto essa segunda camada de teste não existir, um projeto de adequação pode passar por toda a bateria de testes convencional e ainda assim deixar exatamente esse tipo de caso sem cobertura, porque o teste nunca chegou a simular o segundo momento da decisão.

Fechamento

O motor fiscal do SAP decide bem o que sempre decidiu bem: imposto a partir do que está na nota, no momento da nota. A LC 214/2025 introduz, em pelo menos dois dispositivos com o texto lido por inteiro, e possivelmente em outros ainda não lidos com o mesmo rigor, uma segunda decisão, tomada depois, por um fato que a nota não registra sozinha. O risco não é só o dado de terceiro, esse o SAP já sabe resolver. O risco é não ter, hoje, quem pergunte, no momento certo, se aquela primeira decisão continua valendo.

A decisão sobre a tese tributária aplicada em cada caso é sempre do cliente. A DFSpro desenha, configura e prova como o sistema se comporta diante desse tipo de regra, com evidência registrada, não com promessa genérica. Se a sua operação tem tratamento tributário condicionado a um evento que só se confirma depois da nota, o Diagnóstico Fiscal Estruturado mapeia exatamente esse tipo de lacuna antes do próximo fechamento.