Rejeição 1039: retire o nItem referenciado somente no débito tipo 03

Se a NF-e recebeu 1039, confira o tipo de nota de débito antes de procurar um número de produto diferente. No cenário específico dessa rejeição, o problema é a presença de um campo que não deve ser enviado. Para o débito tipo 03, a referência conserva a chave do documento de origem, mas não deve levar o número do item desse documento.

A mensagem exata é “Rejeição: nItem do DFeReferenciado informado indevidamente [nItem: 999]”. Guarde o retorno completo. O item indicado entre colchetes ajuda a localizar a ocorrência na NF-e transmitida; não é uma instrução para preencher o campo com 999.

O contexto fiscal e documental

A regra VC03-10 da NT 2025.002-RTC v1.52, página 70, pertence à autorização da NF-e, modelo 55. Seu gatilho é tpNFDebito=03, utilizado para débitos de notas fiscais não processadas na apuração, com DFeReferenciado/nItem preenchido. Não é uma regra geral de número incorreto em devolução, complemento ou venda normal. A classificação da operação deve ser confirmada pelo responsável fiscal. [1]

A coluna de modelo não inclui NFC-e 65. Se o sistema apresenta 1039 num fluxo de NFC-e, confira com o suporte o documento e o serviço efetivamente usados. O número isolado não substitui mensagem e XML.

Em 10/10/2026, o portal oficial listava a v1.52. O aviso ENCAT de 05/10 postergou a implantação anunciada dessa versão para 26/10/2026 em homologação e 16/11/2026 em produção. Não conclua que a VC03-10, existente em documentação anterior, ficou suspensa: o aviso não atesta a situação de cada regra histórica ou autorizador. Confirme ambiente, UF, versão implantada e retorno real do caso. [2][3]

Dois números de item que precisam ser separados

O arquivo da NF-e identifica cada item atual pelo atributo nItem do elemento det. Esse identificador organiza os produtos ou registros da nota que está sendo emitida. Já o campo DFeReferenciado/nItem aponta uma posição em outro documento, o documento de origem. Apesar de usarem o mesmo nome, cumprem funções diferentes.

A correção da 1039 não significa apagar o identificador do item atual. Também não exige renumerar todos os produtos. O suporte precisa localizar o campo dentro do grupo de referência e retirar somente a informação vedada no cenário do débito 03. Uma busca e substituição indiscriminada por “nItem” pode danificar a estrutura da nota.

O leiaute apresenta esse campo como opcional em sua estrutura, mas as regras acrescentam condições. “Opcional” não significa livre em qualquer operação: a VC03-10 proíbe sua presença no tipo 03, enquanto a VC03-20 exige o número em referências fora dessa hipótese. Esta última situação está associada ao retorno 1048. [1]

Por que o campo pode ter sido preenchido

Investigue como a nota foi criada. Um modelo de devolução pode ter sido reutilizado para preparar o débito, conservando o número do item original. Uma integração pode preencher chave e número como um par obrigatório para todas as finalidades, sem observar a exceção. O próprio recurso de copiar uma nota pode transportar referências que deixam de ser pertinentes ao documento novo.

Também há o caso em que o tipo 03 foi selecionado por engano. Não é possível resolver essa dúvida apenas removendo o campo. Se o fato fiscal corresponde a outra operação, a identificação inteira deve ser revista com a contabilidade, e os campos exigidos para o cenário correto precisam ser preservados.

Confirme a hipótese no histórico. Não altere o tipo de débito só para eliminar a mensagem.

O que conferir no documento rejeitado

Peça ao suporte para comparar o XML transmitido com a configuração da nota. Localize a finalidade, tpNFDebito, o item apontado no retorno e seu grupo DFeReferenciado. Confira se o número de origem está realmente presente nesse grupo, mesmo quando a tela parece estar vazia. Algumas rotinas recompõem a referência ao gerar o arquivo.

