Rejeição 614: confira a UF dentro da chave de acesso

A rejeição 614, “Chave de Acesso inválida (Código UF inválido)”, aponta um problema no código de estado contido na chave enviada. A providência inicial é recuperar a chave completa do documento correto e comparar o valor transmitido. Alterar o estado do cliente ou o endereço fiscal da empresa por tentativa não resolve essa validação.

A mensagem aparece em consulta de situação, distribuição por chave e contratos de eventos. Sozinha, não demonstra que a emissão da nota foi recusada. Primeiro identifique qual mensagem foi rejeitada e qual chave ela transportava.

UF inválida é diferente de UF divergente

As duas primeiras posições da chave identificam a UF segundo a codificação adotada pelo projeto NF-e. São códigos específicos, não qualquer número dentro de um intervalo. Por exemplo, 31 representa Minas Gerais e 43 representa Rio Grande do Sul; ambos são códigos válidos.

Enviar uma chave mineira ao serviço inadequado não torna 31 um código inexistente. Esse problema de encaminhamento tem validações próprias. No NfeConsultaProtocolo, J02/226 compara a UF da chave com a do Web Service; J02b/614 verifica a validade do código. Nos eventos, há distinção semelhante entre 249 e 614.

Outra conferência, ligada a 250, envolve o órgão receptor informado em cOrgao. Códigos de órgão como 91 ou 92, quando previstos pelo contrato, não devem ser copiados para o início da chave. A identidade do documento e o destino da mensagem exercem funções distintas.

Onde o retorno pode surgir

O MOC 7.0, Visão Geral, documenta três caminhos relevantes:

• Consulta de situação: J02b, página 83, avalia chNFe da solicitação; o contrato contempla modelos 55 e 65

• Distribuição de documentos: H08 com nota de rodapé 2, página 96, aplica-se a consChNFe; não é uma conferência do NSU e o serviço documenta NF-e modelo 55

• Recepção de eventos: P12-14, página 103, verifica a chave vinculada ao evento, respeitando o tipo de evento e suas condições

A NT 2014.002 v1.40, página 11, confirma o recorte consChNFe. Não atribua uma rejeição de chave ao pedido distNSU apenas porque ambos aparecem no módulo de documentos recebidos.

Cada evento tem seu próprio contexto

A família P12-14 está presente em EPEC da NF-e, manifestação do destinatário, comprovante de entrega, insucesso de entrega e ECONF, entre outros contratos. Prorrogação de industrialização usa a identificação P11 para a mesma conferência. Eventos de visto eletrônico do Fisco também possuem a validação, mas isso não os torna uma operação que qualquer contribuinte possa executar.

Há cenários de modelo 65, como EPEC NFC-e e cancelamento por substituição, com condições próprias. A existência da regra não demonstra disponibilidade de EPEC em todas as UFs nem autoriza qualquer perfil de emitente. No evento Ator Interessado, a NT 2020.007 v1.40 limita as regras marcadas com a nota correspondente a tpAutor=1, empresa emitente. Não estenda essa aplicação automaticamente aos demais autores.

No cancelamento por substituição, diferencie chNFe, no cabeçalho de identificação do evento, de chNFeRef, que identifica a substituta. A NT 2018.004 usa 614 na primeira chave; a validação da UF da substituta integra o código 910. Trocar as duas referências pode alterar o documento atingido.

Roteiro para corrigir

1. Preserve a mensagem completa. Guarde código, motivo, ambiente, horário e identificação do serviço. Em evento, inclua tpEvento, autor e chave vinculada.

2. Localize o documento de origem. Prefira XML e protocolo preservados, conferindo emitente, modelo, série e número. Se só houver imagem ou DANFE, procure também o arquivo eletrônico.

3. Compare a chave inteira. Verifique perda de caracteres, espaços, reconhecimento incorreto de imagem ou conversão em número por planilha. O problema pode ser um deslocamento de todos os componentes.

4. Corrija a chave da solicitação ainda rejeitada a partir da fonte autêntica. Na consulta ou distribuição, recupere o parâmetro correto. Em evento, deixe o sistema regenerar a mensagem e sua assinatura quando necessária.

5. Confira separadamente a rota e o ambiente. Se ambos estiverem incorretos, ajustar somente o código da UF dentro da chave pode mascarar o problema.

6. Refaça a operação necessária e leia o resultado final. Para eventos, o processamento do lote não comprova aceitação individual.

Não transforme uma chave inválida em outra aparentemente válida substituindo apenas seus dois primeiros caracteres. Não edite o XML autorizado que serviu de origem. A correção deve restabelecer a identificação original, sem inventar um documento diferente.

Exemplo: importação de notas recebidas

Uma empresa paulista quer consultar uma compra de fornecedor paranaense. A integração trouxe uma chave iniciada por 54, inexistente na tabela de UF. O responsável deve comparar o registro importado com o XML da compra.

Se o XML correto começa por 41, a solução é recuperar toda a chave desse documento e corrigir o vínculo da consulta. Não se usa 35 apenas porque a empresa compradora está em São Paulo. Se outra nota foi selecionada na importação, mudar só o início conservaria um vínculo errado.

Caso a chave enviada já corresponda integralmente à original, peça ao suporte a requisição efetivamente transmitida. Uma tela correta não exclui falha na montagem da mensagem ou no processamento de um lote antigo.

O que não confundir com 614

A rejeição 522 trata da UF de chave referenciada durante autorização, em campos e modelos próprios. A 502 compara a composição do Id com o XML. A 572 trata do identificador do evento. Esses diagnósticos não são substitutos para a validação de chNFe aqui examinada.

Cabeçalhos SOAP antigos também exigem cautela: a versão 4.00 retirou variáveis de cabeçalho nos serviços migrados. Não recrie esse cabeçalho para corrigir a UF da chave. Contratos específicos devem ser verificados individualmente.

As consultas públicas por QR Code têm validações próprias, tanto na NFC-e quanto no DANFE Simplificado Tipo 2. O código desta página não deve ser transplantado para elas. Chaves continuam tendo 44 posições, mas a adaptação ao CNPJ alfanumérico exige conservar caracteres: remover letras pode corromper o arquivo importado.

Fontes e escopo

Base oficial preservada: MOC 7.0; NT 2014.002 v1.40; contratos específicos de eventos; NT 2026.004 v1.01. Revisão em 10/10/2026, sem certificar ativação em cada UF e ambiente.

Apoio lido: Oobj e Berga, dedicados ao código; Invoisys, como contexto de recuperação da chave consultada. O exemplo prático que confunde UF válida divergente com código inválido não foi adotado.