Rejeição 1067: a classificação da tributação regular não foi reconhecida

Quando a nota recebe a rejeição 1067, confira a classificação tributária que foi enviada dentro do grupo de tributação regular. Esse código descreve a situação de referência do IBS e da CBS, e pode estar errado mesmo que a classificação principal do item esteja correta. Repetir o envio ou trocar o produto não resolve essa divergência.

A mensagem é “Rejeição: Classificação Tributária do IBS e da CBS informada no grupo de tributação regular inexistente [nItem: 999]”. O nItem aponta o item a examinar. “Inexistente” se refere ao código de classificação informado naquele campo, não ao destinatário ou ao estabelecimento emitente.

O campo que precisa ser examinado

A regra UB70-10 da NT 2025.002-RTC v1.52, página 52, aplica-se à autorização de NF-e modelo 55 e NFC-e modelo 65. Se o grupo gIBSCBS/gTribRegular estiver preenchido, a regra verifica a existência do código em gTribRegular/cClassTribReg na tabela oficial de classificação do IBS e da CBS.

Não confunda cClassTribReg com IBSCBS/cClassTrib. O primeiro descreve qual seria a classificação caso não fosse cumprida uma condição resolutória ou suspensiva; o segundo descreve o enquadramento principal do item. A emissão precisa manter ambos coerentes com a operação. Copiar um para o outro sem análise pode dar significado incorreto ao documento.

Também separe a 1067 da 1066. A 1066 verifica a existência do CST regular em CSTReg; a 1067 verifica a classificação regular em cClassTribReg. São dados relacionados, mas diferentes. Um CST existente não torna automaticamente existente qualquer classificação digitada ao lado dele.

Onde procurar a causa

Preserve o XML efetivamente enviado e o retorno completo. Registre a chave, o modelo, o ambiente, a data, a UF e o autorizador. Localize o item na resposta e relacione-o à mercadoria e à regra fiscal aplicada. Se uma tela mostra apenas “1067”, consulte o detalhe: um código numérico pode ter outros sentidos em documentos ou serviços diferentes.

Compare o conteúdo de cClassTribReg no XML com o cadastro fiscal e com a tabela oficial. Examine a descrição da linha, o CST associado e as datas de vigência. Se uma integração conserva uma lista antiga, a escolha disponível na tela pode não coincidir com a tabela consultada pelo autorizador. Não conclua que a SEFAZ está errada antes de comprovar o conteúdo transmitido.

O código é textual e sua representação exige cuidado. Por exemplo, 000001 tem zeros iniciais. Convertê-lo em número e exportar “1” perde a representação esperada. Nesse caso, a falha também pode ser identificada pela validação de esquema; não prometa que todo erro de tamanho gerará precisamente a 1067.

Um código de NCM, CFOP ou classificação de NFS-e não ocupa esse campo. Se a integração utiliza uma tabela compartilhada, o suporte precisa demonstrar que o dado veio do domínio correto de cClassTrib do IBS/CBS para o documento emitido.

Existência é uma verificação, enquadramento é outra

Na consulta oficial de 10/10/2026, a classificação 000001 está vinculada ao CST 000 e descreve situações tributadas integralmente pelo IBS e pela CBS. A tabela permite seu uso em NF-e e NFC-e. Isso confirma sua existência e suas indicações documentais; não prova que ela representa a tributação regular de qualquer produto ou operação.

A classificação principal possui ainda indicadores próprios. A mesma consulta mostra que 200022 exige gTribRegular, mas permite NF-e e não permite NFC-e. Portanto, um exemplo de NF-e com esse enquadramento não pode ser convertido em cupom de varejo apenas mudando o modelo. Consulte as condições da linha real, em vez de decidir pela semelhança do número.

Como corrigir por cenário

A classificação regular foi digitada errada. O responsável fiscal deve indicar a linha correta da tabela e explicar por que ela descreve a referência exigida naquela operação. Corrija o cadastro ou a regra que alimenta o XML. Não procure um número qualquer existente apenas para retirar a mensagem.