Preserve a chave do documento de origem e a documentação do lançamento. A rejeição 1038 trata da ausência da chave para determinados tipos, incluindo o débito 03. Apagar todo o grupo de referência pode trocar a 1039 pela 1038, sem resolver a necessidade de vincular a operação anterior.

Confira também se a referência foi duplicada no cabeçalho e no item. O problema no número não dispensa as demais regras: o documento inteiro precisa representar a operação.

Como corrigir em cada situação

O débito tipo 03 está correto

Retire DFeReferenciado/nItem pelo recurso apropriado do emissor, mantendo a chave verdadeira. Peça que a rotina de geração respeite a condição do tipo 03, inclusive em futuras notas. Corrigir apenas um documento deixa a causa ativa quando o problema vem de um modelo ou integração.

Gere novamente o XML e examine-o antes do envio. Um campo com zero, vazio ou um número arbitrário não representa a ausência exigida. O suporte deve garantir que a tag vedada não seja gerada nesse cenário.

O tipo informado não corresponde ao lançamento

Reúna os documentos e confirme com o responsável fiscal qual operação ocorreu. Corrija a identificação apenas quando houver fundamento para isso. Depois confira novamente a referência e o número do item exigidos no contexto adequado. Essa análise pode afetar outros dados fiscais, por isso não basta mudar o tipo e reenviar sem revisar o documento inteiro.

O XML já respeita a regra, mas o retorno continua

Compare o arquivo que foi examinado com o arquivo efetivamente enviado e a resposta correspondente. Uma tela pode mostrar a versão corrigida enquanto uma fila transmite uma versão anterior. Registre horário, ambiente e identificação do envio para o suporte conciliar a tentativa, sem repetição automática de um documento rejeitado.

Exemplo hipotético

Uma empresa prepara um débito tipo 03 com o enquadramento confirmado. O emissor reutiliza o mecanismo de referência de uma devolução e envia o item atual 3 com a chave original e DFeReferenciado/nItem=11. A resposta traz 1039.

A comparação mostra que o tipo de débito está certo e que o número 11 veio do modelo reaproveitado. A equipe retira somente o número dentro de DFeReferenciado, conserva a chave correta e mantém a identificação 3 do item atual. A rotina é ajustada para não repetir essa montagem nas próximas notas do mesmo tipo.

Como confirmar a correção e quando pedir apoio

Após gerar o novo arquivo, confira que a referência mantém a chave de origem e não contém o número vedado. Verifique todos os itens pertinentes, não só o primeiro que apareceu no retorno. O novo conteúdo deve ser assinado e transmitido pelo fluxo do emissor; não altere manualmente um XML já assinado.

Leia a resposta seguinte e confirme a situação fiscal da nota. A eliminação da 1039 não garante autorização, porque outras validações podem apontar problemas independentes. Preserve o XML e o protocolo quando houver autorização efetivamente confirmada.

Acione o suporte quando a tag reaparecer, o sistema remover a chave junto com o número ou o arquivo transmitido divergir da tela. Procure a contabilidade quando houver dúvida sobre o tipo 03 ou o documento que originou o lançamento. Encaminhe as versões dos arquivos, o retorno completo, ambiente, UF/autorizador e identificação da tentativa, preservando o histórico da correção.

Fontes e revisão

Consulta e revisão documental por IA: 10/10/2026. Sem certificação fiscal humana ou teste operacional por UF.

1. NT 2025.002-RTC v1.52, p. 29, 69–70; VC02-10, VC03-10 e VC03-20.

2. Documentos oficiais SVRS, v1.52 publicada em 01/10/2026.

3. Aviso ENCAT de 05/10/2026, cronograma posterior ao PDF.

Conferência prática: Migrate/InvoiCy, 1039, Sankhya, 1039 e Alterdata, importação RTC. A Alterdata é adjacente. A Sankhya descreve número inexistente e inclui NFC-e, interpretação que não foi adotada para a VC03-10. O exemplo Migrate mistura referências no cabeçalho e no item; foi usada apenas a explicação concordante do gatilho. As regras oficiais prevalecem.