Rejeição 1023: localize o cClassTrib que não existe na tabela oficial

Se a nota recebeu 1023, confira o código de classificação tributária do IBS/CBS enviado no item indicado. A SEFAZ não encontrou esse código na tabela utilizada pela validação. Antes de escolher outro número, identifique se houve erro de cadastro, transformação na integração ou desatualização da tabela. A classificação correta precisa corresponder à operação da empresa.

O retorno documentado é “Rejeição: Classificação Tributária do IBS/CBS informada inexistente [nItem: 999]”. O nItem da resposta identifica o item afetado; 999 representa o número na documentação. Não é o NCM do produto nem o código interno do seu cadastro.

Qual campo foi rejeitado

A regra UB14-10 da NT 2025.002-RTC v1.52, página 41, se aplica à autorização da NF-e, modelo 55, e da NFC-e, modelo 65. Ela verifica a existência do valor informado em IBSCBS/cClassTrib, campo UB14. O leiaute prevê um código numérico de seis posições. NT 2025.002 v1.52, p.18 e 41.

Esse código detalha a classificação do IBS/CBS. Ele é diferente do CST de três posições e do NCM. Não se cria um cClassTrib juntando números que parecem representar a operação. Uma sequência com seis dígitos pode atender ao tamanho do campo e ainda assim não existir na tabela oficial.

Também separe os retornos vizinhos. O 1020 trata de CST inexistente; o 1024, de cClassTrib incompatível com o CST; o 1025, da classificação não permitida para o modelo do documento. Essas verificações se relacionam, mas a 1023 aponta inicialmente a existência do código. Depois da correção, outra inconsistência pode aparecer.

Primeiro compare cadastro e XML

Guarde o XML enviado, a mensagem integral, a chave, a data de emissão, o modelo e o ambiente. Anote a UF/autorizador e a versão do emissor ou integração. Localize o item indicado no XML e confira a descrição do produto, para evitar corrigir um item diferente.

Leia o cClassTrib do arquivo e compare com a tela e com a regra fiscal selecionada para a operação. Um produto pode ter classificações diferentes conforme o contexto fiscal; o campo visível no cadastro nem sempre é a única origem usada pelo emissor. Verifique também regras por operação, estabelecimento ou integração, quando existirem.

Se a tela contém um valor e o XML contém outro, procure a transformação entre eles. Se os valores são iguais, consulte a tabela oficial atual e a classificação indicada pela contabilidade. Essa comparação divide o problema entre a decisão fiscal, o cadastro e a geração do arquivo.

Como corrigir os cenários mais comuns

O código foi digitado ou importado incorretamente

Uma importação pode retirar zeros iniciais, truncar o campo ou confundir a classificação com outro código. Confira o registro original aprovado pelo responsável fiscal e a sequência de seis posições no XML. Corrija o cadastro ou o mapeamento que alterou a informação.

Não acrescente zeros de qualquer maneira e não tente números próximos até obter autorização. A correção deve recuperar a classificação verdadeira. Depois, gere novamente o documento rejeitado pelo fluxo do emissor e confira o valor que efetivamente será transmitido.

O sistema usou um valor padrão por falta de configuração

Se a classificação não foi vinculada à regra fiscal, a integração pode preencher um padrão inválido. Identifique o tratamento usado na nota e peça ao responsável fiscal para definir a classificação cabível. O suporte deve verificar por que a falta de vínculo chegou à transmissão sem ser tratada.

Evite um código genérico para todo o catálogo. Produtos parecidos podem ter tratamentos diferentes, e a existência de um código não significa que ele serve para qualquer operação. Documente o alcance do ajuste e confira outros cadastros que usam a mesma regra.

A tabela interna ficou desatualizada

Consulte a tabela oficial e registre a data de consulta. Confira a descrição, o CST associado, os indicadores do documento e os campos de início e fim de vigência disponíveis. Compare com a versão da tabela carregada no sistema. A atualização deve preservar os vínculos corretos e apontar registros que precisam de análise fiscal.

Não conclua que todo código antigo foi excluído nem que uma novidade já foi carregada em todos os autorizadores. Se o código aparece na fonte oficial, mas continua rejeitado, reúna o registro da consulta e encaminhe a divergência. Trocar a classificação válida por outra apenas para emitir mascara a causa.

O cadastro mudou, mas a nota conserva a classificação anterior

Confira se o documento foi preparado antes da correção. O sistema pode conservar os dados que recebeu ao montar a nota. Use o procedimento de recomposição ou recálculo disponível e compare o novo XML com o anterior.

Quando o conteúdo mudar, o emissor deve produzir novamente a assinatura. Não edite manualmente o arquivo já assinado. Preserve a operação comercial e seus registros; corrigir uma nota rejeitada não exige automaticamente criar uma nova venda ou trocar sua numeração.

Exemplo de causa comprovada

Uma loja fictícia migra o cadastro de uma regra fiscal para outro emissor. O responsável fiscal havia indicado uma classificação específica, mas a importação deixou seu vínculo vazio. O novo sistema gera 000000 no item 4. Na tabela oficial capturada para esta revisão, esse código não consta; a nota recebe 1023.

A equipe identifica o vínculo perdido e recupera a classificação previamente conferida com a contabilidade. Depois recompõe a nota, compara cadastro e XML e acompanha o novo retorno. O exemplo explica uma falha de migração, sem recomendar uma classificação universal ou presumir autorização após o primeiro ajuste.

Qual tabela e qual cronograma considerar

Em 10/10/2026, o portal SVRS listava a NT 2025.002 v1.52 como versão mais recente. A UB14-10 não aparece como alteração nova da v1.52 no histórico dessa versão. O aviso ENCAT de 05/10 adia a atualização 1.52 para 26/10 em homologação e 16/11 em produção; isso não suspende automaticamente verificações de classificação já existentes. Documentos SVRS, aviso ENCAT.

A consulta oficial da classificação apresenta dados próprios por registro, inclusive vigência e uso por documento. Não há uma única data de publicação que substitua a análise de todas as linhas. Confira a emissão e o ambiente concretos, sem presumir implantação uniforme por UF. A obrigação geral de informar IBSCBS possui outra regra; retirar o grupo para eliminar 1023 não resolve a classificação nem define a obrigação fiscal da empresa.

Como saber se o caso foi resolvido

Verifique o código corrigido no XML, sua correspondência com a decisão fiscal e o resultado da transmissão. A mudança de mensagem pode significar que a existência foi aceita e outra regra precisa de tratamento. Confirme a autorização e o protocolo da chave correta quando esse for o resultado final.

Acione a contabilidade para escolher ou revisar a classificação. Chame o suporte quando houver tabela antiga, vínculo perdido, valor transformado ou documento que não incorpora o cadastro novo. Havendo código oficial válido e divergência persistente, encaminhe ao autorizador XML, resposta, horários, modelo, ambiente e evidência da tabela. Evite retransmissões repetidas sem alteração comprovada.

Fontes e revisão

Consulta documental e revisão por IA: 10/10/2026. Sem emissão de teste por UF/ambiente e sem certificação fiscal humana.

• NT 2025.002-RTC v1.52, p.6, 7, 18, 40 e 41.

• Tabela oficial de classificação tributária, SVRS, captura de 10/10/2026.

• Conferência prática: TOTVS/Datasul, ABC71 e F5 Software de Gestão. Suas telas e rotinas são específicas desses produtos; não foram apresentadas como recursos verificados do ALRA.