Sistemas emissores que continuam informando a chave da nota original apenas no grupo NFref estão encontrando um bloqueio concreto na autorização da NF-e de devolução. A SEFAZ já está aplicando em produção a validação que exige a referência dentro do produto de cada item devolvido. Quando o grupo prod/DFeReferenciado não é gerado no det, a nota pode ser recusada pela rejeição 321, identificando o item sem o vínculo exigido.

Não se trata apenas de informar a chave em outro lugar. Para cada produto da devolução, o ERP precisa transmitir a chave do documento de origem e o número que o produto ocupava naquela nota. Isso vale para devoluções parciais e também para a devolução integral: se a nota original possui cem itens e todos estão sendo devolvidos, os cem itens da nova NF-e precisam carregar a própria referência.

Para compreender o contexto mais amplo dessas adaptações, vale consultar o guia do ACBrNFe para a NT 2025.002 e o cronograma de obrigatoriedade dos documentos fiscais na Reforma Tributária. Este artigo se concentra em uma mudança operacional específica: a ligação entre cada item devolvido e o item correspondente do documento original.

Neste artigo, vamos entender por que a devolução está sendo bloqueada, quais dados devem acompanhar cada item, como tratar a devolução integral e como preencher o grupo DFeReferenciado usando o ACBrNFe em Delphi.

Por que a NF-e de devolução está sendo rejeitada

Historicamente, muitos emissores identificam a nota de origem no grupo NFref, dentro de ide, usando a tag refNFe. Esse modelo informa que a nova NF-e tem relação com outro documento, mas não estabelece qual item devolvido corresponde a qual item do documento original. Quando uma nota contém diversos produtos, devoluções parciais ou itens provenientes de documentos diferentes, essa referência geral não oferece uma correlação precisa.

A Nota Técnica 2025.002-RTC acrescentou ao grupo prod do item da NF-e o grupo DFeReferenciado. Dentro dele, chaveAcesso identifica o documento fiscal eletrônico de origem e nItem identifica o número do item naquele documento. A relação deixa de ser apenas “esta nota referencia aquela nota” e passa a dizer “este item devolvido corresponde àquele item do documento de origem”.

No leiaute oficial, DFeReferenciado possui ocorrência 0-1 dentro de cada prod: não é uma lista de várias referências dentro do mesmo produto. A repetição ocorre no conjunto de itens da NF-e. Cada elemento det contém um prod, e cada prod pode conter seu próprio DFeReferenciado. Assim, uma devolução com cem itens terá cem grupos det e, normalmente, um DFeReferenciado dentro do produto de cada item.

Na regra em produção, a VC02-14 determina que, para uma NF-e de devolução de mercadoria, identificada por finNFe = 4, o documento referenciado seja informado no grupo DFeReferenciado do item. A observação da regra proíbe usar refNFe como forma de referenciamento da nota na devolução. A ausência da referência por item gera a rejeição 321, com a indicação do item envolvido.

Há uma validação complementar para o número do item original. Na versão que entrou em produção em 1º de setembro de 2026, a regra VC02-15 determina que, quando a chave é informada em DFeReferenciado/chaveAcesso, também seja preenchido DFeReferenciado/nItem. A ausência desse número gera a rejeição 1102: “NF-e de devolução de mercadoria com referenciamento a nível de item exige referenciamento do item da NF-e original”. O nItem não é a posição do produto na nota de devolução: ele corresponde ao atributo nItem do elemento det no XML original. Confundir os dois números pode criar um XML estruturalmente válido, porém semanticamente incorreto e recusado pela SEFAZ.

A versão 1.51 substitui a VC02-15 pela regra mais abrangente VC03-20, associada à rejeição 1048. Essa evolução explica por que materiais baseados em versões diferentes apresentam dois códigos para a ausência de nItem. Para diagnosticar uma emissão, considere o código efetivamente devolvido pelo autorizador; no cenário já observado em produção sob a regra da devolução, o retorno é a rejeição 1102.

O ponto decisivo é que a validação deixou de ser uma preocupação de cronograma e passou a afetar emissões reais. A rejeição 321 informa que a NF-e de devolução não possui documento fiscal referenciado por item. Corrigir apenas o cadastro, o CFOP ou a finalidade da nota não resolve: o XML precisa conter prod/DFeReferenciado dentro de cada det alcançado pela devolução.

