Clean core em projeto multipaís multiplica a regra fiscal que ninguém revisou

Um projeto de clean core em ambiente único já exige separar dois tipos diferentes de auditoria: a arquitetural (a extensão é estável, documentada, sobrevive a um upgrade?) e a fiscal (a regra tributária dentro dela está correta e atualizada?). Num projeto multipaís, esse mesmo cuidado precisa ser multiplicado, e é exatamente aí que a maioria dos projetos de grande porte falha sem perceber. Os quatro níveis de extensibilidade da SAP (A a D) medem conformidade arquitetural de forma global e consistente entre países. Eles não medem, em nenhum país, se a regra fiscal que foi movida para dentro da extensão está correta para aquela jurisdição específica.

Este artigo não decide como sua empresa deve estruturar o roadmap de clean core de um projeto multipaís, essa é uma decisão de arquitetura e de priorização de recurso que cabe ao cliente. O que este artigo mostra é uma multiplicação de risco que raramente aparece explicitada no plano de projeto: se uma regra fiscal é realocada (não redesenhada) para uma extensão de nível A, e essa mesma extensão é replicada para operar em cinco países, a empresa não tem uma regra fiscal não revisada, tem cinco, cada uma com legislação, prazo e critério de correção próprios.

Este texto é um recorte específico de um ponto que já tratamos em profundidade no artigo "Clean Core reduz risco técnico. O risco fiscal, se a regra não for redesenhada, só mudou de endereço", que explica por que os quatro níveis de extensibilidade da SAP (A a D) nunca avaliam correção fiscal, só conformidade arquitetural. Aquele artigo trata o mecanismo num ambiente único. Este aqui vai um passo além: o que acontece quando o mesmo template de extensão é replicado para vários países ao mesmo tempo, dentro de um único programa de rollout.

O que a conformidade arquitetural garante, e o que ela nunca prometeu garantir

A definição oficial da SAP para clean core é sobre estabilidade de upgrade e dívida técnica: manter o núcleo do sistema limpo, padrão e estável para atualização, permitindo diferenciação específica de negócio onde ela realmente importa. Os quatro níveis de extensibilidade, de A a D, classificam uma extensão pela forma como ela usa interface pública e estável da SAP, não pelo conteúdo de negócio que ela carrega dentro. Uma extensão nível A é, por definição, arquiteturalmente sólida em qualquer país onde ela rodar, porque o critério de nível A (uso de interface pública, ausência de objeto interno não suportado) não muda de jurisdição para jurisdição.

É exatamente essa uniformidade que cria a armadilha em projeto multipaís. Um time de arquitetura pode, com toda honestidade técnica, reportar ao board que cem por cento das extensões fiscais do rollout multipaís estão em nível A ou B, um resultado excelente do ponto de vista de estabilidade e manutenibilidade. Esse relatório não diz nada, porque não foi desenhado para dizer nada, sobre se a lógica de cálculo de imposto dentro de cada uma dessas extensões está correta para a legislação vigente em cada país específico onde ela foi implantada.

Por que a regra fiscal não viaja bem entre países

Uma regra fiscal desenvolvida para o Brasil carrega premissas que fazem sentido só dentro do sistema tributário brasileiro: alíquota de ICMS por estado, obrigação acessória como o SPED, substituição tributária, regime de crédito específico. Quando um projeto de clean core realoca essa lógica para uma extensão padronizada, e depois replica a mesma arquitetura de extensão para operar em outro país, a estrutura técnica se mantém idêntica, mas o conteúdo fiscal que fazia sentido na origem raramente faz sentido no destino sem revisão completa.