A tabela local está desatualizada. Confira a publicação oficial, a data da tabela interna e o processo de atualização do emissor. Atualize os dados pelo procedimento apropriado e reavalie a configuração atingida. Um código substituído ou uma descrição alterada pode exigir revisão fiscal; atualizar uma lista não resolve sozinho o enquadramento de notas já preparadas.

A integração mapeou o campo errado. Compare o valor definido na origem com o exportado em cClassTribReg. Verifique regras padrão, importações, conversões numéricas e seleção de cadastro. O suporte deve corrigir a transformação responsável e regenerar a nota pelo emissor, preservando a correspondência entre os dados internos, o XML e sua assinatura.

A classificação principal foi copiada para o grupo regular. Reavalie a situação de referência com a contabilidade. Em operações sujeitas a uma condição, a classificação principal e a regular podem ter papéis diferentes. Não há regra universal para repetir a classificação principal, nem para substituí-la sempre por 000001.

O grupo foi incluído indevidamente. Confirme o indicador da classificação principal antes de retirar gTribRegular. Se o grupo é exigido, sua remoção pode levar à 1065. Se é vedado, a inclusão é tratada pela 1114. A solução é tornar o documento coerente, não ocultar a informação rejeitada.

Exemplo de conferência

Uma empresa fictícia de equipamentos emite uma NF-e cujo enquadramento exige tributação regular. O fiscal definiu os dados de referência, mas uma importação antiga inseriu em cClassTribReg um identificador interno do cadastro de produtos. Esse identificador tem seis posições, porém não corresponde a uma classificação existente. A resposta indica 1067 no item 3.

A equipe confirma o enquadramento com a contabilidade e corrige o mapeamento. Depois gera outro XML pelo emissor e confere o código regular, seu CST e os cálculos. O produto continua o mesmo; valores comerciais e destinatário não são alterados para eliminar a rejeição. O exemplo mostra por que ter seis dígitos não basta: é preciso usar o domínio correto e a classificação fiscal aplicável.

Como verificar e encaminhar

No novo arquivo, confira cClassTribReg no item correto, sua correspondência com a tabela e os demais campos do grupo. Analise o novo retorno da SEFAZ e registre o resultado associado à chave correta. Se aparecer rejeição de cálculo, examine a rubrica indicada; não volte a trocar classificações sem investigar a nova causa.

O desaparecimento da 1067 não garante autorização nem valida integralmente a escolha tributária. Peça suporte quando a tela e o XML divergirem, a atualização falhar ou a origem do código não puder ser rastreada. Peça análise fiscal quando houver dúvida sobre a situação regular. Persistindo a rejeição com documentação e XML concordantes, encaminhe evidências ao autorizador da UF.

Versão e implantação

Em 10/10/2026, a SVRS lista a NT v1.52, publicada em 01/10. O aviso ENCAT de 05/10 adiou a implantação anunciada dessa versão para 26/10 em homologação e 16/11 em produção. A UB70-10 é herdada de versões anteriores e não tem aviso individual de implementação futura na página 52. O adiamento não demonstra suspensão dessa regra. Não houve teste operacional nesta revisão: confira o ambiente e o retorno do autorizador da empresa, sem presumir ativação uniforme em todas as UFs.

Fontes

Consulta e revisão documental por IA: 10/10/2026.

• NT 2025.002-RTC v1.52, UB70-10 e regras vizinhas, p.52.

• SVRS: tabela oficial CST/cClassTrib, documentos atuais e aviso ENCAT de 05/10/2026.

• Migrate: rejeição 1067, NS7: rejeição 1067 e Buscador NCM: cClassTribReg. Três publicadores distintos; o terceiro fornece apoio ao campo e aponta a rejeição, sem diagnóstico individual de operação. Limites e exemplos não reutilizados estão registrados em fontes.json.