Na leitura da DFSpro, 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 da lei 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. Na leitura da DFSpro, 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 da 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, não uma lista
Os dois casos abaixo vêm de dois dispositivos da LC 214/2025. Podem existir outros com desenho parecido, e cada um precisa ser lido no texto da lei antes de entrar no desenho do projeto.
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; na leitura da DFSpro, o motor decide na operação, e a pergunta que vem 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", é desenho de projeto. 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, na leitura da DFSpro, costuma viver no SAP 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 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.
O desgaste do fim de mês costuma vir de uma regra que ficou frouxa semanas antes. Quem reconhece o cenário pode começar por período fiscal que reabre.
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. Para documentos eletrônicos e relatórios estatutários, o tema passa pelo SAP Document and Reporting Compliance (DRC).
Na leitura da DFSpro, 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.
Reabertura automática de documento já emitido
Reabrir um documento fiscal já emitido, quando um evento posterior confirma ou desfaz o tratamento tributário aplicado na emissão, é o ponto que cada projeto precisa desenhar de forma explícita: na leitura da DFSpro, o motor fiscal decide na operação, e a revisão depois do evento exige processo, dono e prazo.
A DFSpro vende exatamente esse tipo de trabalho: desenho, configuração e prova de comportamento do sistema fiscal em SAP e Guepardo Tax.
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. Os dois casos mostram o porquê: 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
Na leitura da DFSpro, 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 e possivelmente em outros, 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.
O seu time consegue provar hoje que cada regra de segunda decisão está certa? Para ver onde está a lacuna: autoavaliação de prontidão fiscal. Se a dúvida for específica: fale com a DFSpro.
TAKEAWAYS
- Na leitura da DFSpro, o motor fiscal do SAP decide o imposto no momento da operação. Em pelo menos dois dispositivos da LC 214/2025 (art. 106 §2º, restrito a beneficiário do Reidi, e art. 445 §4º), esse imposto só se confirma depois, por um evento fora da nota.
- O risco não é o dado de terceiro comum: isso o ICMS-ST já ensinou o SAP a resolver, com condição de parceiro. O risco novo é reabrir e corrigir a operação quando o evento futuro acontece, ou deixa de acontecer, dentro do prazo: na leitura da DFSpro, o motor decide na operação, e a revisão depois do evento é desenho de projeto.
- Nomes de objeto SAP: TAXBRA e TAXBRJ (esquema de cálculo), RVAB (procedimento de determinação de preços), BAdI (determinação de situação tributária). O escopo do ACR é obrigação acessória, não reabertura de documento.
- Reabrir um documento já emitido quando o evento posterior acontece é parte do desenho do projeto, com processo, dono e prazo.
- O teste técnico convencional cobre a operação no momento da emissão. Cobrir o segundo momento, o evento que confirma ou desfaz o tratamento aplicado, exige simular esse evento e verificar se o sistema reabre o documento sozinho.