Rejeição 249: UF da chave de acesso diferente da UF autorizadora

A rejeição 249 indica que a UF identificada na chave de acesso diverge da UF autorizadora no serviço utilizado. Para corrigir, confira a chave do documento e o destino da solicitação, especialmente quando o retorno veio de um evento. Se a chave está correta, ajuste o encaminhamento. Não altere seus primeiros caracteres para fazê-la parecer pertencente a outro estado.

Uma chave identifica um documento específico. Trocar a UF dentro dela significa apontar para outra identificação, além de afetar sua validação. Quando a nota já está autorizada, um evento precisa conservar a referência ao documento verdadeiro.

O primeiro diagnóstico é descobrir qual operação falhou

O MOC 7.0, Visão Geral, páginas 103 e 106, apresenta o 249 na regra P12-40 de eventos, incluindo cancelamento. O campo investigado é a chave referenciada em evento/infEvento/chNFe. Nos leiautes de envio em lote, o caminho completo passa por envEvento/evento/infEvento/chNFe.

O mesmo número não deve ser atribuído automaticamente a qualquer chamada que use uma chave. Na consulta de protocolo, por exemplo, a regra J02 da página 83 do MOC relaciona a divergência de UF ao código 226. Por isso, informe ao suporte se estava autorizando, cancelando, registrando outro evento ou consultando a situação da nota.

A descrição genérica exibida pelo ERP pode esconder essa etapa. Recupere o retorno efetivo com cStat e xMotivo, junto do nome do serviço, horário, ambiente e XML da requisição.

O que os primeiros caracteres da chave representam

A identificação começa pelo código da UF do emitente. Essa informação é diferente da UF do destinatário e não muda porque a mercadoria foi vendida para outro estado. A UF também não deve ser deduzida do endereço do computador, do certificado ou da localização do servidor da Sefaz Virtual.

Confira a chave integral com a registrada no XML e no protocolo da nota. Em um evento, investigue se a integração selecionou o documento certo, em vez de apenas examinar o prefixo. Uma chave de outra nota da mesma empresa pode ter a UF esperada e continuar sendo uma referência incorreta.

As orientações da InvoiSys e da NS7 destacam a comparação do prefixo com o destino. Use essa pista respeitando o serviço concreto: ela não transforma toda divergência de consulta ou autorização em P12-40.

Exemplo: o evento seguiu a configuração de outra unidade

Uma empresa fictícia centraliza a emissão de várias filiais. A nota de uma unidade foi autorizada corretamente. Dias depois, uma solicitação de evento conserva sua chave, mas usa o serviço configurado para outra unidade federada, sem atendimento previsto à primeira.

A providência é corrigir a seleção do serviço para aquele evento e documento. Não se troca a chave da nota autorizada, a UF da filial ou o destinatário. Se somente o endereço técnico estava errado, preserve o conteúdo fiscal correto e verifique como o emissor retoma o envio.

Se a chave associada ao evento estava errada, recupere a referência correta na origem e gere novamente a mensagem pelo sistema. O identificador e a assinatura do evento também dependem de sua composição; não substitua trechos no XML assinado.

Há diferenças entre eventos e modelos

O 249 não se limita à emissão inicial de NF-e. A NT 2018.004, página 8, apresenta P12-40 no contexto de cancelamento e cancelamento por substituição de NFC-e. Já a NT 2020.007 v1.40, página 9, condiciona essa comparação, no evento de ator interessado da NF-e modelo 55, ao autor identificado como empresa emitente, tpAutor=1.

Não transfira essa condição particular para todos os eventos, nem elimine a condição quando tratar de ator interessado. Outros documentos técnicos também apresentam o código, como os de EPEC, comprovante de entrega e insucesso na entrega. A presença em uma tabela não torna todos os eventos disponíveis para os dois modelos.

O órgão de recepção, cOrgao, também não é sinônimo automático do prefixo da chave. Alguns eventos possuem encaminhamento ao Ambiente Nacional. O código de órgão previsto para esse destino não deve ser colocado na chave de acesso. Verifique o leiaute específico, o autor permitido e o serviço correspondente.

Exceção futura na SVRS: alcance limitado

A NT 2026.007 v1.10, página 11, altera P12-40 para o modelo 55, prevendo exceção na SVRS para contribuinte exclusivo do IBS/CBS, identificado nesse contexto pela ausência de emit/IE na NF-e vinculada à chave. Isso não autoriza retirar uma IE verdadeira nem editar uma nota já autorizada.

Embora o PDF mencione 03/11/2026 para produção, o aviso oficial de 05/10/2026 adiou a v1.10 para 26/10 em homologação e 16/11 em produção. Em 09/10/2026, a alteração continua futura para produção. Confira o ambiente e a versão em ocorrências posteriores; o aviso não demonstra ausência de todos os recursos anteriores em homologação.

A própria nota técnica traz regras específicas de recepção de eventos desse contribuinte. Não transforme essa mudança delimitada em permissão geral para enviar qualquer chave a qualquer autorizador virtual ou de contingência.

Confirme o resultado antes de repetir ou encerrar

Depois do ajuste, acompanhe a resposta individual do evento e sua vinculação à chave correta. O simples recebimento de um lote não prova que o efeito solicitado foi registrado. Um cancelamento rejeitado, por exemplo, não permite tratar a nota como cancelada.

Se uma tentativa anterior ficou sem resposta, verifique se o evento já foi registrado antes de insistir. Não crie outra nota para resolver uma falha de roteamento de evento. A Omie ressalta que a correção pode envolver configuração e estrutura do XML; encaminhar ambos ao suporte ajuda a localizar a causa sem alterações fiscais por tentativa.

Referência de atualização: 09/10/2026. Aplicar ao evento, modelo, autor, versão, UF e ambiente pertinentes.