NT 2025.002 v1.52: a devolução por item foi adiada, e o SAP pode continuar sem guardar o item de origem

A NT 2025.002 v1.52, publicada em 1º de outubro de 2026, adiou a validação que obriga a devolução a referenciar o documento de origem dentro de cada item. O adiamento não reduz o trabalho: só muda o dia em que ele vira rejeição. O próprio Portal Nacional da NF-e registrou, na lista de notas técnicas, que as datas poderiam ser alteradas porque a publicação tinha ocorrido naquele dia. Quem lê essa observação como folga está lendo o calendário. A pergunta que importa está no SAP: na hora de montar a nota, o sistema sabe de qual item da nota original cada linha está voltando?

Quem testou a NT como um bloco único vai descobrir em produção que cada regra tem a sua data.

Para quem loca equipamento pesado e o recebe de volta meses depois, a data adiada é o tempo que existe para configurar o SAP.

O que a v1.52 publicou, e o que ainda não foi lido

A NT 2025.002 trata da adequação dos leiautes da NF-e e da NFC-e para a Reforma Tributária do Consumo: campos novos e regras de validação que entram em produção por etapas, não de uma vez. A NT 2025.002 v1.52 posterga a entrada em produção da regra VC02-14 (referenciamento por item nas devoluções), exigindo que o vínculo com o documento fiscal original seja feito considerando o item devolvido, não só o documento como um todo. A nova data exata de produção ainda não foi conferida no texto da NT nesta revisão. Esse detalhe pesa, porque é a condição de aplicação que decide quem a regra alcança.

"Nota Técnica 2025.002 v1.52, RTC. 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, RTC. Obs.: as datas poderão ser alteradas em razão da publicação ter ocorrido hoje." Portal Nacional da NF-e (SVRS), lista de Notas Técnicas, 2026-10-01.

Uma empresa que homologou o leiaute RTC em setembro testou contra a versão vigente em setembro. O ambiente de homologação não manda aviso quando a data de produção de uma regra se desloca, e a observação do portal é genérica: diz que as datas podem mudar, sem dizer qual regra. Quem não compara versão com versão carrega um teste que parecia completo e que já não corresponde ao calendário em vigor.

Devolução ou retorno: a pergunta que vem antes do SAP

A regra VC02-14 da NT 2025.002 v1.52 fala de devolução. No leiaute da NF-e, devolução é uma finalidade de emissão, a finalidade 4, e não um nome genérico para qualquer bem que volta. A regra é específica de finNFe=4, o que significa que boa parte dos retornos de bem do ativo, emitidos com finalidade normal (CFOP 1.554/2.554 e correlatos), tende a ficar fora do alcance dela.

O retorno de bem do ativo remetido para uso fora do estabelecimento (CFOP 1.554/2.554), o retorno de bem cedido em comodato ou locação (1.909/2.909) e o retorno de conserto (1.916/2.916) costumam sair com finalidade normal e CFOP de retorno, não como devolução. Em alguns desses fluxos, nem é a própria empresa que emite a nota. No conserto, o retorno vem do terceiro que consertou. Na locação a cliente contribuinte do ICMS, quem emite o retorno tende a ser o cliente. Quando o cliente não é contribuinte, a nota de entrada do retorno tende a ser emitida pela própria locadora, e aí é o SAP dela que monta o documento.

Então a primeira tensão é anterior a qualquer configuração: o seu retorno sai como devolução ou como retorno? Se sai como devolução por hábito de parametrização, a regra alcança o fluxo de ativo inteiro. Se sai como retorno com finalidade normal, esse fluxo tende a ficar fora da VC02-14, e o risco se concentra na devolução comercial de peças e acessórios vendidos, que tem finalidade 4 e é emitida por outra rotina do SAP, longe de quem cuida do imobilizado.

A escolha de finalidade e de CFOP é decisão da área fiscal. O sistema só executa o que foi decidido.

Locação de equipamento de içamento: onde a cadeia estica

