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.
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.
Na DFS PRO, o diagnóstico 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, estou disponível.
TAKEAWAYS
- Teste técnico valida que o sistema faz o que foi configurado. Teste fiscal valida que o que foi configurado corresponde à regra tributária vigente.
- São dois tipos diferentes de teste com critérios diferentes de aprovação.
- Go-live aprovado apenas com teste técnico é go-live com incerteza fiscal não quantificada. O primeiro fechamento quantifica.
- O mapeamento de combinações tributárias críticas antes do design dos casos quantifica antes.
Emanuel Kaufman
Head of Business · DFS PRO IT Solutions · Curitiba, 2025
Especialista em estratégia B2B para operações fiscais críticas em SAP e Guepardo Tax. Atua na interface entre governança fiscal, tecnologia e decisão executiva.