Seu relatório de Clean Core prova arquitetura limpa. Não prova que a regra fiscal foi revisada.

Clean core é apresentado, com frequência, como sinônimo de menos risco. É uma leitura incompleta. Clean core reduz risco técnico: menos customização dentro do núcleo do SAP significa upgrade mais previsível, menos atrito de manutenção, menos dependência de código proprietário difícil de rastrear. Isso é real e vale defender. Só que risco técnico e risco fiscal não são a mesma coisa, e uma regra tributária que sai de dentro do core para uma extensão fora dele não fica mais correta só por ter mudado de endereço.

Vale descer ao concreto, porque no ambiente brasileiro a distinção deixa de ser conceitual. A regra tributária no SAP não mora num lugar só: parte dela está nas estruturas mantidas pela J1BTAX e no esquema de cálculo TAXBRA, parte nos Tax Codes de FTXP, e parte no que foi escrito por cima disso, historicamente em código Z e, num projeto de clean core, tipicamente numa implementação de BAdI fora do núcleo. O projeto de limpeza mexe na terceira camada. As duas primeiras ficam onde estavam.

Isso determina o que o board está de fato aprovando ao assinar o orçamento: uma melhoria de arquitetura, com ganho documentado de estabilidade, ou essa mesma melhoria apresentada como se também fosse redução de exposição fiscal, sem que ninguém tenha testado a segunda parte. As duas custam orçamento parecido. O que cada uma deixa para trás é diferente.

O que a SAP promete de fato com clean core

A definição oficial não é vaga. Segundo o SAP News Center, em artigo publicado em 12 de agosto de 2025 (lido em 2026-08-31), a estratégia busca "keep the core clean, standard, and upgrade-stable while still enabling business-specific differentiation where it counts", evitando que a paisagem SAP fique "weighed down by custom code, undocumented changes, and hard-to-maintain integrations".

Para colocar disciplina nessa promessa, a SAP passou a classificar toda extensão em quatro níveis de conformidade:

1. Nível A: extensões que usam só interfaces públicas e estáveis da SAP.

2. Nível B: extensões compatíveis, que também usam APIs clássicas e tecnologias já suportadas.

3. Nível C: extensões parcialmente compatíveis, com acesso a objetos internos da SAP. A própria SAP registra que, para esse nível, "to minimize upgrade risks, SAP plans to provide a changelog", ou seja, mesmo a fornecedora trata esse nível como fonte potencial de instabilidade.

4. Nível D: extensões não recomendadas, usando objetos ou técnicas explicitamente desaconselhadas. A classificação da própria SAP é direta: "these represent the highest risk and create significant technical debt".

Esse modelo de quatro níveis é sobre estabilidade de upgrade e dívida técnica. Uma extensão pode estar perfeitamente enquadrada como nível A, cem por cento aderente às boas práticas de arquitetura da SAP, e ainda assim carregar uma regra fiscal desatualizada, incompleta ou com exceção não documentada. A conformidade arquitetural do nível A não avalia se o cálculo de ICMS-ST embutido naquela extensão está certo. Ela avalia se a extensão sobrevive a um upgrade sem quebrar.

O que a definição oficial não aborda, e por que isso importa

A cobertura oficial de clean core, tanto no material da própria SAP quanto na literatura técnica especializada que documenta o tema, converge num conjunto fixo de benefícios: upgrades mais fáceis, estabilidade, adoção mais rápida de inovação, redução de custo total de propriedade, arquitetura mais flexível, melhor desempenho, alinhamento com a estratégia de nuvem.

Nenhum desses sete benefícios é sobre conformidade tributária. Não é uma omissão isolada de uma fonte; é o próprio escopo do conceito. Clean core é uma metodologia de engenharia de software e governança de extensibilidade. Ela não foi desenhada para avaliar se uma regra de cálculo de imposto está correta, atualizada ou compatível com a legislação vigente. Isso é papel de outro processo, que não acontece automaticamente só porque a extensão está bem arquitetada.

Essa lacuna não é motivo para descartar clean core. É motivo para não confundir dois tipos de auditoria diferentes: a auditoria de arquitetura (a extensão é estável, documentada, sobrevive a um upgrade?) e a auditoria fiscal (a regra dentro dessa extensão está correta e atualizada?). Um projeto pode passar integralmente na primeira e falhar silenciosamente na segunda.

Onde a lógica fiscal costuma estar escondida antes da limpeza

Em ambientes SAP com anos de operação, é comum que regra fiscal não more só em transação padrão. Ela se acumula em camadas: uma customização Z criada para compensar uma parametrização de Tax Code que nunca foi corrigida na origem; uma exceção de ICMS-ST que foi resolvida com ajuste manual antes do fechamento em vez de correção na tabela; uma integração com sistema satélite que aplica uma regra de cálculo própria, fora do SAP, porque foi mais rápido resolver ali do que revisar a parametrização central.

Nenhuma dessas camadas aparece como "problema fiscal" no dia a dia. Elas aparecem como "assim que sempre funcionou". Quando um projeto de clean core entra nesse ambiente com o objetivo de tirar customização de dentro do core, essas camadas são candidatas naturais à remoção ou à migração para uma extensão fora dele. E aqui está o ponto central: mover uma customização Z para uma extensão nível A não altera uma linha da lógica fiscal que ela carrega. A régua de compliance da extensão mudou. A régua fiscal continua a mesma, com as mesmas exceções não revisadas.

Realocar não é redesenhar