Há uma segunda falha possível depois da primeira correção. Se o sistema enviar DFeReferenciado/chaveAcesso, mas omitir DFeReferenciado/nItem, a rejeição 1102 informa que falta o item da NF-e original. Portanto, a implementação deve tratar chave e número do item como um único vínculo, e não como campos independentes e opcionais.

O que o ERP precisa conhecer antes de emitir a devolução

Para montar corretamente o novo grupo, não basta conservar a chave de acesso da nota original. O sistema também precisa preservar a relação entre cada item recebido ou vendido e o respectivo número no documento fiscal de origem. Esse vínculo costuma se perder quando a devolução é iniciada a partir de um pedido, de um movimento de estoque ou de uma tela que copia somente código, quantidade e valor.

Uma implementação segura deve recuperar, para cada item devolvido:

• a chave de acesso de 44 posições do DF-e de origem;
• o número do item no XML original, e não o número da linha exibida na tela;
• a finalidade da nova NF-e, que deve refletir corretamente a operação realizada;
• o CFOP e os demais dados fiscais definidos com a área contábil;
• a quantidade efetivamente devolvida e o vínculo com o movimento original.

Se uma devolução reunir produtos de mais de uma nota, cada item precisa apontar para sua própria origem. Se vários itens vierem da mesma nota, eles podem repetir a chave, mas cada um deve indicar o seu nItem original. O sistema também deve impedir que a referência seja preenchida com uma chave digitada sem validação, pois um erro de um dígito muda o documento relacionado.

Vale separar duas responsabilidades. A escolha de finalidade, CFOP, tributação e natureza da operação pertence à análise fiscal e contábil. Já a preservação do vínculo, a geração das tags e a validação estrutural são responsabilidades do software. O desenvolvedor não deve tentar resolver no código uma dúvida sobre a natureza fiscal da operação, mas precisa oferecer ao profissional responsável dados e controles suficientes para que a decisão seja aplicada corretamente.

E quando a nota inteira é devolvida?

A devolução integral não é uma exceção ao referenciamento por item. Mesmo quando todos os produtos e todas as quantidades da NF-e original estão sendo devolvidos, a nova NF-e continua possuindo seus próprios elementos det. Cada um deles deve informar, em DFeReferenciado, a chave de acesso do documento original e o número do item ao qual corresponde.

Na prática, se a nota original possui cinco itens e todos são devolvidos, a NF-e de devolução normalmente terá cinco itens referenciados. Todos podem repetir a mesma chaveAcesso, pois vieram do mesmo documento, mas o nItem deve reproduzir a correspondência individual: o produto originado no item 1 aponta para nItem = 1, o produto originado no item 2 aponta para nItem = 2, e assim sucessivamente.

O mesmo raciocínio vale para documentos extensos. Uma única NF-e aceita no máximo 990 itens de produto, e o XML transmitido não pode exceder 500 KB, conforme as perguntas frequentes do Portal Nacional da NF-e. Assim, na devolução integral de uma NF-e com 990 itens, os 990 itens da devolução devem carregar sua própria referência. A chave de acesso será repetida, mas cada grupo terá o nItem correspondente, de 1 até 990 quando essa for a numeração do documento original. Uma suposta NF-e com 1.000 itens não poderia ter sido autorizada como um único documento; a operação original precisaria estar dividida em mais de uma NF-e e a devolução teria de respeitar a origem de cada item em cada documento.

Isso não significa que a numeração dos itens da devolução tenha de ser idêntica à ordem da nota original. Se o ERP reorganizar as linhas, o item 1 da devolução poderá referenciar, por exemplo, o item 4 da origem. O valor transmitido em DFeReferenciado.nItem sempre identifica o elemento det original, não o item que está sendo criado. Manter a mesma ordem pode facilitar a conferência humana, mas não substitui o vínculo gravado corretamente.

Também não se deve interpretar “devolução integral” como autorização para informar apenas ide/NFref/refNFe. A observação da regra VC02-14 proíbe esse caminho para a devolução e direciona a referência para DFeReferenciado. Portanto, tanto a devolução parcial quanto a integral exigem que o sistema percorra os itens e preserve a origem individual de cada um.

