Rejeição 232: IE do destinatário não informada

A rejeição 232 exige investigar por que a inscrição estadual do destinatário ficou ausente quando o cadastro fiscal indica que ela deve ser informada. A correção começa pela identificação exata do cliente e por uma consulta oficial. Depois, atualize os dados verdadeiros no cadastro e no XML da nota rejeitada.

Não marque o cliente como isento ou não contribuinte apenas para tentar emitir. Também não inclua uma inscrição encontrada por nome parecido. O conjunto CNPJ, estabelecimento, UF, IE e enquadramento fiscal precisa permanecer coerente com a operação real.

A condição completa da regra

Na autorização da NF-e modelo 55, a regra 5E17-50 se aplica quando não foi informada a IE e existe CNPJ do destinatário. A consulta usa a UF e esse CNPJ. O retorno 232 está associado à existência de IE ativa, CCC.cSitIE=1, com indicação de preenchimento obrigatório, CCC.IndIEDestOpc=0. Não basta resumir a regra como “qualquer cliente com IE deve sempre informá-la”. [1]

O MOC e a NT 2019.001 determinam pesquisar todas as inscrições vinculadas ao CNPJ informado. Também preveem a utilização do CCC nas operações interestaduais ou no ambiente da Sefaz Virtual. Uma consulta que encontre mais de um registro precisa ser analisada com atenção; a primeira inscrição exibida não é automaticamente a correta para aquela operação. [1][2]

A NT 2021.002 v1.12 acrescenta a exceção da Nota Fiscal Fácil, tpEmis=3, porque o aplicativo e o Portal Nacional da NFF realizam as verificações cadastrais pertinentes. Essa exceção específica não é uma alternativa para contornar a rejeição em outro emissor. [3]

No EPEC da NF-e modelo 55, a regra correspondente é 6P31-50, documentada na NT 2014.001 v1.41 e na NT 2019.001 v1.70. Ela mantém as condições de CNPJ informado, IE ausente, inscrição ativa e indicador de obrigatoriedade. O evento e a NF-e devem ser diagnosticados separadamente. O EPEC da NF-e tem impedimento documentado para PR e PB desde 05/10/2026 em produção. [2][4]

Não confunda 232 com 728

O código 728 está ligado à declaração de destinatário contribuinte do ICMS, indIEDest=1, sem a tag IE. O 232 envolve a consulta cadastral descrita acima. Uma falta de preenchimento pode aparecer em etapas diferentes da validação, mas isso não torna os dois códigos sinônimos. [1]

Outras distinções úteis: 210 trata de IE inválida; 233, de inscrição não cadastrada; 234, de falta de vínculo ao CNPJ; e 306, de inscrição não ativa na UF. Incluir uma IE sem conferir titularidade e situação pode apenas revelar um desses problemas no envio seguinte.

O que conferir no XML e no cadastro

Separe o retorno completo e o XML efetivamente enviado. Identifique modelo, ambiente, serviço e data. No grupo dest, confira CNPJ, enderDest/UF, indIEDest e IE. Compare também a unidade compradora indicada no pedido e na documentação comercial.

O indicador indIEDest distingue contribuinte do ICMS, contribuinte isento de inscrição e não contribuinte. O MOC admite que um não contribuinte possa ter IE. Portanto, possuir inscrição não autoriza, isoladamente, mudar todo cliente para indIEDest=1. O indicador precisa acompanhar sua condição fiscal real, confirmada pelo responsável fiscal. [1]

Consulte o cadastro estadual ou o CCC para o estabelecimento exato. Solicite ao destinatário confirmação quando houver dúvida e registre a fonte e a data. A situação do CNPJ na Receita Federal não comprova qual IE deve constar na nota. Evite usar informações de pedidos antigos como única evidência.

Cenários de diagnóstico

A importação do cliente trouxe apenas o CNPJ

Uma fornecedora fictícia importou o cadastro de um comprador sem sua inscrição estadual. A NF-e foi preparada com CNPJ correto, mas sem dest/IE. O cadastro fiscal informa uma inscrição ativa com preenchimento obrigatório, e o autorizador retorna 232.

Confira o número oficial, sua associação ao estabelecimento e o enquadramento do destinatário. Atualize o cadastro e a nota em aberto; em seguida, gere novamente o XML. Não basta gravar a informação no cadastro se o documento continua preservando o conteúdo anterior.

O comprador informou os dados de outra unidade

O pedido menciona uma filial, mas o cadastro usado na emissão corresponde à matriz. A consulta pelo CNPJ transmitido retorna uma inscrição que não coincide com os documentos do pedido.

Primeiro confirme quem é o destinatário real. Se o CNPJ está errado, corrija a identificação conforme os fatos antes de selecionar uma IE. Se o CNPJ está certo, não o substitua pelo de outra unidade apenas porque você já possui a inscrição dela. A correção deve resolver a identidade comercial e fiscal, não somente preencher o campo vazio.

A consulta mostra vários registros

Um destinatário possui mais de uma inscrição vinculada ao CNPJ consultado. Verifique UF, situação, tipo do registro e orientação cadastral aplicável. A regra exige pesquisar todas as inscrições; isso não significa informar qualquer uma delas ou escolher a primeira ativa sem confirmar pertinência.

Quando houver regime especial ou divergência entre cadastro estadual e CCC, envolva o responsável fiscal e a Sefaz. Guarde as consultas para demonstrar a inconsistência. Não existe um prazo nacional único de atualização que possa ser prometido para todos os casos.

A correção não chegou ao EPEC

O XML da NF-e já contém a IE correta, mas o resumo do EPEC foi montado com dados antigos. Se o 232 veio do evento, atualize sua origem de dados e confira o destinatário do EPEC. Um evento registrado não substitui a autorização posterior da NF-e, que continua sujeita às próprias validações.

E na NFC-e?

Os ramos 5E17-50 e 6P31-50 examinados são de modelo 55. Não aplique automaticamente esta solução a uma NFC-e modelo 65 só porque o aplicativo mostra uma lista genérica de rejeições.

No leiaute do MOC, a NFC-e utiliza indIEDest=9 e não informa a IE do destinatário. Se o retorno parecer incompatível com esse modelo, confira o XML, o serviço e o texto original com o suporte antes de acrescentar dest/IE. Também não altere o modelo do documento apenas para escapar da validação. [1]

Verifique o resultado e previna novas ocorrências

Após corrigir os fatos e atualizar o documento rejeitado, gere o XML pelo emissor, confira o conteúdo e retransmita. Se o arquivo foi alterado, sua assinatura deve ser produzida novamente pelo fluxo adequado. Leia o novo retorno até confirmar a autorização da chave correta; o desaparecimento do 232 não garante que todas as validações passaram.

Para prevenir repetição, registre a fonte da informação cadastral, revise cadastros alterados e confira se integrações levam a IE à nota. Não use “ISENTO”, IE de terceiro ou alteração fictícia de indIEDest como solução. Se o cadastro oficial contradiz a rejeição, encaminhe à Sefaz as evidências e o retorno, evitando reenvios sucessivos sem mudança.

Fontes e revisão

Revisão e acesso: 09/10/2026.

1. MOC 7.0 Anexo I, p. 15, 86, 87, 137

2. Nota Técnica 2019.001.v.1.70, p. 23, 24

3. Nota Técnica 2021.002 - Nota Fiscal Fácil (v1.12), p. 16, 17

4. Nota Técnica 2014.001 v.1.41, p. 4, 12, 13

Conferência prática: Treeunfe, CIGAM, Mainô. As regras oficiais prevalecem.