Isso parece óbvio quando dito em voz alta, nenhum arquiteto sério assumiria que a regra de ICMS brasileira se aplica na Alemanha. O problema real não é essa confusão grosseira, é mais sutil: quando o time de arquitetura padroniza o padrão de extensão entre países (mesma estrutura de nível A, mesmo template de customização, mesma forma de expor a lógica de negócio), existe uma tentação natural de assumir que o trabalho de padronização arquitetural também resolveu a padronização de conteúdo fiscal, porque as duas coisas parecem parte do mesmo projeto de modernização. Não são. Uma é reutilização de arquitetura. A outra é revisão de conformidade tributária, país por país, sem atalho.

Um template de extensão nível A reutilizado em cinco países entrega cinco arquiteturas estáveis. Entrega zero regras fiscais revisadas, a menos que alguém tenha feito, país por país, o trabalho que o template não faz sozinho.

Onde a multiplicação de risco realmente acontece

A multiplicação não é apenas aritmética (cinco países, cinco vezes o risco de um). Ela é estrutural, porque cada país adiciona uma dimensão de complexidade que os outros não compartilham: prazo de vigência de norma diferente, autoridade fiscal diferente, formato de obrigação acessória diferente, e, frequentemente, um time local diferente responsável por validar aquela regra específica, com nível de proximidade e prioridade diferente em relação ao projeto central de clean core.

Um projeto de grande porte, gerido centralmente, tende a medir progresso pela métrica que o board entende, percentual de extensões migradas para nível A ou B, prazo de entrega do rollout, número de países ativados. Nenhuma dessas métricas, por desenho, captura se a regra fiscal de cada país foi revisada e testada com cenário local real. O risco cresce silenciosamente exatamente onde a métrica de sucesso do projeto não olha.

A diferença entre rollout técnico e rollout fiscal completo

Vale nomear a diferença entre dois tipos de "pronto" que um projeto multipaís de clean core pode declarar. O primeiro é o rollout técnico pronto: a extensão está implantada, testada tecnicamente, estável, em conformidade arquitetural com o padrão nível A ou B, em todos os países do escopo. O segundo é o rollout fiscal completo: além de tudo isso, a lógica de negócio fiscal dentro de cada extensão foi revisada contra a legislação vigente daquele país específico, testada com cenário fiscal real (não só o caso padrão que passa sem erro), e documentada com evidência de quem validou.

Um projeto pode, honestamente, declarar o primeiro tipo de "pronto" sem ter avançado nada no segundo. Isso não é fraude nem negligência deliberada, é consequência direta de como as duas auditorias (arquitetural e fiscal) são conduzidas por equipes diferentes, com cronograma diferente, e frequentemente sem um ponto de sincronização formal entre elas dentro do plano mestre do projeto.

O que um plano de rollout multipaís precisa ter, além do cronograma técnico

Para que a revisão fiscal país por país não fique invisível dentro do cronograma técnico do clean core, o plano de rollout multipaís precisa tratar cada país como uma linha própria de trabalho fiscal, com dono nomeado, critério de aprovação específico e evidência exigida antes de o país ser declarado "pronto" no sentido fiscal completo, não só técnico. Isso significa que o gate de aprovação de cada país não pode ser só "a extensão passou no teste técnico de nível A", precisa incluir "a regra fiscal foi revisada e testada com cenário local real por alguém com competência para validar aquela legislação específica".

Na prática, isso costuma exigir um recurso que projetos técnicos de clean core raramente orçam desde o início: especialista fiscal local, ou parceiro com conhecimento da legislação daquele país, dedicado à revisão de cada extensão antes de ela ser considerada concluída ali. Sem esse recurso explicitamente alocado, o trabalho de revisão fiscal tende a ficar em segundo plano, empurrado para depois do go-live, quando a pressão de cronograma técnico já passou e a atenção do projeto se moveu para o próximo país do rollout.

O custo de descobrir a lacuna tarde é maior em projeto multipaís do que em ambiente único

Num projeto de clean core em ambiente único, descobrir tardiamente que uma regra fiscal foi realocada sem revisão gera um problema de escopo concentrado, uma correção, um teste, uma decisão sobre quando aplicar. Num rollout multipaís, o mesmo tipo de descoberta tardia tende a se repetir em cada país onde o mesmo template de extensão foi replicado, porque a causa raiz (padronização arquitetural confundida com padronização de conformidade fiscal) não é exclusiva de um país específico, é uma característica do próprio processo que gerou todos eles.

