SAP e Reforma Tributária: prioridades do programa

Uma nota autorizada pode acender o indicador verde e, ainda assim, deixar aberta a pergunta que interessa à diretoria: o tratamento tributário está correto? Na combinação entre SAP e Reforma Tributária, o ponto de partida é separar transmissão de conteúdo. A Resolução CGIBS nº 6/2026, art. 132, I, registra que a autorização “não implica validação das informações”. Por isso, o programa precisa coordenar norma, ambiente SAP e governança interna — e exigir evidência própria para cada decisão.

Uma nota autorizada encerra a conferência?

O recado regulatório é mais preciso do que a fórmula “autorizou, está certo”. No alcance da Resolução CGIBS nº 6/2026, o art. 132, I, afirma que a autorização “não implica validação das informações”; o art. 147, por sua vez, atribui ao emitente responsabilidade pela “veracidade e exatidão” do que foi informado. Isso não apaga as validações técnicas do autorizador, nem transfere automaticamente todos os fatos ao implementador. Mostra apenas que o protocolo, sozinho, não fecha a análise material.

Imagine uma venda sem qualquer número inventado: o documento passa, o protocolo volta e a fila fica vazia. Ainda restam perguntas independentes. O item recebeu a classificação decidida por Tax? A vigência usada era a correta? O cálculo no ERP chegou ao XML sem alteração indevida? A contabilização reproduziu o resultado esperado? O conjunto de evidências precisa responder a essas perguntas, não apenas provar que um arquivo foi aceito.

Essa distinção muda o desenho do projeto. O teste documental observa emissão e retorno; o teste tributário compara premissa, dados, determinação, documento e lançamento. Antes de contratar uma entrega genérica, vale delimitar o escopo, os responsáveis e os critérios de aceite da validação tributária no ERP. Sem essa fronteira, duas equipes podem acreditar que a outra conferiu o mesmo ponto.

Os três relógios que precisam caber no mesmo programa

O primeiro relógio é normativo. A EC 132/2023 introduziu no ADCT marcos que precisam ser lidos pelo objeto de cada dispositivo: o art. 125 começa com “Em 2026” e trata da etapa constitucional de teste; o art. 126 estabelece a fase de CBS e IS “a partir de 2027”; e o art. 129 situa “a partir de 2033” o estado final relativo a ICMS e ISS. Os três trechos podem ser conferidos no texto oficial da EC 132/2023. Eles não criam, por si, uma data universal de corte de sistema.

O segundo relógio é o ciclo dos produtos efetivamente presentes no landscape. A página de estratégia de manutenção da SAP documenta, para o escopo elegível do core Business Suite 7 e dos Enhancement Packages ali especificados, “mainstream maintenance … until end of 2027”. O mesmo documento registra: “This offboarding phase will be followed by optional extended maintenance until end of 2030”. A extensão é opcional, vem depois da fase indicada e não funciona como direito geral para qualquer ECC — muito menos como prazo tributário.

Dentro desse relógio tecnológico há ainda produtos com horizonte próprio. O Administration Guide de NFE 10.0 SP35 afirma “Brazil Tax Reform will not be supported in GRC NFE”. Essa frase delimita o produto documental descrito; ela não diz que o SAP ERP ou o ECC inteiro carece de suporte à reforma. Na página oficial da versão 10.0.35, a SAP também registra “SAP NFE 10.0 will be out of maintenance by the end of the year 2025”. Esse 2025 pertence à manutenção do SAP NFE 10.0, não ao core e não ao cronograma constitucional.

O terceiro relógio é o único que a empresa controla diretamente: decisões, responsáveis, disponibilidade de ambientes, dados, integrações, testes e critérios de aceite. Ele não ganha uma data fictícia para parecer completo. Primeiro se conhece o landscape e a operação; depois se calcula a sequência possível. Chamo essa separação de “três relógios” como método editorial de governança da TaxUp, não como modelo prescrito pela Constituição ou pela SAP.

Onde a mudança percorre a operação

A pergunta “qual sistema será alterado?” chega cedo demais quando o percurso da operação ainda está escondido. Uma decisão comercial pode depender de cadastro de produto, parceiro, estabelecimento, condição contratual, origem e destino. Esses dados alimentam classificações; as classificações acionam regras; o resultado percorre documento, integração, lançamento e reporte. O sistema em que o erro aparece nem sempre é o sistema em que ele nasceu.

Há um exemplo documentado e delimitado pela própria SAP. Em Inclusion of Taxes in TAXBRA Pricing Procedure, para as versões EHP4 SP24 a EHP8 SP24 e a Note 3569061 indicadas, o Help descreve “automatic calculation and mapping … CBS and IBS”. O trecho sustenta uma entrega de compras no escopo documentado. Não comprova cobertura de todas as operações, todos os regimes ou todo ambiente que use TAXBRA.

Daí surgem dois inventários que precisam conversar. O primeiro acompanha dados mestres, classificações, vigências, donos e seus efeitos tributários. O segundo define as fronteiras entre ERP, localização, motor fiscal e camada documental. Quando um deles falta, o projeto costuma transformar uma lacuna de premissa em chamado técnico, ou uma falha de interface em discussão jurídica interminável.