Antes da emissão, “integral” deve ser verificado pelo conteúdo, e não apenas por uma marca na tela. O ERP precisa comparar os itens e as quantidades devolvidas com o documento original, considerar devoluções anteriores e impedir que a soma devolvida ultrapasse a quantidade documentada. A definição do tratamento fiscal, dos valores, dos tributos e de eventuais diferenças deve ser confirmada com o profissional contábil responsável; o vínculo técnico por item não resolve sozinho essas decisões.

Como preencher o DFeReferenciado no ACBrNFe

O exemplo oficial do ACBrNFe expõe DFeReferenciado como propriedade de Prod, dentro do item da coleção Det. Isso significa que não é necessário criar XML manualmente nem adicionar uma referência a uma coleção. Depois de adicionar o item à NF-e, atribua a chave de acesso e o número do item original em Item.Prod.DFeReferenciado.

O trecho abaixo isola apenas a parte relevante do preenchimento:

uses
  ACBrNFe.Classes,
  ACBrNFeNotasFiscais;

var
  Nota: NotaFiscal;
  Item: TDetCollectionItem;
begin
  Nota := ACBrNFe1.NotasFiscais.Add;

  // Demais grupos da NF-e devem ser preenchidos normalmente.
  Nota.NFe.Ide.finNFe := fnDevolucao;

  Item := Nota.NFe.Det.New;

  // Dados de produto, quantidade, valores e tributos foram omitidos.
  Item.Prod.DFeReferenciado.chaveAcesso :=
    '35260900000000000100550010000001231000001234';
  Item.Prod.DFeReferenciado.nItem := 3;
end;

A chave do exemplo é apenas ilustrativa e não deve ser copiada para uma emissão. O valor 3 significa que o produto devolvido corresponde ao item 3 da nota original. Ele não depende da posição ocupada na nova nota: o mesmo produto pode ser o item 1 da devolução e continuar referenciando o item 3 da origem.

Em uma rotina real, a referência deve vir do registro que relaciona o item atual ao movimento fiscal original. Um laço simplificado pode ser organizado assim:

for ItemDevolucao in Devolucao.Itens do
begin
  Item := Nota.NFe.Det.New;

  PreencherProduto(Item.Prod, ItemDevolucao);
  PreencherImpostos(Item.Imposto, ItemDevolucao);

  Item.Prod.DFeReferenciado.chaveAcesso :=
    ItemDevolucao.ChaveAcessoOrigem;
  Item.Prod.DFeReferenciado.nItem :=
    ItemDevolucao.NumeroItemOrigem;
end;

Esse mesmo laço atende à devolução integral: a coleção Devolucao.Itens deve conter todos os itens do documento original, cada um acompanhado de sua chave e de seu número de origem. Não crie uma única referência genérica para representar o conjunto, nem atribua automaticamente o contador do laço a nItem sem conferir o número armazenado no XML original.

Os nomes de classes do domínio Devolucao, ItemDevolucao, PreencherProduto e PreencherImpostos são ilustrativos. As propriedades confirmadas no programa oficial de demonstração são Produto.DFeReferenciado.chaveAcesso e Produto.DFeReferenciado.nItem. Como o componente evolui junto com as notas técnicas, atualize os fontes e schemas do ACBr antes dos testes e confira o XML gerado, não apenas os valores mantidos em memória.

Como deve ficar o XML

No XML, o grupo aparece dentro de det, no mesmo nível dos demais grupos associados ao item. Uma representação reduzida ajuda a visualizar a posição correta:

<det nItem="1">
  <prod>
    <!-- dados do produto devolvido -->
    <DFeReferenciado>
      <chaveAcesso>CHAVE-DE-44-POSICOES-DO-DFE-ORIGINAL</chaveAcesso>
      <nItem>3</nItem>
    </DFeReferenciado>
  </prod>
  <imposto>
    <!-- tributação do item -->
  </imposto>
</det>

O XML reduzido é didático e não deve ser usado como documento completo. A posição final e a aceitação das tags dependem dos schemas oficiais vigentes. O Portal da Conformidade Fácil da SVRS disponibiliza um validador da Reforma Tributária que permite conferir campos como finalidade, chave do DF-e referenciado e número do item. Ele é útil para explorar as combinações, mas o teste decisivo continua sendo a geração do XML completo e sua transmissão no ambiente de homologação da SEFAZ.

