Rejeição 1010: escolha o nível correto de referência na NF-e

A rejeição 1010 acontece quando uma NF-e combina referência a documento no cabeçalho com referência no item. Para a empresa, isso costuma aparecer depois de uma mudança na geração da nota: o emissor passou a vincular a origem por item, mas continuou preenchendo a referência geral. A solução exige conservar o vínculo exigido para a operação e eliminar a estrutura indevida. Apagar todas as referências pode impedir a rejeição 1010 e deixar a nota sem uma informação fiscal necessária.

A mensagem exata é “Rejeição: NF-e com referenciamento de documento a nível de nota e a nível de item [nItem: 999]”. O item indicado ajuda a localizar onde apareceu DFeReferenciado; a investigação também precisa olhar o cabeçalho e os demais itens.

O que a regra verifica

Na NT 2025.002-RTC v1.52, página 69, a VC02-05 é exclusiva da NF-e modelo 55, no serviço de autorização. Se um item possui DFeReferenciado/chaveAcesso e existe documento referenciado no grupo NFref da nota, a combinação é rejeitada. A regra não exige que as duas referências tenham a mesma chave. Uma chave no cabeçalho e outra no item continuam preenchendo os dois níveis proibidos. [1]

Essa distinção evita um diagnóstico enganoso de “chave duplicada”. A rejeição 1072 trata de repetição de documento/item em outro contexto, pela VC02-20. Na 1010, o ponto é a coexistência das estruturas. Não procure apenas valores iguais e conclua que o XML está correto porque as chaves são diferentes.

Na NFC-e modelo 65, a VC02-04 tem outra condição e outro retorno: 708, porque a NFC-e não pode referenciar documento fiscal no item. Não use a estratégia de transferir a referência do cabeçalho para o item de uma NFC-e para resolver esse problema. Confirme sempre modelo, serviço, UF, autorizador, ambiente e mensagem completa.

Antes de escolher o que remover

Identifique a finalidade da NF-e e o tipo de nota, quando aplicável. A referência não é uma preferência de apresentação. Existem operações que exigem documento por item e outras em que essa forma de vínculo é indevida.

Na nota de crédito, por exemplo, a VC02-07 veda DFeReferenciado quando finNFe=5, com exceção do tipo 06, retorno por recusa parcial na entrega. Já a VC02-10 exige a referência por item nos tipos de débito 03 e 04 e no tipo de crédito 06. São condições próprias; o diagnóstico da 1010 não autoriza remover um vínculo exigido por elas. [1]

Nas devoluções, a VC02-14 estabelece a migração para referência por item. A v1.52 mostra produção em 03/11/2026, com datas anteriores riscadas. O aviso posterior do ENCAT, de 05/10, posterga a implantação das mudanças recém-publicadas para 16/11/2026 em produção e 26/10 em homologação. Em 10/10/2026, não se deve declarar essa mudança como já implantada em produção em todas as UFs. O cronograma herdado de homologação da VC02-14 e as regras antigas precisam ser analisados separadamente. [1][2]

Como encontrar a origem da mistura

Guarde o XML rejeitado, o retorno original e os dados da nota de origem. Compare a configuração da operação com o arquivo transmitido. Peça ao suporte que localize NFref no cabeçalho e DFeReferenciado/chaveAcesso em cada item, verificando também o número do item original, quando exigido.

Três causas possíveis merecem atenção:

• Uma configuração antiga continua gerando NFref, enquanto a nova rotina monta DFeReferenciado.

• O operador vincula a nota de origem no cabeçalho e a integração também acrescenta sua referência nos itens.

• A emissão foi copiada de outro documento e conservou um vínculo incompatível com a operação atual.

A existência dessas estruturas na tela não garante que o XML as represente da mesma forma. Alguns emissores compõem a referência a partir de dados de origem guardados em outras rotinas. Corrigir somente a visualização pode deixar a geração intacta.

Correção por cenário

A operação exige referência no item. Mantenha as chaves e os números de item exigidos, retire a referência geral indevida e confira todos os itens envolvidos. Na devolução preparada para o fluxo novo, faça a associação com o XML original, não com a posição visual de uma planilha. O responsável fiscal deve confirmar a aplicação no ambiente e no prazo pertinente.

A operação utiliza referência no cabeçalho e não admite ou não exige a estrutura por item. Preserve o vínculo correto em NFref e ajuste a configuração que acrescentou DFeReferenciado indevidamente. Antes de executar essa opção, confira finalidade e tipo; ela não pode apagar uma exigência específica de nota de débito ou de retorno.

O documento tem referências de origens diferentes. Não reorganize vínculos para um único documento por conveniência. Confirme as regras de quantidade de documentos e suas exceções, a identidade das partes e a relação entre item atual e item original. Se a operação não puder ser representada como foi cadastrada, a definição deve vir da análise fiscal.

A correção desaparece ao gerar novamente. O problema está na origem dos dados ou na rotina de integração. Ajuste essa origem e produza novo XML pelo emissor. Não altere manualmente o arquivo já assinado nem tente transmitir repetidamente versões com a mesma inconsistência.

Um exemplo sem trocar a operação real

Uma distribuidora fictícia prepara uma devolução de duas mercadorias. A equipe decide, com a contabilidade e o suporte, usar o referenciamento por item no ambiente que está testando. O item 1 aponta a mercadoria da nota de origem; o item 2 tem seu próprio vínculo. Entretanto, a rotina antiga também preenche NFref no cabeçalho.

O retorno aponta 1010. O suporte retira a geração duplicada no cabeçalho e preserva as relações por item, revisando chaves e posições contra o XML de origem. Não muda a finalidade da devolução para uma venda normal, não exclui as referências e não altera o destinatário. A validação seguinte ainda pode apontar outro problema, que será analisado conforme sua própria regra.

Como confirmar e quando escalar

Após corrigir, regenere a NF-e pelo fluxo do emissor, incluindo assinatura, e confira o XML antes da nova transmissão. A comparação precisa mostrar apenas o nível adequado e os vínculos fiscais preservados. Leia o retorno final: ausência de 1010 é uma etapa; autorização exige resultado correspondente à chave correta e protocolo preservado.

Procure a contabilidade quando houver dúvida sobre finalidade, tipo de nota ou documento que deve ser vinculado. Acione o suporte quando o cadastro correto gerar grupos indevidos ou quando a implantação do autorizador divergir da documentação. Envie XML, retorno, data, ambiente, versão do emissor e evidências da origem. A presença da VC02-05 na nota técnica e o calendário nacional não constituem teste de funcionamento em toda UF.

Fontes consultadas

1. NT 2025.002-RTC v1.52, p. 5–6, 29 e 69–70, VC02-05 e regras de referenciamento.

2. Avisos oficiais SVRS/ENCAT, comunicado de 05/10/2026; lista oficial de documentos, publicação da v1.52 em 01/10/2026.

Conferência prática em 10/10/2026: TOTVS Protheus, Sankhya e Migrate/InvoiCy. A descrição da TOTVS restringe o caso à mesma chave; a VC02-05 oficial não traz essa restrição. Os exemplos de integração de fornecedores não substituem o leiaute oficial nem o cronograma atualizado. Revisão por IA, sem certificação fiscal humana ou teste operacional por UF.