Quem loca ou opera equipamento pesado de movimentação e içamento conhece a cadeia. O guindaste ou o conjunto de içamento sai da base para o canteiro do cliente com nota de remessa por contrato de locação ou comodato (5.908/6.908), ou como bem do ativo para uso fora do estabelecimento (5.554/6.554). Fica meses em campo. Às vezes só volta para a base depois de passar por outra obra, em outra UF, com retorno e nova remessa no meio do caminho.

Uma remessa assim costuma carregar vários itens: o equipamento principal, contrapesos, acessórios, às vezes peças que serão consumidas na obra. O retorno raramente traz de volta exatamente o que saiu. Alguns itens voltam, outros ficam, um acessório volta em outra nota. É nesse ponto que a referência por item deixa de ser detalhe de leiaute, nos casos em que esse retorno sai de fato com finalidade de devolução.

Não é mais "esta nota devolve aquela nota". Passa a ser "este item desta nota devolve aquele item daquela nota".

Com registro em várias UFs, cada base tem o seu CNPJ, a sua série e o seu emitente. O retorno precisa apontar a remessa do estabelecimento que remeteu. Se o equipamento descarrega numa base diferente daquela de onde saiu, a área fiscal tem de decidir como tratar essa operação, e a referência de item passa a cruzar estabelecimentos.

E a remessa emitida antes da regra entrar, cujo retorno acontece depois dela, cai exatamente na fresta. A nota de origem foi gerada sem qualquer preparo para referência por item; a nota de retorno, se emitida como devolução, já será validada pela regra nova. A remessa antiga não precisa ser refeita, mas o vínculo de item precisa existir no momento do retorno.

Onde o SAP guarda a referência hoje

No leiaute atual da NF-e, a referência a outro documento fica no grupo NFref, dentro da identificação da nota, no cabeçalho. Quem já abriu o XML de uma devolução gerada pelo SAP reconhece o desenho: uma ou mais chaves de acesso no topo do arquivo, e itens que não dizem de qual linha da nota original vieram.

O problema aparece quando a validação passa a exigir referência por item e o SAP, na configuração atual, não leva o item de origem até o XML.

Na localização Brasil do SAP ECC e do S/4HANA, a tabela de itens da nota fiscal (J_1BNFLIN) tem campos de documento de referência e de item de referência, DOCREF e ITMREF (conferir no ambiente, porque o preenchimento depende do fluxo). Numa devolução de venda criada no SD com controle de cópia a partir da fatura original, esses campos podem chegar preenchidos. Numa nota de ativo emitida pelo Writer (J1B1N), sem documento logístico de origem, quem preenche é a pessoa que digita, e só se o campo estiver aberto na tela.

Quando o ITMREF chega vazio na J_1BNFLIN, o sintoma típico aparece no ambiente de qualidade como rejeição de schema ou de regra de preenchimento no envio da NF-e, com o SAP devolvendo o documento fiscal em status de erro antes mesmo de tentar a transmissão à SEFAZ. Na prática, é o analista de rotina fiscal (quem monitora a fila de documentos pendentes de autorização) que percebe primeiro, porque é ele quem vê a nota parada na fila sem motivo aparente até abrir o log e achar o campo em branco.

Nota SAP ou cópia: dois consertos, dois donos

Quando a referência por item não aparece no XML, há duas causas possíveis, e convém não misturar. Pode ser Nota SAP de localização ainda não aplicada: o leiaute novo da NT 2025.002 não chega ao XML, por mais que o campo esteja preenchido na tabela. Ou pode ser cópia que não leva o item de origem para a nota: o leiaute está pronto, mas DOCREF e ITMREF ficam vazios porque nenhuma rotina os preenche.

