Rejeição 316: a NF-e está referenciando a própria chave

A rejeição 316 ocorre quando a NF-e aponta para ela mesma na lista de documentos referenciados. A referência deveria identificar um documento de origem relacionado à operação, mas recebeu a chave da nota que está sendo enviada. Para corrigir, descubra qual documento deveria estar vinculado e ajuste o preenchimento na origem.

Não resolva o problema inventando outra chave, mudando a numeração sem necessidade ou selecionando uma nota qualquer. Fazer a referência ficar diferente é apenas uma parte da validação; ela também precisa ser verdadeira e adequada à operação.

O que a SEFAZ compara

No MOC 7.0, página 79, a BA02-50 é uma regra obrigatória da autorização de NF-e modelo 55. Quando existe referência em NFref/refNFe, verifica se a chave informada é a mesma da NF-e atual.

Essa regra não se limita a devoluções ou complementares. Esses são cenários frequentes de referenciamento, mas a condição da BA02-50 é a existência de refNFe com autorreferência. Também não estabelece uma dispensa por a nota ser de entrada, por usar determinada série ou por o emitente ser produtor rural.

A indicação nOcor no retorno ajuda a localizar a ocorrência problemática entre os documentos referenciados. Não é o número da nota original. Entregue ao responsável pelo emissor o retorno completo e o XML daquela tentativa, porque a tela pode mostrar uma versão diferente da efetivamente transmitida.

Onde procurar o preenchimento incorreto

Compare a chave atual, apresentada pelo sistema e no identificador infNFe/Id, com cada conteúdo de ide/NFref/refNFe. O identificador Id possui o prefixo literal NFe, que não integra as 44 posições da chave comparada.

A Oobj demonstra o vínculo incorreto dentro de NFref. Seu exemplo utiliza leiaute antigo; o que importa para o diagnóstico é a igualdade entre as identificações, não reproduzir aquele XML no emissor atual.

Há três situações que merecem atenção:

• A pessoa copiou a chave exibida na nota em elaboração, em vez da chave do documento de origem

• Uma rotina de integração usou a variável da chave atual para preencher a referência

• A cópia de um documento manteve vínculos que precisavam ser revistos para a nova operação

O preenchimento automático reduz trabalho, mas também pode repetir um erro de configuração em muitas notas. Se o problema começou após atualização do sistema ou importação de pedidos, confira o mapeamento antes de corrigir arquivos um por um.

Como selecionar a referência correta

Reconcilie o documento com o pedido, o recebimento, a devolução ou a diferença que está sendo documentada. Confira emitente, destinatário, produtos, data, finalidade e situação da nota de origem. A coincidência de número ou valor não demonstra que é o documento certo.

A Softniels apresenta a substituição do vínculo pela chave selecionada no documento de origem. No seu sistema, o nome da aba pode ser diferente. O resultado a verificar é o XML gerado após a alteração.

Uma empresa fictícia prepara uma complementar e, ao copiar uma informação da tela, preenche a referência com a chave da própria complementar. A equipe localiza a nota original autorizada, comprova a diferença a complementar e substitui o vínculo. A chave correta vem do documento existente; não é calculada para imitar uma origem.

Se não existe documento que justifique a referência, investigue por que ela foi incluída. A Berga menciona retirar vínculos indevidos. Isso só cabe quando a operação realmente dispensa aquele referenciamento. Excluir o grupo de uma complementar apenas troca o problema por outra rejeição.

Finalidade e mudanças da reforma tributária

A NT 2025.002 v1.52, página 31, exige NFref para complementar e determinados créditos dos tipos 01, 03 e 04. Há também limites de quantidade e comparações de emitente. Corrigir a autorreferência não elimina esses controles.

Na devolução, a mesma NT prevê mudança para referência por item em DFeReferenciado, pela VC02-14. O PDF aponta produção em 03/11/2026. Um aviso do ENCAT de 05/10 inclui a NT entre mudanças adiadas para 26/10 em homologação e 16/11 em produção, mas não individualiza essa regra. Em 09/10, esse marco ainda é futuro: confirme a programação aplicável antes de migrar o preenchimento.

Não copie a chave de um grupo para outro indiscriminadamente. NFref, referência por item e vínculo de pagamento possuem funções próprias. Uma alteração de leiaute não autoriza criar uma nova operação para contornar a rejeição.

refNFeSig tem uma validação diferente

A NT 2022.003 v1.11, página 10, trata da referência com código numérico zerado em refNFeSig. A autorreferência por chave natural nesse campo gera o código 952, pela BA02a-100, e não 316.

A comparação ali considera UF, CNPJ/CPF, série e número. Trocar refNFe por refNFeSig não é uma forma de liberar a nota: existem restrições próprias, inclusive finalidade normal e condição por UF. Não zere parte da chave manualmente para fazer o conteúdo parecer diferente.

Cuidados com documentos e sistemas atuais

A chave tem 44 posições. A NT 2026.004 v1.01 adapta refNFe e refNFeSig ao CNPJ alfanumérico. Preserve letras e zeros legítimos; uma rotina que guarda a chave como número pode corromper a identificação.

PAA e Nota Fiscal Fácil possuem regras próprias de série e processo. Não altere série, CNPJ, CPF ou tipo de emissão para romper a igualdade artificialmente. A identificação deve continuar sendo a do contribuinte e do documento reais.

A NT 2026.002 v1.11 também restringe referências em NFC-e e NF-e com DANFE Simplificado Tipo 2 e veda grupos antigos como refNFP. Eles não são alternativas para esconder a própria chave.

Depois de corrigir o vínculo, regenere e assine o XML pelo emissor. Consulte previamente qualquer envio com resultado incerto. Acompanhe o retorno individual da tentativa corrigida e guarde o protocolo quando houver autorização, sem tratar uma simples troca de mensagem como conclusão.

Referência de atualização: 09/10/2026. Diagnóstico de autorização de NF-e modelo 55, condicionado à versão e ao ambiente.