Duas notas técnicas em dois meses: quem é o dono de liberar o leiaute da NF-e no seu SAP

Em 1º de outubro, o Portal Nacional da NF-e publicou a versão 1.52 da Nota Técnica 2025.002, referente à Reforma Tributária do Consumo. A versão anterior, 1.51, havia saído dois meses antes, em 1º de agosto. Duas versões do mesmo leiaute em dois meses não é projeto que se conclui: é rotina que precisa de dono, calendário e prova de liberação.

Quem trata isso como projeto único já está atrasado.

A linha do tempo das versões, e o que ela revela

O leiaute da NF-e ligado à Reforma Tributária do Consumo não nasceu pronto numa única publicação. Ele vem evoluindo em versões sucessivas, cada uma ajustando campos e regras de validação à medida que a regulamentação infralegal avança. A v1.51, publicada em agosto, e a v1.52, publicada em outubro, são dois pontos recentes dessa linha, mas não os primeiros nem, previsivelmente, os últimos.

O portal registra também, em publicação próxima mas de uma nota técnica distinta (identificada neste levantamento como NT 2021.003 v.1.50, portanto fora da série 2025.002), alterações no leiaute de impressão do Documento Auxiliar da Nota Fiscal Eletrônica necessárias à representação dos tributos instituídos pela Reforma. Isso mostra que a mudança não afeta só o XML transmitido pela nota técnica principal: afeta também o documento impresso que circula fisicamente com a mercadoria, por meio de uma nota técnica separada. Uma empresa que acompanha só a série 2025.002 e ignora a 2021.003 entrega metade do trabalho.

O ritmo de duas versões em dois meses não é acidente: ele reflete um mecanismo legal de atualização contínua, não um calendário fechado de projeto. O Decreto 12.955/2026, que regulamenta a CBS, remete as datas de obrigatoriedade de emissão do documento fiscal eletrônico a ato conjunto da Receita Federal e do Comitê Gestor do IBS, ato que continua sendo editado ao longo do período de transição. Enquanto esses atos conjuntos seguirem saindo, o leiaute que os reflete também vai continuar mudando.

Vale notar que o portal frequentemente publica mais de uma nota técnica no mesmo dia, cada uma com sua própria numeração e versão, o que exige triagem cuidadosa: nem toda publicação do mesmo dia trata do mesmo assunto, e tratar a leva inteira como um bloco único de mudança, como ocorreu com a 2025.002 e a 2021.003 na mesma janela de outubro, aumenta o risco de perder algum ajuste relevante dentro do volume.

Um detalhe que costuma passar despercebido é que uma versão nova nem sempre substitui a anterior de forma limpa: em alguns casos, campos introduzidos numa versão são ajustados ou redefinidos na versão seguinte, o que significa que uma empresa que atualizou para a v1.51 e ainda não tratou a v1.52 pode estar operando com um campo que já mudou de comportamento, mesmo achando que está em dia com a versão mais recente que conhece.

O que uma versão exige do SAP e da solução fiscal

Cada versão da nota técnica normalmente traz três tipos de mudança: campo novo no schema XML, regra de validação alterada (o que pode mudar se um documento antes aceito passa a ser rejeitado), e ajuste no leiaute de representação, como o DANFE. No SAP, isso se traduz em atualização de schema de saída, ajuste de regra de preenchimento de campo, e, quando há solução fiscal acoplada de terceiro, como o Guepardo Tax da NTT, atualização paralela dessa camada para manter a compatibilidade entre os dois sistemas.

Uma versão de leiaute não se resolve com um único ajuste.

Ela percorre, tipicamente, quatro etapas: leitura da nota técnica e identificação do que muda para o seu ambiente, ajuste de parametrização em ambiente de desenvolvimento, homologação contra o schema oficial e contra cenários de teste representativos do seu volume real de emissão, e, só então, transporte para produção antes da data em que a versão passa a ser exigida. Pular etapas, ou comprimi-las para ganhar tempo, é o que costuma gerar rejeição em produção depois que a janela de homologação do ambiente oficial já fechou.

Para quem emite NF-e e NFC-e em volume relevante, com solução fiscal acoplada ao SAP, a homologação de uma versão nova não é tarefa de uma pessoa num dia. Envolve testar cenários de diferentes tipos de operação, conferir se o campo novo é preenchido corretamente em cada um, e validar que a regra alterada não rejeita documentos que antes passavam. Quanto maior a diversidade de operações da empresa, maior a superfície de teste necessária a cada nova versão.

Há ainda uma camada frequentemente esquecida nesse processo: o cadastro de material ou produto. Um campo novo exigido pela nota técnica costuma depender de informação já presente no cadastro (classificação fiscal, atributo específico de tributação), e se esse dado não estiver preenchido corretamente para todos os materiais afetados, o sistema pode calcular corretamente para parte do catálogo e falhar silenciosamente para o restante, sem gerar erro explícito no momento da emissão.

Onde a atualização trava: os quatro pontos de falha mais comuns

O primeiro ponto de falha é a leitura tardia. Se ninguém monitora o portal de forma sistemática, a nota técnica só é percebida quando alguém, por acaso, vê a publicação ou quando o fornecedor da solução fiscal avisa, o que pode acontecer dias ou semanas depois da publicação oficial.

O segundo ponto é a homologação incompleta. Testar só os cenários mais comuns de emissão, sem cobrir operações menos frequentes mas ainda relevantes (exportação, devolução, transferência entre filiais), deixa brechas que só aparecem quando esse tipo específico de operação ocorre em produção, depois da virada de versão.

O terceiro ponto é o transporte atrasado. Mesmo com homologação concluída a tempo, se o transporte da mudança para produção depende de uma janela de mudança que só abre semanalmente ou mensalmente, a empresa pode ficar tecnicamente pronta mas operacionalmente desatualizada até a próxima janela disponível.

