Quando TI muda algo no SAP e o Fiscal descobre depois, isso tem correção
Um patch aplicado. Uma customização ajustada. Um upgrade de versão. Qualquer uma dessas mudanças pode alterar como o SAP calcula, registra ou transmite uma obrigação fiscal. Sem um checkpoint fiscal formal, isso não é falta de comunicação: é a ausência de um processo de governança entre duas áreas que otimizam para objetivos diferentes.
O sintoma tem uma assinatura reconhecível
Patch de correção
Um patch de correção aplicado por TI altera, sem intenção, a forma como uma alíquota é calculada.
Customização de performance
Uma customização feita para resolver um problema de performance muda a ordem de processamento de um lançamento fiscal.
Upgrade de versão
Um upgrade de versão do SAP redefine o comportamento padrão de um campo que alimentava a integração com o GUEPARDO Tax.
Em nenhum desses três casos há má-fé. Em todos os três, existe uma mudança técnica registrada no log de TI, sem um registro correspondente de que a área Fiscal validou o impacto dela antes de essa mudança entrar em produção.
O sinal mais claro de que este é o seu problema: a mudança já aconteceu, mas ninguém sabe apontar, com data e nome, quem no Fiscal avaliou o impacto tributário dela antes do go live.
Fiscal e TI não estão competindo. Estão otimizando para objetivos diferentes.
Conformidade
A área Fiscal precisa de conformidade: a regra tributária certa, aplicada da forma certa, todo mês, sem exceção.
Estabilidade e performance
A área de TI precisa de estabilidade e performance: o sistema no ar, respondendo bem, sem regressão técnica. Os dois objetivos são legítimos. Nenhum dos dois está errado.
O problema aparece quando uma mudança que resolve o objetivo de TI tem um efeito colateral fiscal que ninguém do lado da conformidade foi chamado a avaliar antes. Não é falta de boa vontade. É a ausência de um ponto formal, no fluxo de mudança técnica, onde o Fiscal precisa dizer sim antes do deploy.
Sem esse ponto de verificação, a divergência entre as duas áreas não é uma exceção ocasional. É o resultado esperado de dois times competentes trabalhando sem um processo comum entre eles.
O custo aparece depois, quando já é mais caro corrigir do que teria sido prevenir
Quando uma mudança técnica altera comportamento fiscal sem checkpoint, duas consequências se repetem.
A primeira é a autuação: o Fisco identifica a divergência antes da própria empresa, e a defesa fica mais difícil porque não existe registro de que a mudança foi avaliada tecnicamente do ponto de vista tributário.
A segunda é o retrabalho: quando a divergência é percebida internamente, alguém precisa reconstruir o que mudou, quando mudou e qual foi o efeito acumulado, muitas vezes revisando meses de lançamentos já fechados.
Nenhum dos dois custos aparece no momento da mudança técnica em si. Aparece depois, quando a janela para corrigir de forma simples já fechou.
O Diagnóstico Fiscal SAP mapeia exatamente onde esse checkpoint existe e onde falta
Mapeamento
Mapeamento do fluxo real de mudanças técnicas no ambiente SAP.
Análise
Análise de onde essas mudanças têm potencial de impacto fiscal.
Priorização
Priorização dos pontos de maior risco por criticidade (Crítico, Alto, Médio, Monitorar).
O processo inteiro leva de 5 a 8 semanas, conduzido por equipe sênior, e termina com um mapa concreto de onde a governança Fiscal↔TI existe de fato, e onde ela é só uma suposição.
Não é uma auditoria genérica de sistema. É um mapeamento específico do ponto de fricção entre as duas áreas, com prioridade clara sobre o que resolver primeiro.
Para o CIO e o Gerente SAP: isso não é mais uma dependência, é um processo que reduz o seu próprio risco
A objeção mais comum de quem lidera TI diante deste tema é direta: "já temos um processo de change management, isso não resolveria?" Na maioria dos casos, não resolve, porque o change management de TI foi desenhado para proteger estabilidade e performance do sistema. Ele não tem, por padrão, um checkpoint formal que pergunte "esta mudança altera algum comportamento fiscal, e o Fiscal já validou isso?"
Corresponsável, não executor
O Technical Buyer deixa de ser apenas quem executa a mudança técnica e passa a ser corresponsável pelo desenho do processo que evita o problema se repetir, com base no conhecimento técnico real (parametrização, integração com o GUEPARDO Tax, arquitetura Clean Core) que só quem administra o sistema tem.
Reduz o próprio risco, não cria dependência nova
Isso não cria uma dependência nova de terceiro. Cria um processo documentado que reduz o risco de o próprio CIO ser responsabilizado, depois do fato, por uma mudança técnica que teve efeito fiscal não avaliado.
Cinco perguntas para avaliar se esse risco já existe na sua operação
01
Checkpoint formal existe?
Existe um ponto formal no processo de change management de TI onde uma mudança técnica precisa ser avaliada quanto ao impacto fiscal antes de ir para produção?
02
Fiscal é avisado antes?
Se essa mudança alterar uma regra de cálculo, parametrização de imposto ou integração com o GUEPARDO Tax, o Fiscal é notificado antes do deploy, ou só descobre no fechamento seguinte?
03
Responsável nomeado?
Existe um responsável nomeado, do lado Fiscal, que precisa aprovar formalmente mudanças técnicas com potencial impacto tributário?
04
Processo de reconstrução?
Quando uma divergência fiscal é identificada depois de uma mudança técnica, existe um processo documentado para reconstruir o que mudou e desde quando, ou isso depende de investigação manual caso a caso?
05
Última mudança teve registro?
A última mudança técnica relevante no ambiente SAP (patch, customização, upgrade) passou por esse checkpoint fiscal, com registro?
Se a resposta a duas ou mais dessas perguntas for "não" ou "não sei", o risco já está presente na operação, mesmo que nenhuma autuação tenha acontecido ainda.
Duas Especialidades diretamente ligadas a este problema
Diagnóstico Fiscal SAP
Mapeia, em 5 a 8 semanas, onde o checkpoint fiscal↔TI existe e onde falta, priorizando os pontos de maior risco.
AMS Fiscal de Governança
É o modelo de continuidade: sustenta o monitoramento contínuo depois que o checkpoint é desenhado, para que uma nova mudança técnica não reabra a mesma lacuna meses depois.
Perguntas frequentes sobre divergência entre Fiscal e TI
01Já temos um processo de change management em TI. Isso não resolveria o problema sozinho?+
Na maioria dos casos, não, porque o change management de TI é desenhado para proteger estabilidade e performance do sistema, não para validar impacto fiscal. É exatamente esse checkpoint fiscal formal, dentro do fluxo já existente de TI, que costuma faltar.
02Isso é um problema de comunicação entre as áreas, ou algo mais estrutural?+
É estrutural. Fiscal e TI otimizam legitimamente para objetivos diferentes (conformidade e estabilidade, respectivamente). Sem um ponto formal de validação cruzada, a divergência é o resultado esperado dessa diferença de objetivo, não uma falha pontual de comunicação.
03Quantas empresas realmente têm esse problema?+
O padrão aparece de forma recorrente em operações SAP com mudanças técnicas frequentes. O Diagnóstico Fiscal SAP confirma a extensão do risco na sua operação.
04O CIO ou o Gerente SAP precisa participar da conversa inicial, ou isso é assunto só do CFO?+
Precisa participar desde o início. O checkpoint fiscal↔TI só funciona na prática se for desenhado junto com quem administra o ambiente técnico, não imposto de fora para dentro.
05Como sei se a divergência é entre Fiscal e TI ou entre unidades?+
Se o descompasso é entre a regra que o Fiscal define e o que a TI implementa no mesmo ambiente, é o caso desta página. Se é entre CNPJs/unidades diferentes tratando a mesma regra, o tema é Governança fiscal multi-CNPJ.
06Isso se resolve com mais reuniões entre as áreas?+
Raramente. Sem um ponto formal no processo onde o impacto fiscal é validado antes de a mudança ir para produção, o alinhamento depende de memória e boa vontade, e a divergência volta a aparecer.
07Um checkpoint fiscal no change management resolve?+
É justamente o mecanismo estrutural que trata a causa: um ponto formal onde toda mudança técnica é avaliada quanto ao impacto fiscal antes de entrar em produção, em vez de descobrir o efeito no fechamento seguinte.
08A Reforma Tributária piora essa divergência?+
Tende a piorar, porque a transição CBS/IBS aumenta o volume de mudanças de regra que precisam ser refletidas corretamente no sistema. Sem o checkpoint fiscal, cada mudança vira uma nova chance de divergência.
09Quem precisa estar na conversa inicial?+
Vale ter, além do Fiscal, o CIO ou o Gerente SAP, porque a solução envolve o processo de change management de TI, não só a regra fiscal. Não é um assunto exclusivamente da área fiscal.
10Por onde começa a tratar a divergência Fiscal e TI?+
Pelo Diagnóstico Fiscal SAP, que mapeia onde a regra definida diverge do que está parametrizado e identifica onde falta o checkpoint fiscal no fluxo de mudanças.
Do checkpoint que falta ao processo que sustenta
O problema, com precisão: não existe, hoje, um ponto formal no fluxo de mudança técnica do SAP onde o Fiscal precisa validar o impacto tributário antes de uma mudança ir para produção. Patch, customização ou upgrade seguem o processo de change management de TI, que protege estabilidade e performance, mas não tem, por padrão, esse checkpoint.
O custo real de deixar como está: a divergência entre o que o Fiscal definiu e o que o sistema de fato calcula só é percebida depois, no fechamento seguinte, ou pior, em uma fiscalização, quando a defesa fica mais difícil por não existir registro de que a mudança foi avaliada tecnicamente do ponto de vista tributário. Cada mês sem o checkpoint é mais um lançamento fechado sob esse risco não avaliado.
Como resolvemos, passo a passo:
- Mapeamos o fluxo real de mudanças técnicas no ambiente SAP, sem presumir que o change management de TI já cobre o fiscal.
- Analisamos onde essas mudanças têm potencial de impacto fiscal (parametrização, integração com o GUEPARDO Tax).
- Priorizamos os pontos de maior risco por criticidade (Crítico, Alto, Médio, Monitorar).
- Desenhamos, junto com o CIO ou o Gerente SAP, o ponto formal de validação cruzada Fiscal↔TI dentro do fluxo já existente.
Serviço que entrega isso: o Diagnóstico Fiscal SAP mapeia e prioriza o risco em 5 a 8 semanas; a continuidade, para que a lacuna não reabra meses depois com a próxima mudança técnica, é sustentada pelo AMS Fiscal de Governança.
O que você recebe: um mapa concreto de onde a governança Fiscal↔TI existe de fato e onde ela é só uma suposição, com prioridade clara sobre o que corrigir primeiro, não um relatório genérico de auditoria de sistema.
Primeiro passo concreto: uma conversa com o Fiscal e com quem administra o ambiente SAP para levantar se o checkpoint já existe formalmente hoje, e desenhar a partir daí se o Diagnóstico Fiscal SAP é o próximo passo.
Mapear, não presumir
Se você reconheceu o padrão descrito nesta página, um diagnóstico estruturado mapeia exatamente onde o checkpoint fiscal↔TI existe, onde falta, e o que priorizar primeiro.