setembro 1, 2026
guilherme

A Reforma Tributária já chegou ao backlog do SAP

A Reforma Tributária costuma começar em reuniões do fiscal e da controladoria. Mas ela entra em produção pelas mãos de TI.

Novos campos de CBS e IBS, mudanças nos documentos fiscais eletrônicos, atualizações do padrão nacional da NFS-e, regras de retenção, arredondamento, classificação tributária e particularidades municipais precisam ser traduzidos em parametrização, integração, XML, desenvolvimento ABAP, testes e transportes.

É nesse momento que a discussão deixa de ser apenas tributária.

Uma regra fiscal correta, implementada de forma errada, ainda pode impedir a emissão de uma nota, interromper o faturamento ou gerar uma inconsistência em produção. A lei pode estar compreendida pelo time fiscal e, mesmo assim, o ambiente SAP não estar tecnicamente preparado.

A pergunta que TI precisa responder não é somente “quais tributos mudaram?”. A pergunta é:

quantas mudanças precisarão atravessar o ambiente SAP, em qual ordem, com quais dependências e com que evidência de teste?

A documentação técnica da NFS-e vem recebendo atualizações ao longo de 2026. A Nota Técnica SE/CGNFS-e no 009 consolidou evoluções que afetam a Declaração de Prestação de Serviços (DPS) e a NFS-e gerada, incluindo adequações para o CNPJ alfanumérico e grupos relacionados a IBS/CBS. O Portal Nacional da NFS-e registrou novas implantações em produção em agosto de 2026, reforcando que a adequação precisa ser tratada como acompanhamento contínuo, não como uma entrega única.

Atualização regulatória: em 30 de julho de 2026, o Ato Conjunto RFB/CGIBS no 4 formalizou o cronograma de obrigatoriedade dos documentos fiscais eletrônicos; em 31 de julho, o Ato Técnico Conjunto no 1 aprovou documentação técnica relacionada. Para datas operacionais, a referência deve ser sempre o ato oficial e a versão técnica vigente.

Esse cenário exige uma estrutura continua de acompanhamento. Tratar a Reforma como um único projeto, com uma única entrega, cria uma falsa sensação de conclusão.

O impacto da Reforma Tributária dentro do SAP

O alcance exato depende da arquitetura e das customizações de cada empresa. Em geral, a análise precisa passar por cinco camadas.

1. Processos de negócio

Devem ser mapeados processos como:

• order-to-cash;

• procure-to-pay;

• faturamento de serviços;

• recebimento fiscal;

• apuração;

• devoluções e cancelamentos;

• retenções;

• pagamentos;

• integrações com prefeituras e provedores fiscais.

O objetivo não é apenas identificar módulos. E entender em quais pontos uma nova regra fiscal pode alterar o comportamento do processo de ponta a ponta.

2. Parametrizações

A adequação pode exigir revisão de códigos tributários, determinação de impostos, classificação das operações, condições, regras por empresa, estabelecimento, serviço, município ou cenário fiscal.

Alterar uma parametrização sem registrar a justificativa, os cenários afetados e as evidências de teste aumenta o risco de a correção de um caso quebrar outro.

3. Documentos fiscais e integrações

Os novos layouts precisam ser refletidos nos XMLs, nas mensagens trocadas com provedores e nos retornos dos autorizadores. A empresa deve localizar:

• estruturas de XML alteradas;

• campos obrigatórios e condicionais;

• APIs, RFCs, IDocs, web services e middlewares envolvidos;

• validações realizadas fora do SAP;

• tratamentos específicos de rejeição;

• regras diferentes por município;

• conciliações entre documento fiscal, contabilização e pagamento.

4. Desenvolvimentos próprios

Objetos Z, user exits, BAdIs, enhancements, relatórios, formulários e integrações podem conter regras fiscais que não serão atualizadas automaticamente por uma SAP Note. Quanto maior o histórico de customizações, maior a necessidade de inventário.

Sem esse mapa, a empresa corre dois riscos: deixar um objeto impactado de fora ou alterar um objeto sem saber quais processos dependem dele.

5. Governança de mudanças

Cada SAP Note, ajuste de parametrização, correção ABAP e mudanca de integração precisa percorrer uma esteira controlada. Isso inclui demanda, responsável, escopo, request, dependências, testes, aprovação, janela de transporte, plano de reversão e evidência pos-produção.

