Prontidão para a Reforma não se estima. Mede-se nota por nota, antes que o cronograma vire aposta.

A Reforma Tributária muda a base de cálculo, a apuração e a escrituração fiscal de quem roda SAP. Isso significa que toda nota SAP relacionada a IBS e CBS que ainda não foi aplicada no ambiente vira um ponto de risco na transição, e toda nota já aplicada precisa ser confirmada, não presumida.

Um assessment técnico de prontidão existe para responder uma pergunta simples e difícil de responder de memória: das notas SAP que tratam da Reforma, quantas já estão implementadas no ambiente, quantas faltam, e quantas simplesmente não servem para aquele cenário. Sem essa fotografia, decisão de cronograma de virada vira aposta.

O que foi medido

Em um cliente do agronegócio, no segmento de grãos, a DFSpro executou esse assessment em 07/08/2026, no ambiente de desenvolvimento (DS4), usando o SAP Note Analyzer.

Resultado bruto, medido naquela data:

• 61 notas SAP já implementadas no ambiente.
• 50 notas ainda a implementar.
• 4 notas classificadas como não implementáveis para aquele cenário.

O que cada bloco significa

61 notas já aplicadas dizem que o ambiente não está partindo do zero. Há trabalho de manutenção e atualização que já rodou antes da Reforma virar prioridade de projeto, e isso muda o tamanho real do esforço que falta.

50 notas a implementar são o volume principal de trabalho técnico a fazer antes da transição. O SAP Note Analyzer aponta a nota, não o desenho da solução, então esse número é ponto de partida de planejamento, não um cronograma pronto.

As 4 notas não implementáveis são o ponto mais informativo do assessment. Não implementável não quer dizer nota errada nem nota ignorável, quer dizer que, para aquele cenário específico de operação, a nota SAP genérica não se aplica sem adaptação, ou colide com uma customização já existente, ou pressupõe um pré requisito que o ambiente ainda não tem. É exatamente nesses pontos que mora o trabalho de julgamento técnico que uma leitura automática de notas não resolve sozinha, e onde entra desenho, não só aplicação.

O SAP Note Analyzer funciona lendo, no próprio ambiente, quais notas de uma coleção relacionada a um tema (no caso da Reforma Tributária, a coleção de notas ligadas a IBS e CBS) já foram aplicadas, quais estão pendentes e quais a ferramenta classifica como não aplicáveis àquele sistema específico, com base em versão de Support Package, componente instalado e pré-requisito técnico declarado em cada nota. A leitura é automática e objetiva quanto ao status técnico de aplicação, mas não avalia se o comportamento resultante, depois de aplicada, está de fato correto para o cenário fiscal daquela empresa: aplicar uma nota é condição necessária, não suficiente, para o cálculo estar certo.

Uma nota entra na categoria "não implementável" por motivos concretos e distintos entre si, não por um único critério: pode colidir com uma customização Z já existente que sobrescreve o mesmo ponto de extensão que a nota tentaria modificar; pode pressupor um objeto, tabela ou versão de componente que o ambiente ainda não tem instalado; ou pode simplesmente não se aplicar ao processo de negócio daquela empresa (uma nota que trata de um cenário de operação que a empresa não executa). As três situações exigem tratamento diferente: a primeira precisa de decisão de engenharia sobre qual lógica prevalece, a segunda precisa de um pré-requisito técnico resolvido antes, e a terceira só precisa de registro formal de que não se aplica, para não ficar como pendência eterna na lista.

Aplicar uma nota tecnicamente não encerra o trabalho. A maior parte das notas de adequação fiscal entrega código e, junto dele, uma atividade de customizing (ajuste de tabela de configuração, ativação de um novo campo ou domínio, parametrização de uma nova condição fiscal) que precisa ser executada e testada à parte. Um ambiente pode mostrar "nota implementada" no relatório técnico e ainda não ter a parametrização correspondente ativa, porque a aplicação da nota e a configuração do comportamento dela são dois passos distintos, frequentemente feitos por pessoas ou momentos diferentes do projeto.

O que o assessment não é

O assessment é um diagnóstico técnico do ambiente SAP frente às notas da Reforma. Não é decisão sobre qual tese tributária a empresa deve adotar, essa decisão é sempre do cliente. Não é prova de que a transição está concluída ou de que um problema foi resolvido. Não é um veredito de pronto ou não pronto, é uma fotografia de onde o ambiente está numa data específica.

A DFSpro desenha, configura e prova o comportamento do sistema. A tese fiscal, o que aplicar e como, é decisão do cliente.

Esse tipo de assessment deliberadamente não cobre tudo. Ele mede prontidão técnica de código e parametrização diante das notas SAP relacionadas à Reforma, não avalia a qualidade da tese tributária que a empresa vai adotar para cada cenário, nem substitui a análise jurídica sobre qual interpretação de IBS ou CBS se aplica a cada operação específica. As duas frentes são complementares e seguem responsáveis distintos: a técnica, que a DFSpro prova, e a tributária, que continua sendo do cliente e do time jurídico e fiscal interno dele.

O trabalho que vem depois do diagnóstico

