Voltar para o blog

NF-e

Rejeição 233 da NF-e e IE do destinatário não cadastrada

Atualizado em 9 de outubro de 2026

Blog ALRA
Capa ilustrada da ALRA: Rejeição 233 da NF-e e IE do destinatário não cadastrada.

Atualizado em 9 de outubro de 2026

Na autorização, a 233 indica IE do destinatário não localizada no cadastro da UF de destino. Compare IE e UF do XML com o estabelecimento comprador. Formato válido não comprova existência; corrija o dado ou regularize o cadastro, preservando o destinatário real.

Confira a mensagem completa: na consulta pública do DANFE Tipo 2, 233 trata de QR Code. Esse ramo adiante é distinto da autorização cadastral.

O que a SEFAZ verifica

Na autorização da NF-e, modelo 55, a regra 5E17-10 consulta o cadastro pela combinação UF do destinatário e IE informada. O MOC 7.0, Anexo I, página 137, e a NT 2019.001 v1.70, página 23, documentam essa verificação. Ela não equivale à 210, que trata de formato ou dígito da IE; à 234, que trata do vínculo com o CNPJ; nem à 306, relativa à inscrição não ativa. [1][2]

A NT 2021.002 v1.12 estabelece tratamento próprio para a Nota Fiscal Fácil: as verificações desse grupo são realizadas pelo aplicativo NFF em conjunto com seu portal, e essas regras não se aplicam à autorização de emissão ao abrigo da NFF, tpEmis=3. Isso não autoriza um emissor convencional a escolher NFF como atalho. No EPEC de NF-e, a regra correspondente é 6P31-10. A versão 1.41 da NT 2014.001 inclui expressamente a IE com exclusão lógica no CCC, cSitIE=9, entre as situações dessa rejeição. [3][4]

A ressalva (*7) para pessoa física ausente do CCC foi excluída da autorização 5E17-10: NT 2019.001 v1.70, pp. 4/11/23, e NT 2020.005 v1.21, p. 22. [2][9]

No EPEC, a NT 2014.001 v1.41 ainda reproduz a ressalva na 6P31-10. A NT 2019.001 risca a nota desse serviço, mas não cita 6P31-10 na lista de exclusões. Essa divergência não permite generalizar a exceção para autorização nem afirmar sua exclusão nessa regra do evento. Confirme o tratamento do EPEC com a SEFAZ; consulta vazia pede apuração, sem alterar o destinatário real. [2][4]

Diagnóstico em qualquer emissor

  1. Guarde o XML transmitido e a resposta completa. Anote modelo, ambiente, UF autorizadora, horário e se a falha ocorreu na autorização da nota ou no registro do EPEC.

  2. Confira dest/IE e dest/enderDest/UF. Preserve zeros pertencentes à inscrição; não transfira a IE do emitente, transportador ou endereço de entrega para o destinatário.

  3. Consulte o cadastro oficial da UF, utilizando os acessos do SINTEGRA ou do CCC. Pesquise o estabelecimento correto e compare IE, CNPJ ou CPF e situação cadastral.

  4. Verifique se houve alteração de filial, endereço ou inscrição. Uma ficha antiga pode continuar sendo reutilizada por pedidos, integrações ou documentos já preparados.

  5. Corrija apenas a divergência comprovada. Gere novamente o XML da nota rejeitada e confira o conteúdo antes de retransmitir.

Cadastro correto não garante XML atualizado: a nota pode conservar ficha antiga ou uma integração eliminar zero inicial. Compare o arquivo transmitido com a informação oficial e corrija a origem.

Exemplos para identificar a origem

IE de outro estado. Exemplo hipotético: um pedido destinado à unidade baiana carrega IE da unidade pernambucana. Recupere a inscrição comprovada do estabelecimento destinatário, mantendo a identidade real do comprador.

Cadastro recém-concedido. Preserve comprovante e consulta com horário; o destinatário deve verificar com a SEFAZ a divergência da base utilizada pelo autorizador. Não existe prazo nacional único de sincronização que permita prometer solução em horas.

Inscrição encontrada, mas sem atividade. Se a consulta mostra uma IE existente e não habilitada, não trate isso como simples inexistência. Releia o retorno e separe eventual 306 ou outro bloqueio. O destinatário pode precisar regularizar seu cadastro; editar a ficha no emissor não altera a base fiscal.

