Rejeição 502 na NF-e: confira a formação do Id sem alterar a nota autorizada

A rejeição 502 aponta uma divergência entre o identificador do XML e os campos que deveriam compô-lo. Na autorização de NF-e ou NFC-e, o sistema precisa formar a chave de acesso com os mesmos dados existentes na nota. Quando as duas representações não correspondem, o documento enviado é rejeitado.

A primeira providência é identificar a operação que recebeu o retorno. O código também aparece em pedido de inutilização, cujo identificador tem composição diferente. E um erro de comunicação “HTTP 502” não equivale ao cStat 502 da SEFAZ: é necessário ler o retorno fiscal e sua mensagem completa.

Na emissão, a chave precisa representar o próprio XML

A regra A03-10 do MOC 7.0, Anexo I, página 74, abrange NF-e 55 e NFC-e 65. Ela compara a chave contida no atributo Id de infNFe com a composição dos campos correspondentes.

Esse Id usa o prefixo “NFe” seguido da chave de 44 posições. Não é um identificador livre escolhido pelo operador. No leiaute documentado pelo MOC 7.0, Visão Geral, página 19, a chave reúne:

• Código da UF e ano/mês de emissão

• Identificação do emitente, respeitadas as situações especiais

• Modelo, série e número do documento

• Forma de emissão, código numérico e dígito verificador

O problema pode surgir quando uma dessas informações é alterada no cadastro ou na nota, mas a integração reaproveita uma chave construída antes da alteração. Por exemplo: o XML registra determinada série, enquanto o Id ainda representa outra. O importante é localizar a divergência real; uma chave com tamanho correto pode continuar incompatível com o conteúdo.

Para o empresário, a pergunta útil ao fornecedor é: “Qual campo está diferente entre o XML transmitido e o identificador gerado?”. A resposta deve apontar o dado e a etapa que o produziu, em vez de simplesmente pedir que a emissão seja repetida.

Data de emissão, série e identidade exigem cuidado

O componente ano/mês vem da emissão. Conferir essa correspondência é especialmente importante em transmissões que atravessam a virada do mês ou recuperam arquivos pendentes. A data do envio posterior não deve substituir automaticamente a data real da emissão. Também não se deve deslocar a operação no tempo só para obter autorização.

A série merece atenção porque participa da chave e pode indicar uma modalidade especial de emissão. A observação da A03-10, incorporada pela NT 2018.001 v1.10, página 14, manda considerar o CNPJ da SEFAZ correspondente na Nota Fiscal Avulsa das séries 890 a 899. Nos demais casos, considera-se o CNPJ ou CPF do emitente. Não é seguro resolver qualquer 502 trocando a série para 1.

Para emitente pessoa física, o MOC Visão Geral descreve o CPF precedido de zeros até completar as 14 posições reservadas à identificação na chave. Isso não converte CPF em CNPJ nem autoriza escolher qualquer série: a permissão de emissão e o enquadramento precisam ser compatíveis com o modelo, a UF e o processo utilizado.

Também é necessário atualizar validadores antigos. A NT Conjunta 2025.001 v1.00 e a NT 2026.004 v1.01 tratam do CNPJ alfanumérico e de sua repercussão nos campos e chaves. Uma rotina que elimina todas as letras pode destruir uma identificação válida. A conferência deve usar a especificação aplicável, não uma fórmula antiga apresentada como universal. Essas alterações de formato, por si só, não comprovam a implantação operacional de cada autorizador.

Na inutilização, o Id identifica um pedido de faixa

O MOC 7.0, Visão Geral, páginas 79 e 80, apresenta outro uso da 502: regra I04.a do serviço NfeInutilizacao. Aqui, o atributo pertence a infInut e identifica a solicitação, não uma nota emitida.

O leiaute documenta 43 caracteres, incluindo o prefixo “ID”, formados a partir de UF, ano com duas posições, CNPJ, modelo, série, número inicial e número final. Não se deve copiar para esse campo a chave de 44 posições de uma NF-e. A NT 2026.004 v1.01 também atualiza o tipo do CNPJ nesse serviço. A possibilidade de CPF em infNFe não autoriza substituir o CNPJ por CPF no pedido infInut.

Se a tentativa rejeitada era uma inutilização, confira os parâmetros da faixa e peça ao sistema que reconstrua o pedido coerentemente. Isso não autoriza inutilizar número já utilizado, cancelar uma nota autorizada ou criar outra solicitação com intervalo diferente. A rejeição informa falha naquele pedido; não prova sua homologação.

Um roteiro seguro para o reenvio

1. Preserve o XML transmitido e o retorno com cStat e xMotivo. Registre modelo, ambiente, série, número e versão do emissor

2. Confirme que o documento continua rejeitado. Se houve perda de resposta ou tentativas anteriores, consulte recibos e situação antes de modificar dados

3. Identifique o componente divergente, comparando o identificador com os campos do arquivo efetivamente enviado

4. Corrija a origem do erro no emissor ou na integração, mantendo os fatos reais da operação

5. Somente para o documento ou pedido ainda rejeitado, gere novamente o XML coerente, valide-o e aplique a assinatura exigida antes da transmissão

6. Confira o novo resultado e guarde o protocolo pertinente. A ausência da 502 não significa, sozinha, que a autorização ou a inutilização foi concluída

Não edite manualmente chave, Id ou conteúdo de XML autorizado. A assinatura e o protocolo estão associados ao documento original. Tampouco presuma que excluir o cadastro do ERP, trocar o número ou inutilizar a faixa seja a correção necessária para esse código.

Evite misturar contratos antigos e eventos atuais

O MOC 5.0 registrava a 502 na regra H02c do antigo serviço de cancelamento. Esse registro histórico não determina a montagem dos eventos atuais. O identificador de evento tem contrato próprio; há regras específicas que retornam 572 quando sua concatenação está errada.

A pesquisa documental de outubro de 2026 sustenta os ramos separados de autorização e inutilização. Para prevenir reincidências, a integração deve gerar dados, identificador e assinatura a partir da mesma versão da operação, evitando reaproveitar um Id depois que algum componente mudou.

Fontes práticas consultadas

TecnoSpeed, Omie e Inforsystem foram lidos para o diagnóstico de emissão. O guia FlexDocs de inutilização complementa o contexto de integração, com referências antigas tratadas como históricas.