Rejeição 1038: informe a chave do documento de origem no item da NF-e

Se a NF-e recebeu a rejeição 1038, confira qual débito ou crédito ela pretende registrar e qual documento deu origem a esse lançamento. Nos tipos alcançados pela regra, o item precisa carregar a chave do documento fiscal de origem no grupo DFeReferenciado. Ter essa chave anotada em observações ou vinculada apenas ao cabeçalho não demonstra que ela foi enviada no lugar exigido.

A mensagem é “Rejeição: DFeReferenciado não informado [nItem: 999]”. O número entre colchetes identifica o item apontado no retorno; 999 é a representação usada na documentação. Guarde a resposta completa antes de corrigir o documento.

Quando esta regra se aplica

Na NT 2025.002-RTC v1.52, página 69, a regra VC02-10 pertence à autorização da NF-e, modelo 55. Ela exige DFeReferenciado/chaveAcesso quando o tipo informado é débito 03, relativo a notas não processadas na apuração; débito 04, multa e juros; ou crédito 06, retorno por recusa parcial na entrega. A finalidade e o tipo devem representar o caso real. [1]

Não transforme essa lista em exigência para toda venda, toda nota de débito ou toda nota de crédito. Também não transfira o procedimento para a NFC-e 65: o referenciamento de documento nesse modelo tem vedação própria, associada ao retorno 708. Devolução de mercadoria é outro ramo documental, com regra e cronograma próprios.

A versão 1.52 estava listada no portal oficial em 10/10/2026. O aviso do ENCAT de 05/10 adiou sua implantação anunciada para 26/10/2026 em homologação e 16/11/2026 em produção. Isso não prova que a VC02-10, já documentada anteriormente, esteja suspensa até novembro. Identifique a versão implantada, a UF, o autorizador e o ambiente do retorno recebido. Não há teste operacional por UF nesta revisão. [2][3]

O que pode ter causado a falta

Uma referência pode existir no cadastro comercial e se perder durante a preparação fiscal. A empresa seleciona uma nota anterior, mas a integração guarda a chave em um campo de observação. Em outro cenário, o vínculo fica na nota inteira, enquanto o arquivo exige a informação associada ao item. Também pode acontecer de um item ser adicionado depois que as referências foram montadas, ficando sem documento de origem.

Outra possibilidade é o tipo fiscal estar errado desde o início. Um modelo de emissão reaproveitado pode ter conservado um tipo de débito que não corresponde à operação. Nesse caso, preencher uma chave qualquer não corrige a causa: primeiro é necessário confirmar a finalidade adequada com o responsável fiscal.

Essas são hipóteses de investigação, não uma conclusão automática sobre seu sistema. O que decide o diagnóstico é a comparação entre operação, configuração e XML efetivamente transmitido.

Como conferir antes de alterar

Separe o XML rejeitado, a resposta da SEFAZ, o documento de origem e a informação que justificou o débito ou crédito. Peça ao suporte para localizar finNFe, tpNFDebito ou tpNFCredito na identificação da nota e o grupo DFeReferenciado no item indicado. Compare o arquivo com a tela do emissor.

Confira a chave completa no documento original preservado. A chave identifica um documento fiscal específico; número e série isolados não a substituem. Uma chave digitada corretamente pode ainda pertencer a outra operação, por isso compare emitente, destinatário, data e conteúdo do documento antes de vinculá-lo.

Se a tela mostra uma referência e o XML não, registre ambos. Essa evidência ajuda a distinguir uma falta de preenchimento de uma falha de geração. Não edite diretamente o arquivo já assinado: a correção deve passar pelo fluxo do emissor, que produzirá e assinará o novo conteúdo.

Como corrigir conforme o cenário

O documento de origem ainda não foi vinculado

Localize o documento correto nos arquivos da empresa e confirme sua relação com o lançamento. Preencha o vínculo no recurso do emissor que gera a referência do item. Se não houver documento disponível ou existir dúvida sobre qual nota originou o ajuste, suspenda a correção e envolva o responsável fiscal. Inventar uma referência transforma uma rejeição técnica em informação fiscal falsa.

A chave ficou apenas no cabeçalho ou em observações

Solicite a revisão do mapeamento para que a chave saia em DFeReferenciado/chaveAcesso no item pertinente. Não duplique indiscriminadamente a referência nos dois níveis: o mesmo conjunto documental contém a regra 1010 para a coexistência de referências no nível da nota e do item. O suporte deve conferir o fluxo completo, não apenas acrescentar uma tag para eliminar a primeira mensagem.

A nota é de débito tipo 03

A chave continua necessária, mas o número do item de origem tem tratamento diferente: a VC03-10 não permite DFeReferenciado/nItem nessa hipótese e pode retornar 1039. Portanto, não copie um modelo de devolução que preenche o número do item automaticamente. A montagem deve conservar a chave e respeitar a condição do tipo 03. [1]

O caso é débito 04 ou crédito 06

Confira também o item do documento de origem. A VC03-20 trata da falta de DFeReferenciado/nItem fora da exceção do tipo 03 e pode gerar 1048. O número referenciado corresponde ao item do documento original, que pode ser diferente da posição do produto na nova NF-e. Essa conferência é complementar; não autoriza escolher um tipo fiscal apenas porque exige menos campos.

Exemplo hipotético

Uma distribuidora prepara uma NF-e para registrar multa e juros, com o tipo 04 confirmado pela contabilidade. A nota original está vinculada no atendimento comercial, mas a integração envia o item sem DFeReferenciado/chaveAcesso. A autorização retorna 1038 para o item 2.

A equipe preserva o retorno, confere a origem do lançamento e identifica que o vínculo não chegou ao XML. O suporte corrige o mapeamento da referência desse item e verifica também o número do item original exigido no cenário. A finalidade, os valores e a operação não são alterados para contornar a rejeição.

Como verificar o resultado e quando escalar

Depois da correção, compare o novo XML com o anterior: o item indicado deve conter a referência verdadeira no local esperado. Confira os demais itens envolvidos, porque corrigir o primeiro erro pode revelar outra inconsistência. Reenvie pelo procedimento do emissor e leia a nova resposta completa. O desaparecimento do 1038 não equivale, sozinho, à autorização; confirme o protocolo e a situação fiscal retornados.

Acione o suporte quando o campo preenchido não chegar ao arquivo, a referência for removida ao recalcular a nota ou o retorno não combinar com o modelo e o tipo enviados. Procure o responsável fiscal quando faltar documento de origem, houver conflito sobre o tipo de débito ou crédito, ou a operação não se enquadrar nas hipóteses descritas. Encaminhe XML, retorno, horário, ambiente, UF/autorizador e versão do emissor por canal apropriado, preservando o histórico.

Fontes e revisão

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

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

2. Documentos oficiais SVRS, publicação da v1.52 em 01/10/2026.

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

Conferência prática: Migrate/InvoiCy, 1038, Sankhya, 1038 e Alterdata, importação RTC. A Alterdata é adjacente, não uma solução específica da 1038. A orientação Sankhya sobre tipos 01/05 diverge do gatilho da VC02-10 atual e não foi adotada. Exemplos de estrutura de integradores não substituem o leiaute oficial; as divergências estão registradas em fontes.json.