O que não resolve com segurança

Apagar a IE, preencher ISENTO ou mudar indIEDest para 9 somente para eliminar a mensagem pode gerar outra rejeição e declarar uma condição fiscal incorreta. O indicador deve representar a condição real do destinatário na operação. Se a classificação original estiver errada, a alteração precisa ser sustentada pelo cadastro e pela análise fiscal, e não pelo resultado desejado da transmissão.

Também não classifique toda irregularidade como denegação. A NT 2024.001 v1.20 substituiu o processo de denegação da NF-e modelo 55 por rejeição; referências antigas a denegação não descrevem automaticamente o processamento atual. Documentos históricos exigem leitura do protocolo que receberam. [5]

CNPJ alfanumérico não dispensa IE correta. A NT 2026.004 v1.01 prevê homologação até 15/06 e produção em 01/07/2026. A NT 2026.007 v1.10 previa 03/11, mas o aviso ENCAT de 05/10 adiou homologação para 26/10 e produção para 16/11/2026. Confira versão e ambiente; não antecipe regras futuras. [6][7]

Quando 233 aparece na consulta do QR Code

Na tabela de consulta pública da NT 2026.003 v1.00, página 25, o código 233 descreve ausência de DigestValue no QR Code da NF-e com DANFE Simplificado Tipo 2. A tabela usa a coluna Código, sem definir a tag cStat da autorização. O cronograma prevê testes em 01/07/2026 e produção em 03/08/2026; confirme a implantação da consulta. [8]

Há uma ressalva importante: os parâmetros da versão 3, nas páginas 19–20, não apresentam DigestValue como parâmetro separado. Portanto, essa mensagem não justifica acrescentar um hash ou DigestValue inventado à URL. Compare o QR impresso com o XML, versão, ambiente e endereço oficial de consulta; se forem coerentes, encaminhe a inconsistência documental e o retorno ao fornecedor e à SEFAZ. Alterar a IE não resolve esse ramo.

Código 233 na consulta pública da NFC-e modelo 65

No Manual DANFE NFC-e v6.0, 233 identifica ausência de DigestValue no QR. A tabela é de Código da consulta por chave ou QR, sem definir cStat de autorização. No leiaute v2 offline, confira se o sexto parâmetro foi preenchido a partir do DigestValue da assinatura do XML, com a conversão hexadecimal prevista no manual. Revise também os separadores e o hash correspondente. Manual v6.0, pp.22–24 e 38–40.

O QR v2 online e os leiautes v3 não possuem DigestValue avulso. A versão 3 offline usa assinatura dos parâmetros próprios. Nesses modos, não crie um campo para atender à mensagem legada; encaminhe ao integrador a versão, o modo, a URL e o retorno para conferir a implementação. Alterar a IE do destinatário não corrige esse ramo. NT 2025.001 v1.03, p.14.

Como confirmar a correção

Depois da retransmissão, leia o resultado da nota ou do evento, não apenas o recebimento do lote. A ausência da 233 não garante autorização: outra regra pode ser verificada em seguida. Arquive o XML final, o protocolo e a evidência cadastral utilizada. Se persistir, envie ao suporte a divergência objetiva entre XML e consulta oficial, protegendo dados pessoais e evitando compartilhar credenciais.

Referências e data da revisão

Fontes verificadas em 09/10/2026. Documentos oficiais prevalecem sobre simplificações dos guias operacionais.

  1. MOC 7.0 Anexo I, p. 137

  2. NT 2019.001 v1.70, pp. 4, 11 e 23–24

  3. NT 2021.002 v1.12, pp. 16–17

  4. NT 2014.001 v1.41, pp. 12–13

  5. NT 2024.001 v1.20, pp. 3–6

  6. NT 2026.004 v1.01, pp. 3–4

  7. NT 2026.007 v1.10, pp. 3–4 e 8–10

  8. NT 2026.003 v1.00, pp. 3 e 19–25

  9. NT 2020.005 v1.21, pp. 21–22

Guias práticos consultados: TecnoSpeed, Senior, CIGAM.

Pronto para dar o próximo passo?

Pronto para organizar sua empresa e ganhar mais tempo?

Teste grátis por 15 dias e descubra como a Alra pode transformar a gestão do seu negócio.