Rejeição 387: código de enquadramento legal do IPI inválido
Revisão editorial em 16 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.
A rejeição 387/O06-10 da NF-e modelo 55 verifica a validade de cEnq, o código de enquadramento legal do IPI. Ter de um a três dígitos não basta: o código precisa constar da tabela oficial aplicável.
Onde localizar cEnq e qual tabela conferir
cEnq fica diretamente em det/imposto/IPI, antes do subgrupo IPITrib ou IPINT. Não é o CST do IPI, EXTIPI, NCM nem código de benefício de ICMS. O campo é obrigatório quando o grupo IPI é informado; isso não torna IPI obrigatório em toda NF-e.
O MOC remete à tabela de enquadramento. A NT 2020.002 consolida esse assunto e, na versão 1.01, atualiza a descrição do código 165. Use a tabela do anexo dessa NT para conferir código e descrição, além de preservar a referência normativa da situação confirmada. O XSD limita a forma do campo, mas não substitui o teste de existência do código.
Fontes: MOC 7.0 Anexo I v7.00, p. 118, NT 2020.002 — IPI v1.01, p. 3–4, Leiaute NF-e/NFC-e — PL 010f v1.04.
Validade e compatibilidade são verificações diferentes
A 387 verifica cEnq inválido. A 388/O09-10 verifica compatibilidade entre cEnq e determinados CST de IPINT, nas faixas específicas da regra. Um código existente pode ser incompatível com o CST informado; inversamente, estar dentro de uma faixa não prova que um número arbitrário exista na tabela.
Não substitua o código por 999 como solução genérica. Embora 999 apareça na tabela como “Outros”, sua existência não comprova que represente a operação. Confirme a fundamentação fiscal e o código com o responsável contábil; a tarefa técnica é transportar o parâmetro confirmado sem perda, truncamento ou substituição.
Fontes: NT 2020.002 — IPI v1.01, p. 3–4.
Exemplo de truncamento na integração
Exemplo sintético: a origem fiscal confirmada contém cEnq=165. A integração limita o código a dois caracteres e transmite 16. A conferência deve recuperar o 165 na origem, comparar o XML transmitido e pesquisar o código efetivamente enviado na tabela; não tentar completar qualquer código por aproximação.
Se a origem também contém 16, não há prova de falha de serialização: falta confirmar o enquadramento, com descrição da mercadoria, operação, situação do IPI e fundamento utilizado. O código 165 do exemplo não é recomendação para o leitor.
Um XML sintético não provaria a fundamentação legal da operação. A comparação textual entre origem, código transmitido e tabela permite diagnosticar a perda sem fabricar documento operacional.
Fontes: NT 2020.002 — IPI v1.01, p. 3–4.
Como verificar a geração corrigida
Associe 387 ao item, ambiente e XML da mesma tentativa. Compare cEnq bruto no cadastro, valor após os mapeamentos e texto final do XML. Preserve zeros significativos quando fizerem parte da representação confirmada e não transforme ausência em código padrão.
Depois de corrigir a origem comprovada, verifique novamente existência na tabela e compatibilidade com o CST. Valide a estrutura e os cálculos do item sem editar XML assinado. Registre o novo retorno, pois eliminar 387 não comprova autorização nem adequação da apuração. Se a situação de uma tentativa anterior for incerta, consulte essa situação antes de novo envio.
Fontes: MOC 7.0 Anexo I v7.00, p. 118, NT 2020.002 — IPI v1.01, p. 3–4.