Isso significa que, se a lacuna for descoberta depois que vários países já estiverem em produção, o esforço de correção não é multiplicado de forma linear, é multiplicado com o agravante de que cada país já tem operação real rodando sobre a regra não revisada, com histórico de apuração acumulado que também precisa ser reavaliado. Corrigir a arquitetura de uma extensão é, comparativamente, mais simples do que reconstituir o histórico fiscal de múltiplas jurisdições que já processaram meses ou anos de operação sobre uma regra que, em algum momento, precisa ser corrigida.

Por que esse risco não aparece no relatório de status do projeto

Relatório de status de projeto de grande porte é, por natureza, otimizado para comunicar progresso de forma agregada ao board: percentual de países ativados, marcos técnicos cumpridos, orçamento consumido versus planejado. Esse formato de relatório é útil para gestão executiva do cronograma, mas tem uma limitação estrutural: ele agrega exatamente o tipo de detalhe (a regra fiscal deste país específico foi ou não revisada com a mesma profundidade que a arquitetura técnica) que precisaria aparecer desagregado, país por país, para que o risco fique visível antes de virar problema.

Um board que recebe "92% dos países ativados, todos em conformidade nível A ou B" está recebendo uma informação verdadeira e, ao mesmo tempo, incompleta sobre o risco real do projeto, porque essa métrica não distingue entre um país onde a regra fiscal foi revisada com evidência documentada e um país onde ela foi apenas replicada do template original sem revisão local. As duas situações produzem exatamente o mesmo número no relatório de status.

Quatro perguntas para um projeto multipaís em andamento

Se você é o Diretor Fiscal ou CFO desse rollout, estas são as quatro perguntas que o seu CIO ou gerente de SAP precisa responder antes que você assine o "pronto" do projeto, e que medem se a dimensão fiscal está sendo tratada com o mesmo rigor da dimensão técnica:

1. O plano de rollout tem uma linha de trabalho fiscal própria, por país, separada da linha de trabalho de migração técnica de arquitetura?
2. Para cada país já declarado "pronto" tecnicamente, existe evidência documentada de que a regra fiscal migrada foi revisada e testada contra a legislação local vigente?
3. Quem, nomeadamente, tem competência e responsabilidade para validar a regra fiscal de cada país específico, e essa pessoa está formalmente alocada ao cronograma do projeto?
4. Se o relatório de nível de extensibilidade (A a D) fosse apresentado ao board como prova de conformidade fiscal, alguém no projeto perceberia o erro de interpretação antes de o board perceber?

Se a resposta a qualquer uma dessas perguntas for "não sei" ou "ainda não formalizamos", isso não significa que o projeto esteja com erro fiscal ativo em algum país agora. Significa que a dimensão fiscal do rollout multipaís está sendo administrada sem visibilidade formal equivalente à dimensão técnica, o que é uma posição de risco silencioso, não de risco medido e aceito conscientemente.

O papel da DFSpro nesse tipo de projeto

Mapear, país por país, onde a lógica fiscal foi realocada sem revisão completa dentro de um rollout de clean core, e desenhar o teste que prova o comportamento real do sistema para cada jurisdição específica, é trabalho de rastreabilidade fiscal aplicada a arquitetura de sistema. O Diagnóstico Fiscal Estruturado mapeia, país por país, onde a regra fiscal foi realocada sem revisão completa dentro do rollout de clean core. A decisão sobre como estruturar e priorizar o rollout multipaís continua sendo do cliente, sempre. O papel da DFSpro é garantir que a decisão sobre cada país seja tomada com evidência real de comportamento do sistema, não com a suposição de que um relatório de arquitetura estável equivale, silenciosamente, a uma regra fiscal já revisada.