Seu S/4HANA passou em 340 casos de teste técnico. Nenhum validou se o imposto está certo.

Organização com forte governança de TI tem processo de teste rigoroso. Centenas de casos de teste definidos, executados e aprovados antes de qualquer go-live. A metodologia existe, é seguida, e o histórico de projetos mostra que ela funciona.

Para projetos S/4HANA com componente fiscal relevante, essa rigidez técnica tem uma lacuna específica: casos de teste técnico e casos de teste fiscal são tipos diferentes de teste, com critério diferente de aprovação.

Caso de teste técnico valida que o sistema processa sem erro: transação executa, documento é gerado, integração funciona, dados são gravados. Caso de teste fiscal valida que o resultado do processamento corresponde à regra tributária vigente para aquela combinação específica de produto, operação, estado de origem e estado de destino.

Um sistema pode passar em 340 casos de teste técnico e ter Tax Code incorreto em 8 combinações de produto e estado que nenhum desses casos testou. O go-live é aprovado. O primeiro fechamento revela os 8 combinações.

Por que os dois tipos de teste têm lógicas diferentes

Teste técnico parte do sistema: dado de entrada definido, fluxo executado, dado de saída verificado contra o esperado. O critério de aprovação é consistência interna: o sistema faz o que foi configurado para fazer.

Teste fiscal parte da legislação: regra tributária identificada para aquela combinação de variáveis (produto, operação, estado), dado de entrada definido de forma que exercite exatamente aquela regra, resultado verificado contra o que a regra tributária exige. O critério de aprovação é conformidade externa: o sistema produz o resultado que a lei determina para aquela situação.

A diferença de ponto de partida muda quem precisa definir os casos de teste.

Casos de teste técnico podem ser definidos pelo time de TI com base no mapeamento de processos do sistema. Casos de teste fiscal precisam ser definidos com participação do time fiscal, porque a lógica de cobertura não é de processos de sistema, é de combinações de variáveis tributárias que precisam ser exercitadas.

Em organizações com forte governança de TI, o time de TI tem domínio do processo de teste. Tem metodologia, tem ferramentas, tem histórico. O que pode faltar é o parceiro fiscal que define quais combinações tributárias precisam ser exercitadas, com qual resultado esperado. Sem esse parceiro na fase de design dos casos, os casos de teste fiscal nunca entram no plano.

O mapa de cobertura fiscal que nenhum plano de teste técnico tem

Plano de teste técnico de projeto S/4HANA cobre fluxos e processos: pedido de compra, entrada de mercadoria, nota fiscal de saída, pagamento, apuração de impostos, geração de SPED. Para cada fluxo, os casos de teste verificam que o sistema executa o fluxo corretamente.

O que esse plano não cobre é o mapa de combinações tributárias da operação: para cada categoria de produto, em cada estado de origem e destino, com cada natureza de operação (venda para revenda, venda para consumidor final, transferência entre filiais, devolução), qual é a regra de ICMS, de ICMS-ST, de PIS e de COFINS vigente?

Esse mapa é o que determina quais combinações precisam ser testadas para garantir que o S/4HANA está apurando corretamente toda a operação da empresa. Sem esse mapa, o plano de teste cobre os fluxos mas não cobre as combinações tributárias dentro de cada fluxo.

Em operação com 150 categorias de produto, operando em 12 estados, com 8 naturezas de operação diferentes, o número de combinações tributárias únicas pode ser na ordem de centenas. Não todas precisam de caso de teste separado. Mas as que têm regra tributária específica diferente do padrão certamente precisam.

Identificar quais combinações têm regra específica é trabalho do time fiscal, não do time de TI. E esse trabalho precisa acontecer antes da definição dos casos de teste, não depois do go-live.

O que o time fiscal precisa contribuir no design dos cenários de teste

Participação do time fiscal no design de cenários de teste fiscal tem três entregas específicas.

A primeira é o mapeamento das combinações tributárias críticas. Para a operação da empresa, quais são as combinações de produto, estado e natureza de operação que têm regra tributária específica que precisa ser validada? Quais são as categorias de produto com tratamento fiscal diferenciado (produtos monofásicos, produtos com substituição tributária, produtos com alíquota diferenciada de PIS/COFINS)? Quais são os estados com regras de ICMS-ST específicas para determinadas categorias?

A segunda é a definição do resultado esperado para cada combinação crítica. Para a combinação produto X operando em transferência entre filial do estado A para filial do estado B, qual é a alíquota de ICMS-ST esperada, qual é a base de cálculo e qual é o Tax Code que deveria ser aplicado? Esse resultado esperado é o que vai ser comparado com o que o S/4HANA produz no caso de teste.

