Rejeição 332: confira o CNPJ ou CPF do terceiro na importação

Atualizado em 10/10/2026

A rejeição 332 indica problema na identificação do adquirente ou encomendante informada no grupo de importação da NF-e. A descrição atual contempla CNPJ e CPF. O diagnóstico começa pelo XML enviado, porque a identidade correta no cadastro pode ter sido alterada, truncada ou associada ao campo errado durante a geração do documento.

Não troque o participante por um número que passe na validação. O objetivo é transmitir a identificação verdadeira, no campo correto e sem perda de caracteres. Também não remova o dado sem conferir a modalidade: em conta e ordem ou encomenda, a ausência pode provocar a rejeição 331.

Duas regras diferentes retornam o mesmo código

A NT 2023.004 v1.20, página 13, separa o controle em dois ramos:

• I23d-20: se informado CNPJ do adquirente ou encomendante, verifica identificação inválida por zeros, nulo ou dígito verificador inválido

• I23d1-10: se informado CPF do adquirente ou encomendante, faz a verificação correspondente para CPF

Ambas são regras obrigatórias da autorização de NF-e modelo 55 e retornam 332. A segunda foi criada quando o CPF passou a ter campo próprio. O MOC anterior e diversos artigos antigos apresentam apenas o ramo de CNPJ.

A pesquisa não identificou outro significado de cStat 332 em eventos, consultas ou autorização de NFC-e no corpus examinado. Não confunda a numeração de campos das tabelas com códigos de retorno.

Identificação inválida não é sinônimo de irregularidade cadastral

A redação das regras trata do conteúdo da identificação. Ela não descreve uma consulta de situação fiscal, habilitação no Siscomex ou inscrição estadual no Cadastro Centralizado de Contribuintes.

Um CNPJ pode ter estrutura válida e pertencer à empresa errada. Inversamente, uma pessoa cadastrada regularmente pode ter seu CPF transmitido sem um zero inicial. A conferência deve verificar tanto a identidade do participante quanto a integridade do conteúdo enviado, sem atribuir à rejeição conclusões que ela não fornece.

A NS Tecnologia situa o problema no CNPJ dentro de DI. Utilize essa localização, acrescentando a alternativa CPF da NT. Não comece alterando o CNPJ do emitente ou do destinatário apenas porque existem campos com o mesmo nome no arquivo.

Confira cada etapa entre o documento e o XML

Reúna o cadastro comprovado do adquirente ou encomendante, os dados da importação e a tentativa rejeitada. Localize det/prod/DI/CNPJ ou det/prod/DI/CPF e faça a comparação com o original.

Verifique especialmente:

• Troca de caracteres na digitação ou cópia

• Zero inicial perdido ao armazenar o documento como número

• Máscara de apresentação levada indevidamente ao XML

• CPF colocado na alternativa destinada a CNPJ

• Campo preenchido somente com zeros para contornar ausência de cadastro

• Identificação de outro estabelecimento ou de outro participante da operação

• Rotina antiga que rejeita ou apaga letras de um CNPJ alfanumérico

Os validadores do emissor devem aplicar o padrão oficial correspondente. Se o cálculo de dígito verificador falha, recupere a identificação correta; não altere os últimos caracteres por tentativa. A validação matemática ajuda a encontrar erro de transmissão, mas não demonstra que aquela pessoa é a adquirente ou encomendante real.

CNPJ alfanumérico já faz parte da conferência

A NT 2026.004 v1.01, página 7, transforma DI/CNPJ em campo caractere de 14 posições. A NT Conjunta DFe 2025.001 complementa as regras de formação e cálculo do dígito verificador.

A Receita Federal confirmou a geração do primeiro CNPJ alfanumérico em 31/07/2026, com introdução gradual de novas inscrições nesse formato. Cadastros numéricos anteriores permanecem válidos.

Portanto, não aplique a orientação genérica de retirar tudo o que não for algarismo. A rotina precisa diferenciar pontuação de apresentação e letras integrantes da identificação. CPF continua sendo CPF; a alteração do CNPJ não muda o tamanho nem o cálculo de validação da pessoa física.

O cronograma do schema NF-e dessa NT indicava produção em 01/07/2026. Essa data de adaptação técnica é distinta da primeira inscrição efetivamente gerada pela Receita. Ao investigar falhas, registre a versão instalada e o ambiente, sem supor que todos os componentes do ERP foram atualizados juntos.

Quando a exclusão do campo é uma orientação perigosa

Um artigo da TOTVS para Protheus identifica o complemento de importação e o campo CD5_CNPJAE. Essa localização pode ajudar usuários da versão indicada, mas a sugestão de omitir CNPJ não deve ser generalizada.

Com tpIntermedio igual a 2 ou 3, a I23d-10 exige identificação do terceiro. Apagar um CNPJ inválido sem fornecer a identidade correta pode apenas trocar 332 por 331. Não mude parâmetros de integração ou a modalidade fiscal sem entender a origem do dado.

A Berga também orienta conferir a modalidade. Se a operação for realmente por conta própria e houver dados de terceiro incluídos por engano, avalie com a área fiscal a retirada do preenchimento indevido. O gatilho de 332 é a identificação informada; ele não se restringe, no texto da regra, aos casos 2 e 3.

Como encerrar a correção

Considere uma situação fictícia em que a identificação está correta no cadastro, mas perde uma letra na exportação. Corrigir a tela repetidamente não muda o resultado. O suporte deve reparar o mapeamento, gerar novo XML e demonstrar que as 14 posições chegaram intactas ao campo CNPJ.

Antes de retransmitir, confira também a UF do mesmo participante e todas as ocorrências de DI nos itens. A estrutura do grupo contempla DI, DSI, DIRE e DUImp; a troca do documento aduaneiro não elimina a identificação aplicável.

Após o envio, verifique a situação da NF-e e guarde o protocolo. Se a rejeição persistir com o conteúdo correto, encaminhe ao suporte o retorno integral, a ocorrência afetada, UF, ambiente e versões usadas. Não exponha documentos pessoais em fóruns públicos. A solução fica demonstrada pelo XML consistente e pelo processamento confirmado, sem substituir a análise fiscal da operação.