NF-e e NFC-e
Rejeição 226: código da UF do emitente diverge da UF autorizadora
A rejeição 226 pede uma conferência conjunta da mensagem enviada e do destino. Na autorização, a comparação envolve o código da UF do emitente; na consulta de protocolo, envolve a UF da chave consultada. Se os dados fiscais estão corretos, a solução pode ser exclusivamente ajustar o roteamento do emissor. Não troque…
A rejeição 226 pede uma conferência conjunta da mensagem enviada e do destino. Na autorização, a comparação envolve o código da UF do emitente; na consulta de protocolo, envolve a UF da chave consultada. Se os dados fiscais estão corretos, a solução pode ser exclusivamente ajustar o roteamento do emissor. Não troque a UF real do estabelecimento para fazer a nota passar.
Regra oficial e mudança prevista
O MOC 7.0, Anexo I, apresenta B02-10 como regra obrigatória para NF-e e NFC-e, modelos 55 e 65. Ela confronta o código da UF do emitente com a UF do Web Service. O campo de identificação relevante é ide/cUF. A sigla do endereço do emitente é outra informação, e sua divergência aparece em validação própria. [1]
A NT 2026.007 v1.10 mantém o 226 e acrescenta uma exceção na SVRS para NF-e modelo 55 sem IE do emitente, no contexto de contribuinte exclusivo do IBS/CBS. A exceção não abrange automaticamente NFC-e, outros autorizadores ou um contribuinte de ICMS que apague sua inscrição. [2]
O PDF previa 03/11/2026 para produção, mas o comunicado 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 exceção permanece futura em produção. Confira a implantação do autorizador nas ocorrências posteriores. O adiamento não comprova ausência de recursos da v1.00 em homologação, cujo cronograma previa 01/09/2026; versão, publicação e ativação são informações diferentes. [2][3]
Se o 226 apareceu na consulta da situação da nota
No serviço NfeConsultaProtocolo, J02 compara a UF da chave consultada com a UF do Web Service. O campo é consSitNFe/chNFe, e não um novo preenchimento de ide/cUF. O MOC, Visão Geral, páginas 82 e 83, documenta esse ramo, com chaves dos modelos 55 e 65 conforme as validações pertinentes. [5]
Uma integração pode consultar uma nota de fornecedor usando, por engano, o destino da própria empresa. Confira a chave integral, o serviço que atende o documento e o ambiente, respeitando os autorizadores virtuais. Corrija o encaminhamento ou a chave digitada incorretamente, sem adulterar a identificação verdadeira.
O retorno rejeita a consulta; sozinho, não demonstra que a nota original foi rejeitada, cancelada ou deixou de existir. A exceção futura da NT 2026.007 para B02-10 não deve ser transportada automaticamente para J02. Tampouco se deve substituir esse diagnóstico por 249, usado em regras de eventos.
Dados necessários para localizar a causa
Separe a mensagem transmitida, a resposta com cStat e xMotivo, a URL e o horário da tentativa. Na autorização, inclua o XML assinado da nota. Registre também modelo, tpAmb, tpEmis, estabelecimento selecionado e versão da integração. O atendimento técnico precisa saber se o envio ocorreu em produção ou homologação e se havia contingência oficialmente ativada.
No XML da nota, confronte ide/cUF, emit/enderEmit/UF e a identificação do estabelecimento com o cadastro fiscal verdadeiro. Depois compare a configuração do emissor com a relação oficial de Web Services e de autorizadores. O mesmo fornecedor de ERP pode atender empresas de diversas UFs, mas cada solicitação precisa seguir o destino aplicável. [4]
Uma Sefaz Virtual presta serviço para outras unidades federadas. O fato de o servidor estar ligado ao Rio Grande do Sul não transforma a UF do emitente em RS. Use a relação oficial de atendimento; não deduza o código fiscal pela sigla encontrada no domínio ou no nome da infraestrutura.
Cenário 1: filial correta, endereço de envio errado
Uma distribuidora fictícia de Goiás gera a nota com cUF 52, correspondente ao estabelecimento real. Após a migração, a integração reaproveita o destino configurado para outra filial. O XML chega a um serviço que não atende aquela UF naquela modalidade.
A correção é rever o roteamento por estabelecimento, modelo, ambiente e tipo de emissão. Se o conteúdo fiscal não mudou, não há razão para alterar cUF, a chave ou a data. O suporte deve confirmar o endereço na relação oficial e testar a configuração apropriada, mantendo uma trilha do que foi modificado.
Cenário 2: cadastro importado gerou cUF incorreto
Uma empresa possui unidades em estados diferentes. Na importação, o sistema associou à nota de uma unidade o código de UF de outra. Aqui o problema está no conteúdo, mesmo que a URL selecionada esteja correta.
Corrija o cadastro de origem e gere novamente a nota rejeitada pelo fluxo do emissor. Confirme se o documento não conservou uma cópia antiga dos dados. O código de UF integra a chave de acesso: quando sua correção é legítima, o sistema precisa recompor a chave, recalcular cDV, atualizar Id e produzir assinatura compatível. Não edite somente os primeiros caracteres da chave ou somente a tag cUF. [5]
A mudança de chave também exige verificar protocolos, vínculos e tentativas anteriores. Se houver documento autorizado, o tratamento deixa de ser uma simples edição de nota rejeitada e deve seguir o procedimento fiscal apropriado ao caso.
Cenário 3: confusão entre autorização normal e contingência
Trocar a URL por um serviço de contingência sem observar a modalidade, a disponibilidade e a UF atendida não é uma solução genérica. O serviço de contingência precisa estar disponível para aquela situação, e o XML deve representar a modalidade efetivamente utilizada.
Ao retornar da contingência, revise o destino de envio com o suporte. Nunca altere a UF do estabelecimento para acompanhar a localização do servidor de contingência. A NFC-e não é autorizada pela SVC. [1]
O que não resolve o 226
Ajustar relógio, fuso ou data de emissão sem evidência de erro nesses dados
Trocar certificado para tentar mudar a UF fiscal da nota
Copiar cUF de uma nota autorizada de outra empresa
Remover a IE para tentar antecipar a exceção da NT 2026.007
Reenviar continuamente para vários estados até obter uma resposta diferente
TecnoSpeed, Omie e InvoiSys oferecem orientações úteis para localizar a divergência entre cUF, configuração e destino. Entretanto, exemplos de CT-e ou MDF-e e nomes de campos específicos desses produtos não devem ser aplicados ao XML de NF-e. Na autorização, a referência é B02-10 dos modelos 55 e 65; na consulta de protocolo, é J02. [5][6][7][8]
Confirmação do resultado
Antes de repetir, apure tentativas anteriores sem resposta para evitar duplicidade. Depois do ajuste, confira a URL e a mensagem efetivamente enviadas. Na autorização, leia o resultado individual e arquive o protocolo com o XML autorizado. Na consulta, leia a situação retornada para a chave correta. Comunicação concluída ou lote processado não prova autorização.
Se o 226 persistir com dados e destino comprovadamente corretos, envie ao suporte o conjunto de evidências, a versão da aplicação e a referência da regra. O objetivo é localizar a divergência real, mantendo o estabelecimento e a operação representados corretamente.
Referências e revisão
Revisão técnica: 09/10/2026. Exemplos originais e fictícios.