Rejeição 249 — UF da Chave de Acesso diverge da UF autorizadora

O que é esta rejeição?#

A Rejeição 249 é retornada pela SEFAZ durante a validação da NF-e quando há uma inconsistência relacionada a chave de acesso que identifica unicamente a NF-e, dígito verificador calculado a partir da chave de acesso. Isso significa que a nota fiscal não foi autorizada e precisa ser corrigida antes de ser retransmitida.

Este código indica que rejeição: UF da Chave de Acesso diverge da UF autorizadora.

Os campos afetados estão na seção de chave de acesso, identificação da NF-e do XML.

Campos XML relacionados#

Esta rejeição está associada aos seguintes campos do XML da NF-e. Verifique cada um deles ao diagnosticar o problema:

Causas comuns#

• O dígito verificador da chave de acesso está incorreto
• A chave de acesso tem formato inválido (deve ter exatamente 44 dígitos)
• Os componentes da chave (UF, data, CNPJ, modelo, série, número) não correspondem aos dados da NF-e
• O código numérico aleatório (cNF) está ausente ou com formato incorreto

Como resolver#

1. Recalcule o dígito verificador usando o algoritmo módulo 11 conforme especificação da SEFAZ
2. Verifique se todos os componentes da chave de acesso correspondem aos dados informados na NF-e
3. Confirme que a chave tem exatamente 44 dígitos numéricos, sem espaços ou caracteres especiais
4. Regenere a chave de acesso completa no seu sistema emissor e retransmita

Verificações analíticas#

• Se os dois primeiros dígitos da chave de acesso (posições 1-2) divergem do cUF informado no elemento ide/cUF, então a UF codificada na chave não corresponde à UF do emitente declarada no XML, indicando que a chave foi gerada com código de UF incorreto ou que o campo cUF foi alterado após a geração da chave: sincronize cUF com o código IBGE da UF do emitente e regenere toda a chave de acesso antes de retransmitir.
• Se o valor do campo ide/cNF (8 dígitos aleatórios, posições 36-43 da chave) não coincide com o segmento correspondente extraído da chave de acesso informada em infNFe/@Id, então houve dessincronização entre o código numérico gerado internamente e o que foi embutido na chave, o que compromete tanto o dígito verificador quanto a unicidade do documento: regenere cNF de forma consistente com a chave e recalcule o dígito verificador pela regra módulo 11 com pesos 2-9.
• Se a concatenação de cUF + AAMM(dhEmi) + CNPJ(emit) + mod + serie + nNF + tpEmis + cNF não totaliza exatamente 43 caracteres numéricos antes do dígito verificador, então a estrutura posicional da chave está corrompida, possivelmente por preenchimento sem zero-left-padding em campos como serie (3 dígitos), nNF (9 dígitos) ou cNF (8 dígitos): force padding com zeros à esquerda em cada componente conforme tamanho fixo da especificação técnica NT 2011.004.
• Se o campo emit/enderEmit/UF difere da UF implícita no cUF de ide e simultaneamente o cUF da chave de acesso corresponde à UF do endereço do emitente mas não ao cUF declarado em ide, então existe tripla inconsistência entre cUF, endereço e chave, sugerindo que a UF do emitente foi corrigida no endereço sem propagar a atualização ao campo ide/cUF e à chave: atualize ide/cUF para o código IBGE correto, ajuste emit/enderEmit/UF de forma consistente e regenere a chave integralmente.
• Se tpEmis for diferente de 1 (contingência) e a posição 35 da chave de acesso não refletir o valor numérico de tpEmis declarado em ide/tpEmis, então o tipo de emissão embutido na chave diverge do campo XML, invalidando o dígito verificador calculado e causando rejeição por incompatibilidade de componentes: atualize o byte de tpEmis na posição correta da chave antes de recalcular o dígito verificador módulo 11.