O quarto ponto, menos falado, é a divergência entre SAP e solução fiscal de terceiro. Quando as duas camadas são atualizadas por equipes ou fornecedores diferentes, sem sincronização de calendário, é possível que o SAP já reflita a versão nova enquanto a solução fiscal ainda opera com a regra antiga, ou vice-versa, gerando inconsistência entre o que um sistema calcula e o que o outro valida.

Esses quatro pontos raramente aparecem isolados: na maioria dos casos que resultam em rejeição em escala, é a combinação de dois ou três deles, não um único fator, que transforma uma atualização de rotina em incidente de produção. Uma leitura tardia reduz o tempo disponível para homologação, o que aumenta a tentação de testar menos cenários, o que por sua vez aumenta a chance de a transferência entre filiais, pouco testada, ser justamente o cenário que falha na primeira semana da versão nova em produção.

Nota técnica de adequação dos leiautes da NF-e e da NFC-e para inclusão dos campos e das regras de validação referentes à Reforma Tributária do Consumo.

O modelo de dono, calendário e prova de liberação

A pergunta executiva que fecha essa questão é direta: quem, no time interno ou no contrato de sustentação, é o dono de acompanhar o portal da NF-e e liberar cada nota técnica antes da data em que ela passa a ser exigida em produção? Se a resposta demora, ou aponta para "a equipe de TI, de forma geral", o processo não tem dono real, tem um grupo que eventualmente resolve.

Um modelo de governança de versão funcional define, por escrito, quem monitora o portal, com que frequência, e quem decide se uma nota técnica publicada exige ação no seu ambiente específico. Essa decisão de triagem, separada da execução técnica, é o que evita que notas técnicas irrelevantes para o seu fluxo consumam tempo de homologação desnecessário, e que notas técnicas relevantes, inclusive de séries diferentes como a 2021.003 e a 2025.002, passem despercebidas.

O calendário de uma versão nova precisa ter, no mínimo, quatro datas documentadas: data de publicação da nota técnica, data planejada de conclusão da homologação, data planejada de transporte para produção, e data de produção obrigatória informada pelo próprio portal. Comparar essas quatro datas, para cada versão recente, revela se o processo está rodando dentro da margem de segurança ou correndo contra o prazo.

A prova de liberação, por sua vez, é o registro que permite responder, meses depois, exatamente quando e por quem cada versão foi homologada e transportada. Sem esse registro, a resposta à pergunta "quando atualizamos para a v1.51" vira reconstituição de memória, não consulta a um dado confiável.

Um contrato de sustentação que inclua esse tema deveria prever, de forma explícita, o prazo máximo entre publicação e triagem, o prazo entre triagem positiva e homologação concluída, e o formato do registro que comprova cada uma dessas etapas. Contrato que trata isso como "manutenção evolutiva conforme legislação", sem esses três prazos escritos, deixa a cadência inteira a critério informal de quem está disponível no momento da publicação.

O que levar ao comitê, e o checklist de governança de versão

Para um CIO ou Head de SAP que precisa reportar esse tema a um comitê executivo, o ponto central não é a nota técnica em si, é a maturidade do processo que trata notas técnicas como elas continuarão chegando: em sequência, com prazo curto, e com volume crescente enquanto a Reforma Tributária do Consumo segue em transição.

Um checklist mínimo de governança de versão cobre seis pontos: existe responsável nomeado para monitorar o portal da NF-e; existe prazo definido entre publicação e triagem; existe ambiente de homologação com cenários de teste representativos do volume real de emissão; existe sincronização de calendário entre SAP e solução fiscal de terceiro, quando houver; existe registro documentado de cada liberação, com data e responsável; e existe alguém com autoridade para escalar o tema ao comitê quando uma versão tiver prazo apertado demais para a capacidade atual da equipe.

Dois meses entre versões é o ritmo observado agora.

Não há garantia de que esse ritmo vá desacelerar antes que a transição para IBS e CBS se complete. Tratar cada nota técnica como surpresa, em vez de evento previsível dentro de um processo já desenhado, é o que transforma rotina de sustentação em sequência de emergências.

Um exercício simples revela a maturidade real do processo: peça para alguém reconstituir, sem acesso a e-mails antigos ou mensagens de chat, a data exata em que cada uma das duas últimas versões foi homologada e transportada. Se a resposta vier de um documento consultável, a governança existe. Se depender de perguntar a quem participou, o processo vive na memória de pessoas específicas, o que é exatamente o risco que esse checklist existe para eliminar.

Vale ainda medir a folga real entre a data de produção obrigatória informada pelo portal e a data em que a homologação de fato foi concluída nas últimas versões. Uma folga positiva e estável indica processo sob controle; uma folga que vem encolhendo a cada versão é sinal de que a capacidade da equipe está ficando para trás do ritmo de publicação, e isso é exatamente o tipo de indicador que um comitê executivo precisa ver antes que vire incidente.

Onde isso converge para uma decisão concreta

A parametrização do leiaute de NF-e e NFC-e no SAP, e, quando há, na solução fiscal de terceiro acoplada, passa por homologação e transporte a cada nova versão, de qualquer série de nota técnica aplicável ao ambiente. Essa sustentação contínua é o trabalho de AMS Fiscal: monitorar notas técnicas, montar o plano de homologação, e produzir a evidência de liberação que o comitê e a auditoria podem consultar depois.

O Diagnóstico Fiscal Estruturado da DFSpro mapeia, especificamente, se existe hoje um dono nomeado para esse processo, se o calendário de versões recentes foi cumprido dentro da margem de segurança, e se a evidência de liberação está disponível para consulta, não reconstruída sob pressão a cada auditoria.