A Reforma não cria esse problema. Ela revela a maturidade, ou a falta dela, na governança do ambiente.

Checklist técnico para a adequação do SAP

Etapa 1. Criar um inventário fiscal e tecnológico

Comece pelos documentos e processos, não pelas SAP Notes. Liste:

• quais documentos fiscais a empresa emite e recebe;

• quais empresas, filiais e estabelecimentos estão envolvidos;

• quais municípios possuem tratamentos próprios;

• quais provedores fiscais participam da arquitetura;

• quais módulos SAP executam cada etapa;

• quais integrações recebem ou enviam dados tributários;

• quais objetos Z contem regras fiscais.

O resultado deve ser uma matriz que conecte processo, documento, sistema, objeto técnico, responsável e criticidade.

Etapa 2. Verificar a linha de base do ambiente

Antes de implementar qualquer correção, registre o estado atual do SAP:

• versão do ECC ou S/4HANA;

• SAP_BASIS;

• Support Packages;

• componentes de localização;

• versão do Note Assistant;

• notas já implementadas;

• modificações manuais;

• débitos técnicos relacionados ao processo fiscal;

• divergencias entre desenvolvimento, qualidade e produção.

A mesma SAP Note pode ter requisitos e efeitos diferentes conforme a versão e o Support Package. Sem uma linha de base confiável, a equipe pode diagnosticar como “erro da nota” algo que, na verdade, e incompatibilidade, pré-requisito ausente ou modificação anterior.

Etapa 3. Montar uma matriz de SAP Notes e dependências

Não trate SAP Notes como uma lista de tarefas independentes. Para cada nota, registre:

• número e versão;

• componente afetado;

• release aplicável;

• pré-requisitos;

• notas substituídas;

• objetos alterados;

• necessidade de atividade manual;

• necessidade de customizing;

• request associada;

• responsável pela validação;

• cenários de teste.

O Note Assistant reconhece dependências e estados de implementação, mas isso não elimina a necessidade de uma avaliação funcional e arquitetural. Uma nota tecnicamente implementável pode exigir um conjunto de testes muito maior do que o texto inicial sugere.

Aprofunde: veja o processo completo em SAP Notes: como aplicar, testar e transportar correções sem criar incidentes.

Etapa 4. Mapear objetos Z e integrações impactados

Pesquise referências a estruturas, campos, tabelas e regras fiscais alteradas. A análise deve cobrir:

• programas ABAP;

• classes e metodos;

• exits e BAdIs;

• CDS Views;

• formulários;

• interfaces;

• jobs;

• tabelas próprias;

• regras hardcoded;

• tratamentos de rejeição;

• rotinas de arredondamento;

• lógica específica por prefeitura.

Objetos que não possuem documentação devem ser classificados por risco e criticidade. Uma mudanca na estrutura de um documento pode afetar muito mais do que o programa que gera o XML. Pode atingir relatórios, contabilização, conciliação e integrações downstream.

Etapa 5. Retirar regras municipais do código rigido

Empresas que emitem NFS-e em vários municípios convivem com layouts, códigos, validações e exigências diferentes. Escrever cada particularidade diretamente no código cria uma cadeia crescente de condicionais, alto custo de manutenção e risco de regressão.

Sempre que tecnicamente possível, regras municipais devem ser tratadas como configuração:

• município;

• tipo de serviço;

• regime;

• exigibilidade;

• retenção;

• código nacional;

• código municipal;

• NBS;

• campos aplicáveis;

• versão de layout;

• vigência.

Essa arquitetura permite atualizar uma regra sem reescrever toda a solucao.

Em um case publicado pela QAMetrik, um configurador de NFS-e permitiu atender 80 prefeituras e reduziu o esforco de implementação de 40 para 4 horas por município. O custo unitário reportado caiu de R$ 6.000 para R$ 600.

Case relacionado: o aprendizado e mais importante que o número: particularidade municipal deve virar configuração reutilizável, não código rigido repetido. Veja o case do configurador de NFS-e.

Etapa 6. Isolar as mudanças da Reforma

Misturar correções fiscais urgentes com melhorias comuns do backlog dificulta testes, aprovação e reversão. Crie uma estrutura de governança que permita identificar claramente:

