Rejeição 522: UF inválida na chave do CT-e referenciado

A Rejeição 522 da BA19-14 aparece quando a chave informada em refCTe contém um código de UF inválido. É uma verificação facultativa do serviço de autorização da NF-e modelo 55 sobre o CT-e referenciado.

Onde fica a UF examinada?

O campo /NFe/infNFe/ide/NFref/refCTe contém a chave de 44 posições. Suas duas primeiras posições identificam o código da UF do documento referenciado. Esse trecho não é a sigla de duas letras e não representa automaticamente a UF do destinatário ou o local da entrega da NF-e atual.

A tabela oficial usa códigos como 35 para São Paulo e 41 para Paraná. O objetivo é identificar um código existente, não exigir que a chave do CT-e comece com o código da empresa que está emitindo a NF-e.

Fontes: MOC — Anexo I, Leiaute e Regras de Validação, Leiaute da NF-e e protocolo, Manual de Orientação ao Contribuinte - MOC - versão 7.0 - NF-e e NFC-e

Quando a própria referência é vedada?

A BA01-10 da NT 2026.002 v1.11 veda NFref em NFC-e e em NF-e com DANFE Simplificado Tipo 2 (tpImp=6). Portanto, o alcance modelo 55 da BA19-14 não libera indiscriminadamente refCTe nesse tipo de impressão. A regra de referência precisa ser lida junto com a condição do documento atual.

Antes de corrigir um componente da chave, confira modelo e tipo de impressão verdadeiros. Não altere esses indicadores nem apague um vínculo documental necessário apenas para evitar uma rejeição. Confirme o procedimento cabível quando o contexto da emissão estiver em dúvida; o calendário documental não comprova implantação individual do autorizador.

Fontes: NT 2026.002 — DANFE Tipo 2 e autorização com alertas, MOC — Anexo I, Leiaute e Regras de Validação

Como localizar a causa da referência inválida

Compare a chave inteira com o CT-e original antes de isolar a UF. Uma leitura iniciada no segundo caractere, perda de posição na importação ou substituição da chave por outro identificador pode produzir um prefixo inválido. Examine também o tamanho e a preservação dos caracteres; a adequação alfanumérica não altera a função das duas primeiras posições.

Se houver várias referências e o retorno indicar nOcor, correlacione essa ocorrência com a ordem dos grupos NFref. Não corrija a primeira referência por suposição quando a mensagem apontar outra.

Fontes: MOC — Anexo I, Leiaute e Regras de Validação, Leiaute da NF-e e protocolo, NT 2026.004 CNPJ alfanumérico

Exemplos: UF inválida e UF diferente

Cenário sintético A: o sistema extrai um prefixo que não existe na tabela de UFs, enquanto o CT-e original começa com 41. A comparação revela erro no conteúdo importado; deve-se recuperar a chave original completa.

Cenário B: uma empresa paulista referencia um CT-e cujo prefixo é 41. O prefixo representa Paraná e, isoladamente, essa diferença não satisfaz a condição de UF inválida da BA19-14. A relação documental e as demais regras continuam dependendo da operação e dos documentos verdadeiros.

Fontes: MOC — Anexo I, Leiaute e Regras de Validação, Manual de Orientação ao Contribuinte - MOC - versão 7.0 - NF-e e NFC-e

Qual correção é segura?

Corrija o vínculo ou a importação comprovadamente incorretos e regenere o XML pelo emissor. Não troque somente as duas primeiras posições pela UF da empresa: isso altera a identidade e o DV do CT-e.

Se o valor enviado coincide integralmente com o original, preserve retorno, ocorrência, ambiente e autorizador para análise técnica. Esta regra difere das rejeições que comparam a UF do emitente com o Web Service. Antes de retransmitir, esclareça qualquer tentativa sem conclusão e confira o resultado individual da nova validação.

Fontes: MOC — Anexo I, Leiaute e Regras de Validação, Manual de Orientação ao Contribuinte - MOC - versão 7.0 - NF-e e NFC-e