A terceira é a definição de critério de aprovação fiscal por combinação. Se o S/4HANA aplica Tax Code diferente do esperado, o caso de teste falha, mesmo que o sistema não tenha produzido nenhum erro técnico. Esse critério de aprovação fiscal precisa estar explícito no plano de teste, separado do critério de aprovação técnica.

Como integrar teste fiscal ao processo existente de governança de TI

A boa notícia para organizações com forte governança de TI é que a estrutura de processo de teste já existe. O que precisa ser adicionado é a camada de definição fiscal dentro dessa estrutura.

Antes da fase de design dos casos de teste: incluir uma etapa de levantamento de combinações tributárias críticas com o time fiscal. O output é o mapa de combinações que precisam ser cobertas.

Na fase de design dos casos: incluir casos de teste fiscal ao lado dos casos de teste técnico. Para cada caso fiscal, o time fiscal valida o resultado esperado antes de o caso entrar no plano.

Na fase de execução e homologação: incluir aprovação do time fiscal para os casos de teste fiscal, separada da aprovação técnica. Go-live com todos os casos técnicos aprovados e algum caso fiscal reprovado não é go-live pronto.

Essa integração não aumenta significativamente o volume de trabalho se o mapeamento de combinações críticas for feito com critério: não se trata de testar todas as combinações possíveis, mas as que têm regra tributária específica diferente do padrão.

Cinco cenários que a Reforma cria e que nenhum roteiro de teste atual cobre

Os casos de teste de uma migração são escritos a partir do que o sistema já faz. A LC 214/2025 introduz comportamentos que ainda não existem em produção, e por isso não aparecem em roteiro nenhum. Cinco deles já têm dispositivo escrito e podem ser desenhados agora, mesmo antes de o ambiente do outro lado existir.

1. Apuração que chega pronta: pelo art. 46, o Comitê Gestor do IBS e a RFB podem apresentar a apuração assistida do saldo, e pelo § 2º a apuração da empresa passa a ser feita somente mediante ajustes sobre ela. O teste não é de cálculo: é medir em quanto tempo a operação localiza a origem de uma divergência entre duas apurações e a transforma em ajuste.

2. Retido diferente do devido: pelo art. 34, IV, o split payment não afasta a responsabilidade do sujeito passivo pelo saldo a recolher. O cenário a testar é o valor segregado na liquidação não bater com o apurado no período, e a pergunta é se a conciliação entre as duas pontas existe ou se ninguém a escreveu.

3. Documento sem imposto: o art. 60, § 2º, I, mantém a obrigação de emitir documento fiscal eletrônico inclusive em operações imunes, isentas, com alíquota zero ou suspensão. O caso de teste é uma operação que não gera valor a recolher e mesmo assim precisa sair classificada corretamente.

4. Transferência entre estabelecimentos: pelo art. 6º, II, não há incidência na transferência entre estabelecimentos do mesmo contribuinte, e o art. 60, § 2º, II, mantém a obrigação de emitir documento. É o fluxo menos revisado do cadastro, justamente porque nunca teve imposto associado.

5. Venda parcelada: pelo art. 34, II, com pagamento parcelado pelo fornecedor, a segregação ocorre de forma proporcional na liquidação de todas as parcelas. E o inciso III acrescenta que a antecipação de recebíveis não altera essa obrigação.

Os cinco têm uma característica em comum que explica por que escapam do plano de teste técnico: nenhum deles falha com erro na tela. Em todos, o sistema processa, a transação conclui e o log fica limpo. O que muda é o resultado fiscal e a capacidade de explicar esse resultado depois, que são exatamente as duas coisas que um roteiro escrito a partir de funcionalidade não sabe verificar.

O que o CIO precisa garantir antes de o próximo go-live S/4HANA ser aprovado

Duas confirmações precisam existir antes de qualquer aprovação de go-live com componente fiscal relevante.

A primeira: os casos de teste do projeto incluem casos de teste fiscal definidos com participação do time fiscal, com resultado esperado explícito e critério de aprovação separado do critério técnico?

A segunda: os casos de teste fiscal cobrem as combinações tributárias críticas da operação, não apenas os fluxos técnicos?

Se as respostas forem não, o go-live vai ser aprovado com confiança técnica e incerteza fiscal. O primeiro fechamento vai medir o tamanho da incerteza.

Esse mapa de combinações tributárias críticas é o mesmo que precisa existir antes de qualquer migração para S/4HANA, inclusive quando o projeto já está em andamento e ninguém documentou as dependências fiscais que o ECC aprendeu a esconder.

Na DFSpro, o Diagnóstico Fiscal Estruturado de cobertura de cenários de teste fiscais para projetos S/4HANA identifica as combinações tributárias críticas que precisam ser cobertas e define os critérios de aprovação fiscal por combinação. Se faz sentido ter esse mapeamento antes de o plano de teste ser finalizado, o Diagnóstico Fiscal Estruturado é o caminho.