• programa ou onda regulatória;

• entrega fiscal relacionada;

• SAP Notes incluidas;

• objetos Z alterados;

• parametrizações;

• documentos afetados;

• requests dependentes;

• data de vigência;

• janela de implantação.

Requests excessivamente grandes devem ser evitadas. Uma request jumbo torna a análise de dependência mais difícil e amplia o impacto de qualquer rollback.

Etapa 7. Construir uma matriz de testes por risco

Testar apenas a emissão bem-sucedida de uma nota não é suficiente. A matriz deve contemplar:

• emissão;

• cancelamento;

• substituição;

• devolução;

• retenção;

• não incidência;

• redução ou exceção aplicável;

• arredondamento;

• multiplos itens;

• multiplos municípios;

• serviços com tratamentos diferentes;

• rejeição do autorizador;

• indisponibilidade do provedor;

• reprocessamento;

• contabilização;

• conciliação;

• integração com contas a receber ou pagar.

Além dos testes funcionais, realize regressão nos cenários que não deveriam mudar. O maior risco nem sempre está na nova regra. Pode estar num processo antigo que passou a receber uma estrutura diferente.

Etapa 8. Governar a sequência de transportes

A ordem de importação importa. Uma mudanca pode depender de estrutura, programa, configuração ou nota implementada anteriormente. Transportar fora de sequência cria versões inconsistentes e falhas dificeis de diagnosticar. A própria documentação do SAP TMS sobre filas de importação destaca a importância de preservar a ordem de transporte. Antes do go-live, valide:

• dependências entre requests;

• objetos repetidos em requests diferentes;

• versões existentes nos ambientes;

• sequência de importação;

• aprovações;

• evidências de teste;

• plano de reversão;

• responsáveis durante a janela;

• critérios de interrupção do go-live.

Etapa 9. Preparar rollback e contingência

“Voltar a request” não deve ser o único plano. Dependendo da mudanca, será necessário definir:

• transporte de correção;

• restauração de versão;

• reversão de customizing;

• desativação de feature;

• retorno ao layout anterior, quando permitido;

• fila de documentos para reprocessamento;

• procedimento manual temporário;

• comunicação com fiscal, faturamento e operação.

O plano deve indicar responsáveis, prazo máximo de decisão e impacto tolerável.

Etapa 10. Preservar evidências para auditoria

Ao final, a empresa precisa conseguir responder:

• qual exigencia motivou a mudanca;

• quais objetos foram alterados;

• quem desenvolveu;

• quem testou;

• quem aprovou;

• quando foi transportado;

• qual foi o resultado;

• quais incidentes ocorreram;

• como a mudanca pode ser revertida.

Quando essas informações estão espalhadas em e-mails, planilhas e chamados desconectados, a auditoria transforma-se numa investigação.

Um plano de 30, 60 e 90 dias

Janela	Frentes de trabalho
Primeiros 30 dias	Definir governança conjunta entre fiscal e TI; mapear documentos, processos e responsáveis; registrar a linha de base do ambiente; levantar SAP Notes relevantes; identificar integrações e objetos Z críticos; classificar riscos.
31 a 60 dias	Implementar e validar notas em ambiente não produtivo; ajustar parametrizações; desenvolver correções ABAP; criar matriz de testes; separar requests e dependências; validar os primeiros cenários de NFS-e, CBS e IBS.
61 a 90 dias	Executar regressão; testar contingência; validar sequência de transportes; realizar ensaio de go-live; organizar evidências; monitorar rejeições, erros e impactos após a implantação.

O prazo real depende do ambiente. O valor do plano está em criar ondas controladas, não em prometer uma adequação genérica em 90 dias.

Onde a QAMetrik atua

A QAMetrik não substitui o motor de calculo tributário e não assume o papel da consultoria fiscal. Sua atuação está na camada técnica que leva a mudanca para produção:

• diagnóstico de prontidão do ambiente;

• levantamento de riscos e objetos impactados;

• implementação e governança de SAP Notes;

• engenharia e ajustes ABAP;

• adequação de integrações e documentos;

• configuração escalável de regras municipais;

• testes em homologação;

• governança de requests e transportes;

• rastreabilidade para auditoria.

O objetivo não é apenas “implementar a Reforma”. E implementar a Reforma sem transformar a adequação num novo incidente operacional.