Rejeição 264 — Sigla da UF da consulta difere da UF do Web Service

O que é esta rejeição?#

A Rejeição 264 é retornada pela SEFAZ durante a validação da NF-e quando há uma inconsistência relacionada a unidade federativa do contribuinte. 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: CPF da consulta não cadastrado como contribuinte na UF.

Os campos afetados estão na seção de dados do destinatário, dados do emitente, 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 código da UF não corresponde ao estado do emitente ou destinatário
• O código do município (IBGE) é inválido ou não pertence à UF informada
• A UF informada na chave de acesso diverge da UF do emitente

Como resolver#

1. Verifique se o código da UF está correto conforme a tabela do IBGE (ex: 35=SP, 33=RJ, 41=PR)
2. Confirme que o código do município (7 dígitos IBGE) pertence à UF informada
3. Atualize os dados de endereço do emitente e destinatário no sistema emissor

Verificações analíticas#

• Se o primeiro dígito da chave de acesso (cUF) diverge do código de UF extraído do campo emit/enderEmit/UF (tabela IBGE: AC=12, AL=27, AP=16, AM=13, BA=29, CE=23, DF=53, ES=32, GO=52, MA=21, MT=51, MS=50, MG=31, PA=15, PB=25, PR=41, PE=26, PI=22, RJ=33, RN=24, RS=43, RO=11, RR=14, SC=42, SP=35, SE=28, TO=17) então a chave de acesso foi gerada com UF incorreta e o XML está sendo roteado para o WebService errado: recalcule o cUF com base na UF real do emitente e regenere a chave de acesso antes de retransmitir.
• Se o campo emit/enderEmit/cMun (código IBGE de 7 dígitos) não inicia com os dois dígitos correspondentes à UF declarada em emit/enderEmit/UF (ex: município com cMun começando em '35' mas UF='RJ') então o município informado não pertence à UF do emitente, causando divergência de jurisdição no roteamento SEFAZ: corrija o cMun para o código IBGE oficial do município real do emitente garantindo que os dois primeiros dígitos coincidam com o cUF da UF do emitente.
• Se o campo ide/cMunFG (município do fato gerador) possui dois primeiros dígitos divergentes tanto do cUF na chave de acesso quanto da UF do emitente em emit/enderEmit/UF então o fato gerador está apontando para uma UF diferente da autoridade fiscal competente: atualize cMunFG com o código IBGE correto do município onde ocorreu a saída ou prestação, garantindo consistência com a UF do emitente.
• Se ide/idDest=2 (operação interestadual) mas emit/enderEmit/UF é igual a dest/enderDest/UF então há contradição entre o indicador de destinação e as UFs das partes, e além disso o CFOP informado nos itens provavelmente inicia com dígito 6 (saída interestadual) conflitando com endereços na mesma UF: verifique se a UF do destinatário está correta ou corrija idDest para 1 e ajuste os CFOPs para a série 5, pois essa inconsistência pode provocar roteamento indevido ao WebService de outra UF.
• Se tpEmis diferente de 1 (contingência SCAN, DPEC, FS-DA ou SVC) e o endpoint WebService utilizado na transmissão pertence a uma UF diferente da UF do emitente extraída do cUF da chave de acesso então o sistema emissor está utilizando o endereço de contingência de UF alheia sem que haja registro de evento de contingência justificado: force o retorno ao WebService titular da UF do emitente (conforme cUF) ou registre corretamente o evento de entrada em contingência com dhCont e xJust antes de retransmitir.