O assessment abriu uma frente de projeto com 28 pontos de GAP mapeados. Medido em 29/08/2026: 3 concluídos, 10 em homologação, 7 em desenvolvimento e 8 ainda não iniciados. A maior parte do trabalho ainda está em andamento, e é assim que um diagnóstico técnico opera: ele transforma uma pergunta vaga, estamos prontos para a Reforma, em uma lista concreta e priorizável de pontos a resolver, com número, com data de medição e com método replicável.

Esse tipo de assessment também não é um evento único. A coleção de notas relacionadas à Reforma Tributária continua sendo publicada e atualizada ao longo do período de transição, à medida que a regulamentação avança e novos cenários são endereçados pela SAP e pelo Guepardo Tax. Um assessment executado numa data específica descreve o estado do ambiente naquele momento; tratá-lo como validade permanente, sem repetir a leitura em ciclos definidos até o fim da transição, reintroduz exatamente o mesmo risco que o assessment original existia para eliminar.

A mesma nota SAP pode se comportar de forma diferente conforme o ambiente já rodar ECC ou já tenha migrado para S/4HANA, porque o ponto de extensão que ela modifica pode não existir mais na mesma forma depois da mudança de arquitetura de dados. Isso significa que um assessment de prontidão fiscal feito antes de uma migração planejada tem validade limitada: o resultado (implementadas, pendentes, não aplicáveis) precisa ser reavaliado depois da migração técnica, porque o conjunto de notas relevantes e a forma de aplicá-las muda junto com a arquitetura, mesmo que a legislação em si não tenha mudado nesse intervalo.

Transformar o resultado do assessment em uma lista de pontos de GAP rastreável, com estágio de cada item (não iniciado, em desenvolvimento, em homologação, concluído), é o que separa um relatório estático de um instrumento de gestão de risco vivo. Sem esse rastreamento, o assessment vira uma fotografia que ninguém volta a olhar depois da apresentação inicial, e a organização perde a visibilidade exatamente sobre os itens mais difíceis, as notas não implementáveis que exigem desenho próprio, que são também os itens que mais tempo demoram e mais cedo precisam começar.

A multa por obrigação acessória agora tem tabela, e ela conta por período

Existe um motivo novo para medir prontidão com data, e ele foi escrito depois que a maioria dos cronogramas de Reforma foi montada. O art. 341-G da LC 214/2025, incluído pela LC 227/2026, fixa a tabela de multas por descumprimento de obrigação acessória do IBS e da CBS em UPF. O inciso IV pune entregar em atraso, deixar de entregar, ou manter em desacordo com a legislação os arquivos eletrônicos decorrentes da emissão de documentos fiscais ou de sua escrituração: 20 UPF por período de apuração, independentemente de intimação fiscal, e 30 UPF por período de apuração e a cada intimação fiscal.

A unidade importa mais que o valor. A penalidade não é por evento isolado, é por período de apuração: um ambiente que fica com escrituração em desacordo acumula a multa mês após mês, em silêncio, enquanto ninguém reabre o assessment. Uma nota pendente deixa de ser uma linha num relatório técnico e passa a ter periodicidade.

O inciso IX do mesmo artigo cria uma obrigação que cai direto no processo de entrada: o adquirente ou destinatário que deixar de confirmar a operação, de informar seu desconhecimento, o desfazimento do negócio, a devolução ou o retorno dos bens, relativamente a documento fiscal emitido por terceiro, responde por 1 UPF por documento. Isso não vive no módulo fiscal nem no relatório do SAP Note Analyzer: vive no recebimento, no bloqueio de nota, na conferência entre o pedido e o que chegou. Um assessment que só lê status técnico de nota aplicada não enxerga esse ponto, porque não há nota SAP que resolva uma manifestação que ninguém foi encarregado de fazer.

Por que isso importa para quem roda SAP

Quem tem uma migração ou uma atualização de ambiente SAP pela frente, com a Reforma em curso, vai precisar responder a mesma pergunta em algum momento: o que já está pronto, o que falta, e o que exige desenho próprio porque a nota genérica não serve como está. Ter esse assessment feito antes da virada, e não durante ela, é a diferença entre planejar o trabalho e descobrir o trabalho no meio do go-live.

A consequência de tratar esse assessment como checklist técnico de TI, em vez de insumo de decisão fiscal, aparece no momento em que o cronograma de virada é definido. Quem assina o prazo de adequação diante da diretoria ou do conselho normalmente é o Diretor Fiscal ou o Head de Tax, não quem rodou o SAP Note Analyzer. Se o número de notas pendentes e não implementáveis não for traduzido, com apoio técnico, em risco e esforço reais antes de o prazo ser comprometido publicamente, quem vai precisar explicar um atraso ou uma falha de cálculo na virada é quem assinou o cronograma, não quem gerou o relatório.

Antes de comprometer uma data de virada com a diretoria, o Diagnóstico Fiscal Estruturado coloca número no que falta, com data de medição. O trabalho se conecta com dois pontos vizinhos: a adequação sistêmica para IBS/CBS e a migração de ECC para S/4HANA. Para uma visão completa da Reforma, cronograma ano a ano e o que o S/4HANA entrega nativo, ver o guia "Reforma Tributária no SAP: o guia completo para quem opera fiscal dentro do sistema". Se a sua operação ainda não tem essa fotografia da Reforma, o Diagnóstico Fiscal Estruturado começa exatamente por aí.