A diferença entre os dois verbos decide qual dos dois riscos caiu:

1. Realocar: é mover a regra de um lugar tecnicamente sujo para um lugar tecnicamente limpo, preservando o comportamento exatamente como estava.

2. Redesenhar: é revisar a regra em si, na origem, contra a legislação vigente, antes de decidir onde ela vai morar na nova arquitetura.

Um projeto de clean core que só realoca entrega um resultado real: o core fica mais limpo, o upgrade fica mais previsível, a dívida técnica cai. É um ganho de arquitetura genuíno. O que não acontece, nesse cenário, é redução de risco fiscal. A mesma exceção de ICMS-ST que nunca foi revisada continua exatamente a mesma, só que agora roda numa extensão nível A, bem documentada, upgrade-stable, dentro de todas as boas práticas de arquitetura. Tecnicamente impecável. Fiscalmente, sem nenhuma mudança.

Apresentar isso ao board como redução de risco fiscal é um erro de tradução entre dois tipos de risco. O que caiu foi o risco técnico de manutenção do core. O risco fiscal, se a regra não foi redesenhada, apenas mudou de posição no mapa.

A pergunta que o board raramente faz

Para um Diretor Fiscal ou CIO que está diante de um roadmap de clean core com escopo fiscal, existe uma pergunta objetiva que separa discurso de comportamento provado, projeto por projeto:

1. A regra fiscal que está sendo movida foi revisada contra a legislação vigente antes da migração, ou só foi copiada como estava?
2. Quem assinou essa revisão, e qual evidência existe dela (documento de teste, comparação de resultado antes/depois, aprovação de área fiscal)?
3. A extensão resultante foi testada com cenários fiscais reais (nota com exceção, operação interestadual, regra de substituição tributária), não só com o cenário padrão que passa sem erro?
4. Se essa extensão for auditada por um Fisco estadual amanhã, existe rastreabilidade de que a regra foi conferida na migração, ou o histórico é só "sempre funcionou assim"?

Se a resposta para a primeira pergunta for "foi copiada como estava", o projeto entregou clean core de arquitetura, não redução de risco fiscal. Isso não invalida o investimento em clean core. Só significa que ele precisa ser apresentado ao board pelo que de fato é: uma melhoria de estabilidade e manutenibilidade técnica, com o risco fiscal tratado como item separado, com dono, prazo e evidência próprios. Separar os dois itens antes da assinatura do orçamento é o primeiro entregável de um Diagnóstico Fiscal Estruturado aplicado a um roadmap de clean core.

Nível de extensibilidade não substitui teste fiscal

Na conversa entre TI e fiscal esse ponto costuma se perder: aprovar uma extensão como nível A ou B na régua de clean core é um evento de arquitetura, com critério técnico próprio (uso de interface pública, estabilidade de upgrade, ausência de objeto interno da SAP). Esse evento não inclui, em nenhuma etapa do próprio modelo de quatro níveis, um teste de cenário fiscal contra a legislação vigente. São dois checklists diferentes, mantidos por áreas diferentes, com critérios de aprovação que não se sobrepõem.

Isso significa que um projeto pode reportar, com honestidade técnica, cem por cento das extensões fiscais migradas em nível A, e ainda assim carregar risco fiscal não avaliado. As duas afirmações não se contradizem, porque medem coisas diferentes. O problema aparece quando o relatório de arquitetura é lido pelo board como se fosse, também, um relatório de conformidade fiscal. Ele não é, e nunca foi desenhado para isso.

Por isso, a recomendação prática para quem está revisando um roadmap de clean core com escopo fiscal é simples de enunciar e difícil de pular sob pressão de cronograma: pedir, para cada extensão fiscal migrada, as duas evidências separadas. Uma prova de conformidade arquitetural (o relatório de nível A/B/C/D). E uma prova de conformidade fiscal (teste de cenário real, comparação de resultado antes e depois da migração, assinatura de quem validou). Quando só a primeira existe, o projeto está documentando arquitetura limpa, não risco fiscal reduzido.

Como se prova, no sistema, que a regra sobreviveu à mudança

A prova não é documental, é de execução: rodar o mesmo conjunto de documentos fiscais antes e depois da migração da extensão e comparar o resultado linha a linha. Não o total do período, que esconde compensação entre erros de sinal contrário, mas o valor por item, por Tax Code e por CFOP. Uma exceção de ICMS-ST que mudou de comportamento aparece em duas ou três linhas de um universo de milhares, e some por completo quando a comparação é feita no agregado.

O conjunto de teste precisa conter o que normalmente não entra no roteiro: nota com exceção de substituição tributária, operação interestadual com redutor, devolução, remessa sem valor fiscal, e o item cuja classificação foi corrigida à mão em algum fechamento passado. O cenário padrão passa sempre. Ele passava antes da migração e vai passar depois, e é exatamente por isso que ele não prova nada. Fechando o ciclo: a saída do SPED Fiscal do período de teste, gerada nos dois ambientes, é o artefato que o Fisco olharia, então é ele que precisa bater.

Qual regra manter, qual redesenhar e qual aceitar como risco residual é decisão do cliente. O que precede essa decisão é comportamento medido, não pressuposto herdado. Se o seu projeto de clean core tem escopo fiscal e essas duas evidências, o mapa de onde a regra mora hoje e a comparação de resultado antes e depois, ainda não existem separadamente, um Diagnóstico Fiscal Estruturado gera as duas antes que o Fisco pergunte primeiro.