Rejeição 332 na I23d-20: CNPJ do terceiro inválido
Revisão editorial em 15 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.
A Rejeição 332, na regra I23d-20, verifica o CNPJ do adquirente ou encomendante informado no grupo DI da NF-e modelo 55. A NT 2023.004 v1.20 descreve CNPJ inválido por zeros, nulo ou dígito verificador inválido. Embora a mensagem atual mencione CNPJ/CPF, o CPF é tratado por outra regra, I23d1-10, que utiliza o mesmo código 332.
Por que o código isolado não basta
Confirme qual campo foi enviado: det/prod/DI/CNPJ ou DI/CPF. Na I23d-20, o teste se aplica quando foi informado CNPJ. Não use o algoritmo de CNPJ para validar CPF, nem trate um CPF legítimo como CNPJ incompleto. O tipo de pessoa e o papel de adquirente/encomendante precisam estar comprovados.
A 331 verifica falta de identificação para tpIntermedio=2 ou 3. A 332 verifica a validade do identificador informado. Assim, preencher um campo com zeros pode trocar a mensagem sem resolver o problema. A 333, por sua vez, trata a UF do terceiro, não o dígito do documento.
O que muda com o CNPJ alfanumérico
A NT 2026.004 v1.01 atualiza o campo CNPJ do grupo DI para conteúdo alfanumérico de 14 posições, com adaptação de schema prevista em produção em 01/07/2026. A formação e a validação são detalhadas na NT Conjunta 2025.001. Um sistema que aceita somente números pode rejeitar ou corromper identificação válida no novo formato.
Não apague letras, não converta o identificador em número inteiro e não invente dígitos para passar no cálculo antigo. Preserve a string oficial e use validação compatível com o padrão aplicável. Ter formato e dígito coerentes também não prova que a pessoa é a adquirente ou encomendante da operação: o vínculo documental continua necessário.
Exemplos para separar cadastro e software
Cenário sintético A: o cadastro correto preserva todos os caracteres, mas a integração remove zeros iniciais ao converter a identificação em número. A comparação entre cadastro e XML demonstra alteração. Cenário B: o terceiro possui CNPJ alfanumérico oficial, e um filtro remove as letras antes de serializar DI/CNPJ. O erro está no suporte ao formato, não em uma autorização para substituir a pessoa.
Cenário C: o cadastro já contém identificação diferente da documentação contratual. Nesse caso, corrija o cadastro apenas após confirmar a pessoa correta. A validação deve usar o identificador protegido real; por isso os exemplos comparam integridade e tipo sem fabricar CNPJ, CPF ou dígitos.
Como conferir a correção com evidência
Preserve o retorno completo e o XML enviado, identifique o grupo DI e compare o identificador em cada estágio: documento oficial, cadastro aprovado, integração e arquivo. Confira tipo de pessoa, comprimento, zeros, caracteres admitidos e validação de dígito no padrão adequado.
Quando o dado de origem está correto e a string muda na geração, corrija o software. Se não há identificação oficial ou vínculo confirmado, obtenha-os antes de preencher. Não substitua o terceiro pelo emitente ou destinatário como fallback. Regenerar um arquivo coerente não autoriza alterar documentos já autorizados nem reenviar uma transmissão cujo resultado ainda esteja incerto.
Fontes oficiais
- NT 2023.004 — Informações de Pagamentos e Outros — 1.20: p.13, I23d-20 e I23d1-10; p.7, campos do terceiro.
- NT 2026.004 CNPJ alfanumérico — 1.01: p.7, Grupo I01, DI/CNPJ alfanumérico; p.3, cronograma.
- NT Conjunta 2025.001 — 1.00: p.14, Anexo I: validação e cálculo dos dígitos do CNPJ alfanumérico.
- Leiaute da NF-e e protocolo — PL_010f_v1.04 / leiauteNFe_v4.00.xsd: DI/CNPJ e alternativa CPF.