Rejeição 502: Id da NF-e diverge dos campos da chave
Revisão editorial em 15 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.
A Rejeição 502, regra A03-10 do serviço de autorização, ocorre quando a chave de acesso contida em infNFe/@Id não corresponde à concatenação dos campos da própria nota. O MOC a classifica como obrigatória para os modelos 55 e 65. Ela não se refere ao Id do protocolo da SEFAZ.
Qual comparação a regra faz
O atributo Id de infNFe contém o literal NFe seguido da chave. A composição deve refletir os campos correspondentes: UF, ano/mês da emissão, identificação do emitente aplicável, modelo, série, número da nota, tipo de emissão, código numérico e dígito verificador. A conferência deve usar o XML efetivamente enviado, não uma tela que possa mostrar dados de outra versão.
A03-10 contém uma observação relevante: na Nota Fiscal Avulsa da série 890–899, considere o CNPJ da SEFAZ da UF correspondente na composição. Nos demais casos, a regra menciona CNPJ/CPF do emitente. Não aplique essa exceção fora de sua condição nem substitua a identificação do emitente por iniciativa própria.
O que a evolução do leiaute muda
A NT 2026.004 v1.01 atualizou schemas para CNPJ e chaves alfanuméricos, com homologação até 15/06/2026 e produção 01/07/2026. TChNFe no PL_010f_v1.04 admite 44 caracteres no padrão que permite letras maiúsculas nas posições previstas. A chave deve ser preservada como texto; uma rotina numérica antiga pode descartar caracteres ou perder precisão.
Isso não dispensa a coerência entre Id e campos da nota e não autoriza inventar CNPJ, CPF, código numérico ou DV. A origem de cada componente precisa ser o documento real e seu cadastro confirmado.
Exemplos de causas e conferências
Cenário sintético A: o emissor compõe Id com uma série e depois altera a série em ide sem reconstruir coerentemente a identificação antes da assinatura. Compare o segmento da chave com o valor enviado em ide/serie. A correção pertence ao processo de geração da nota ainda rejeitada, usando os dados reais.
Cenário B: a identificação foi gerada com o mês anterior, enquanto dhEmi enviado pertence a outro mês. Compare o ano/mês da chave à emissão original. Não altere a data real para combinar com uma chave incorreta.
Cenário C: uma rotina aplica sempre o CNPJ do emitente a uma avulsa na série 890–899. Confirme se essa condição realmente se aplica e confronte a identificação prevista na observação oficial. Não generalize a exceção a toda nota emitida por CPF ou a toda avulsa.
Não há XML completo nos exemplos: seriam necessários chave e identificadores reais. Uma chave inventada não ajuda a comprovar essa igualdade.
Como corrigir e verificar sem criar outra inconsistência
Preserve envio e retorno, confirme código 502 e serviço de autorização e localize o infNFe correspondente. Refaça a composição em memória a partir dos campos reais e compare componente a componente, preservando zeros e comprimentos. Identifique qual origem divergiu. Se houve alteração após gerar Id ou assinar, corrija o fluxo para gerar e assinar o documento coerente antes de uma tentativa autorizada. Não edite um XML já assinado ou autorizado.
A rejeição 253/B23-10 trata o dígito verificador da chave composta; é outra comparação. Um DV correto não prova que Id corresponde aos demais campos. Da mesma forma, o Id de infProt identifica a resposta e não deve ser usado para corrigir esta regra.
Eliminar a divergência não garante autorização: outras validações continuam aplicáveis. Se houver comunicação incerta ou uma resposta de autorização para a mesma identidade, consulte a situação antes de reenvio; não crie nova numeração para contornar o diagnóstico.
Leituras relacionadas
Fontes oficiais
- MOC 7.0 Anexo I — 7.00: A03-10 p. 74; B02-10, B02-20, B03-10 e B06-10 p. 75.
- Leiaute NF-e/NFC-e — PL_010f_v1.04: TProtNFe, linhas 6686–6770.
- Tipos básicos NF-e/NFC-e — PL_010f_v1.04: TChNFe, TProt, TStat, TAmb, TVerAplic, TMotivo e TDateTimeUTC.
- NT 2026.004 CNPJ alfanumérico — 1.01: chave de acesso, leiaute e cronograma.