O mapa acima é uma orientação, não uma lista de configuração. Para cada família de operação, a equipe deve localizar onde nasce a premissa, onde a regra é aplicada, qual interface transporta o resultado, qual artefato registra o teste e quem decide uma exceção. Só então a arquitetura deixa de ser um desenho de caixas e passa a apoiar o aceite.

O que precisa estar na mesa antes de escolher a solução

Uma célula “desconhecido” nesta tabela não é resposta negativa; é uma lacuna de descoberta. Esse cuidado parece pequeno, mas evita conclusões perigosas. Não localizar uma customização no primeiro inventário não prova que ela inexiste. Não receber um contrato na primeira reunião não prova ausência de suporte. O programa deve registrar o que foi confirmado, por qual evidência, em que data e o que ainda depende de dono.

A solução só pode ser comparada depois desse retrato. Em algumas operações, uma entrega standard pode cobrir parte relevante do fluxo. Em outras, dados, integrações próprias ou condições contratuais mudam a sequência. A escolha entre adaptar, migrar, conectar ou redesenhar não nasce do nome do produto: nasce da diferença entre o estado atual comprovado e o resultado tributário esperado.

Eu usaria quatro perguntas para impedir uma decisão prematura: qual é o objeto tributário; onde ele é determinado; por quais interfaces ele passa; e qual evidência provará que chegou íntegro ao fim. Se uma alternativa não responde às quatro, ela ainda é uma hipótese técnica, não uma decisão pronta para orçamento.

Como organizar as ondas sem perder as dependências

Organizar em ondas não significa escolher uma receita única. A empresa pode precisar estabilizar uma baseline antes de ampliar o escopo, preparar uma camada documental enquanto o core segue em outra frente, ou priorizar famílias de operação cujo efeito seja mais material. A ordem depende do inventário, das datas aplicáveis, das integrações e da capacidade real de testar.

Na frente de plataforma, a decisão aprofundada é comparar adaptar o ECC, antecipar o S/4HANA ou separar os dois movimentos sem tratar 2027 como desligamento automático. Na frente documental, o ponto é distinguir o papel do GRC NFe, do SAP DRC e do core ERP, inclusive na preparação do corte e das filas. São decisões conectadas, mas não idênticas.

A frente tributária e de dados alimenta as duas anteriores. Ela entrega a matriz de operações, premissas aprovadas, vigências e resultados esperados. O programa transforma isso em critérios observáveis: campo, cálculo, XML, contabilização, retorno e reconciliação. Se uma onda técnica chega antes dessas decisões, ela pode até produzir um arquivo — mas não consegue demonstrar que o arquivo representa a regra aprovada.

Minha recomendação é estabelecer uma porta de entrada e uma de saída para cada onda. Na entrada: dependências conhecidas, responsável nomeado e decisão tributária disponível. Na saída: evidência reproduzível, diferenças classificadas e decisão formal sobre o que foi aceito, corrigido ou adiado. A duração e a equipe necessárias vêm do alcance real; não de um prazo universal.

O que a diretoria deve receber para decidir

A diretoria não precisa receber a lista inteira de tickets. Precisa enxergar as poucas decisões que mudam risco, sequência ou investimento. Para cada ponto, a pauta deve mostrar o fato conhecido, a lacuna, o efeito possível, o responsável por fechá-la, a evidência esperada e a decisão que ficará disponível quando essa evidência chegar.

As três linhas acima são hipóteses de método, não diagnóstico de uma empresa. Elas também não atribuem automaticamente severidade ou prazo. Uma baseline não confirmada pode ser decisiva em um landscape e secundária em outro; uma divergência contábil pode nascer de timing legítimo ou de erro. O valor da tabela está em tornar a incerteza decidível, sem fingir precisão antes da investigação.

Um pacote executivo útil separa quatro estados: confirmado, em validação, bloqueado por dependência e aceito com condição. Cada rótulo precisa apontar para evidência e responsável. Assim, o conselho deixa de votar em cores de semáforo e passa a decidir sobre fatos, lacunas e consequências explícitas.

Perguntas antes de aprovar o programa

Antes de levar a proposta à aprovação, percorra cinco frentes. Algumas já foram apresentadas acima; aqui elas funcionam como portas de decisão, sem repetir as âncoras de aprofundamento.

• Plataforma: a baseline está comprovada e a relação entre adaptação do ambiente atual e migração futura foi separada?
• Documentos: produtos, processos, filas, certificados, ambientes e ponto de corte têm responsáveis definidos?
• Notes: existe controle de aplicabilidade, dependências e resultados esperados? Consulte o guia de governança das SAP Notes ligadas à Reforma Tributária.
• Contratação: entregáveis, exclusões, premissas, aceite e tratamento de mudança estão escritos no mesmo vocabulário?
• Produção: reconciliações, limiares, donos e escalonamento estão prontos para o período de hypercare tributário no SAP?

Fontes e método. As afirmações normativas e de produto desta página estão limitadas aos dispositivos e documentos oficiais identificados no texto, conforme o corpus de pesquisa TaxUp que registra reabertura das fontes em 14/09/2026. O modelo dos três relógios, os fluxos e as pautas de decisão são análise editorial da TaxUp e devem ser atualizados quando mudar a norma, o ciclo do produto ou a versão da documentação.