Testes que devem entrar na atualização do emissor

A mudança merece testes de integração, pois os erros mais prováveis não aparecem em uma simples compilação. Prepare ao menos os seguintes cenários:

1. devolução total de uma NF-e com um único item;
2. devolução integral de uma NF-e com vários itens, confirmando uma referência para cada item;
3. devolução integral cuja ordem dos itens seja diferente da ordem do documento original;
4. devolução parcial de quantidade de um item;
5. devolução de alguns itens de uma nota com vários produtos;
6. devolução formada por itens provenientes de documentos distintos, se o processo da empresa permitir;
7. item cuja posição na devolução seja diferente do nItem original;
8. chave ausente, inválida ou com menos de 44 posições;
9. número do item original ausente, zero ou inexistente;
10. tentativa de usar somente ide/NFref/refNFe em uma devolução;
11. tentativa de devolver quantidade superior à quantidade original ou ao saldo ainda não devolvido;
12. geração com a versão atualizada do ACBr e dos schemas;
13. transmissão em homologação para as unidades federadas atendidas pelo sistema.

Além de conferir a autorização ou a rejeição, arquive o XML produzido nos testes e compare sua estrutura com o schema vigente. A interface pode mostrar a chave e o número corretos, mas uma atribuição feita no objeto errado ou uma biblioteca desatualizada pode impedir que os campos cheguem ao arquivo transmitido.

Conclusão

A referenciação da NF-e de devolução por item não é apenas uma troca de tag. A regra já está bloqueando emissões em produção e exige que o ERP conserve a chave do documento e o número do item original ao longo de todo o fluxo de compra, venda, estoque e devolução.

No ACBrNFe, o preenchimento é direto: use Item.Prod.DFeReferenciado.chaveAcesso e Item.Prod.DFeReferenciado.nItem. O trabalho mais importante, porém, acontece antes dessas duas atribuições. O sistema deve recuperar a origem correta, impedir referências inconsistentes, gerar o grupo dentro de prod em cada det e validar o resultado. Para quem já recebe a rejeição, a correção precisa ser aplicada agora.

Referências

ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. Normas publicadas. Rio de Janeiro: ABNT, [s. d.]. Disponível em: https://abnt.org.br/normalizacao/normas-publicadas/. Acesso em: 25 set. 2026.

BRASIL. Portal da Nota Fiscal Eletrônica. Nota Técnica 2025.002-RTC: Reforma Tributária do Consumo — adequações NF-e/NFC-e, versões 1.40 e 1.51. Brasília, DF: Encat, 2026. Disponível em: https://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=04BIflQt1aY=. Acesso em: 25 set. 2026.

BRASIL. Portal da Nota Fiscal Eletrônica. Perguntas frequentes: modelo operacional — qual o limite de produtos em uma única NF-e? Brasília, DF: Encat, [s. d.]. Disponível em: https://www.nfe.fazenda.gov.br/Portal/perguntasFrequentes.aspx?tipoConteudo=auR4yGlWmRY=. Acesso em: 25 set. 2026.

PROJETO ACBr. Programa de demonstração ACBrNFe: Frm_ACBrNFe.pas. [S. l.]: Projeto ACBr, 2026. Disponível em: https://svn.code.sf.net/p/acbr/code/trunk2/Exemplos/ACBrDFe/ACBrNFe/Delphi/Frm_ACBrNFe.pas. Acesso em: 25 set. 2026.

PROJETO ACBr. Dúvida na validação de NF-e. Fórum Projeto ACBr, 24 jul. 2026. Disponível em: https://www.projetoacbr.com.br/forum/topic/93739-d%C3%BAvida-na-valida%C3%A7%C3%A3o-de-nf-e/. Acesso em: 25 set. 2026.

RIO GRANDE DO SUL. Secretaria da Fazenda. Validador da Reforma Tributária do Consumo — NF-e/NFC-e. Portal da Conformidade Fácil, [s. d.]. Disponível em: https://dfe-portal.svrs.rs.gov.br/Cff/ValidadorRTCNfe. Acesso em: 25 set. 2026.