O critério para distinguir as duas causas está no próprio log de erro. Se o ITMREF está preenchido na J_1BNFLIN e mesmo assim o XML sai sem o item de origem, o log aponta rejeição de schema ou de versão de leiaute: é Nota SAP não aplicada. Se o log aponta campo obrigatório ausente antes mesmo de montar o XML, com o ITMREF vazio na própria tabela, é cópia que não preenche: a Nota SAP passa por quem administra o sistema, com teste de regressão do envio de NF-e em ambiente de qualidade, comparando o XML de uma devolução de venda e de uma nota de ativo antes e depois da aplicação. A cópia passa por quem configura SD e Writer, com teste por fluxo de retorno.

Corrigir o XML à mão resolve a nota. Aplicar a Nota SAP e levar o item de origem na cópia resolve o fluxo. Enquanto só a primeira coisa acontece, cada retorno rejeitado volta para a mesa da área fiscal, e o crédito ou o ajuste de apuração ligado à devolução fica pendurado até a nota ser autorizada pela SEFAZ.

No caso do ativo, há um custo menos visível: o equipamento que voltou fisicamente à base e não voltou no documento. No inventário do imobilizado, ele continua em poder de terceiro.

Quem lê a próxima versão, e contra qual lista

Acompanhar NT por data de produção falha por uma razão prática: o portal publica versões novas com aviso genérico, sem dizer qual regra vai mudar. Quem só anota a data no calendário fiscal descobre a mudança no dia da primeira rejeição.

O critério útil tem dono e artefato. Dono: alguém do AMS Fiscal ou da TI fiscal com responsabilidade escrita de ler cada versão no dia em que sai. Artefato: o histórico de alterações da NT, comparado com uma lista curta das regras que tocam devolução, finalidade e referenciamento, cruzada com os fluxos de emissão em uso: venda, devolução, remessa e retorno de ativo, locação e comodato.

Quem acompanha só a data de produção corre o risco de estar pronto para uma regra que já foi adiada, e despreparado para a que muda na versão seguinte.

Essa leitura precisa terminar numa linha escrita: esta versão afeta ou não afeta tal fluxo, com o nome de quem leu e a data da leitura. Sem esse registro, o adiamento de outubro vira esquecimento quando a próxima versão sair.

O padrão que costuma se repetir na devolução de ativos locados é esse: a referência existe no cabeçalho, mas se perde no item assim que o retorno mistura equipamento, contrapeso e acessório numa única remessa.

A verificação que cabe numa tarde

Abra a última devolução emitida e procure onde está a chave da nota original. Se estiver só no NFref do cabeçalho, a pergunta seguinte é para quem configurou a cópia: o ITMREF desse documento está preenchido na J_1BNFLIN? Se estiver, o que falta é leiaute, e a pergunta vai para quem aplica Notas SAP. Se estiver vazio, falta cópia, e a pergunta vai para quem configura o SD ou o Writer.

Depois, faça o mesmo com o último retorno de equipamento locado. Antes de olhar a referência, olhe a finalidade da nota. Se ela sai como devolução, o fluxo de ativo entra no alcance da regra. Se sai como retorno com finalidade normal, confira quem a emitiu, porque talvez ela nem passe pelo seu SAP, e tende a ficar fora da VC02-14.

Feche com a lista das remessas de locação ainda abertas, emitidas antes da v1.52. Cada uma é um retorno futuro, que vai ser emitido sob a regra vigente no dia do retorno, não sob a regra do dia em que o equipamento saiu.

A pergunta que fica para o Gerente Fiscal

A pergunta prática é estreita: o SAP monta a nota de devolução referenciando o item da nota de origem, ou só o documento inteiro? E, antes dela, qual dos seus retornos sai como devolução?

No dia em que a regra entrar em produção sem essas respostas, o que trava é a nota de um equipamento específico, parado até alguém abrir a J1B1N, localizar o item de origem na remessa e corrigir a referência à mão, nota a nota.

O adiamento deu tempo. Ele não diz se esse tempo está sendo usado na configuração ou só no calendário.

O Diagnóstico Fiscal Estruturado olha essa rotina: onde o item de origem se perde entre a remessa e a devolução, e quais Notas SAP faltam. A escolha de CFOP e de finalidade fica com a área fiscal; a DFSpro desenha, configura e prova a emissão no SAP.