CST e cClassTrib: como revisar o cadastro antes de emitir a NF-e

Revise a regra de emissão, não apenas a ficha do produto

O cadastro pode estar preenchido e ainda esconder uma decisão fiscal sem fundamento. Isso acontece quando o mesmo código é copiado para todos os itens, quando uma configuração antiga é importada sem versão ou quando a equipe escolhe uma opção apenas porque o emissor a aceita.

Este roteiro é para contadores que revisam a parametrização de clientes emissores de NF-e, modelo 55. O recorte é o Código de Situação Tributária (CST) e o código de classificação tributária (cClassTrib) do Imposto sobre Bens e Serviços (IBS) e da Contribuição sobre Bens e Serviços (CBS). A aplicabilidade deve ser conferida por contribuinte, regime, operação e período. Não transfira este roteiro automaticamente para a NFS-e ou para todos os optantes do Simples Nacional.

A entrega proposta é uma relação de cenários de emissão com fundamento, responsável e teste documentados. O contador analisa o tratamento; a empresa descreve a operação; o responsável pelo ERP implementa a regra aprovada. Um campo preenchido não substitui nenhuma dessas etapas.

Leia também: Reforma tributária: como organizar as próximas ações de cada cliente

O que CST e cClassTrib informam na NF-e

No leiaute da NT 2025.002 v1.51, o CST de IBS/CBS tem três dígitos e o cClassTrib tem seis. São os campos UB13 e UB14 do grupo de tributação do item. Não confunda esse CST com os códigos usados para ICMS ou PIS/Cofins.

O IT 2025.002 v1.60 explica que os três primeiros dígitos do cClassTrib coincidem com o CST correspondente. A tabela relaciona o enquadramento a dispositivos legais e regulamentares. Também informa vigência, modelos de documento permitidos e indicadores de preenchimento de grupos.

Confira, portanto, a combinação completa: código existente, vínculo com o CST, período válido, permissão para NF-e e campos exigidos, permitidos ou vedados. A compatibilidade técnica é uma verificação; a aderência da operação à hipótese legal é outra.

A Nomenclatura Comum do Mercosul (NCM) ajuda a identificar a mercadoria, mas não descreve sozinha toda a operação. Como contraste legal concreto, a LC 214/2025 trata vendas onerosas no art. 4º e transferências entre estabelecimentos do mesmo contribuinte no art. 6º, II. Um produto pode manter sua identificação e participar de situações diferentes. Isso impede adotar “um NCM, um código para qualquer saída” como regra universal.

Referência: SVRS: IT 2025.002 v1.60, tabelas de classificação de IBS/CBS, seções 2 e 3. Consultado em 29/09/2026. ↗

Referência: SVRS: NT 2025.002 v1.51, leiaute da NF-e/NFC-e, campos UB13 e UB14. Consultada em 29/09/2026. ↗

Referência: Câmara dos Deputados: LC 214/2025 consolidada, arts. 4º, 6º e 62. Consultada em 29/09/2026. ↗

Guarde a versão da tabela e a versão do leiaute separadamente

Na consulta de 29/09/2026, as referências localizadas nos portais oficiais foram o IT 2025.002 v1.60, para as tabelas, e a NT 2025.002 v1.51, para o leiaute e as regras da NF-e/NFC-e. Os números de versão pertencem a documentos diferentes. Não compare 1.60 e 1.51 como se uma versão substituísse a outra.

Guarde o arquivo consultado, endereço de origem, data de obtenção e responsável pela revisão. Registre também a versão do ERP em que a alteração foi testada. A ficha deve permitir responder se o código veio de uma tabela oficial identificada ou de uma planilha recebida sem procedência.

A página do Validador RTC da SVRS consultada nesta revisão exibia referência à NT 2025.002 v1.31. Ela pode auxiliar a inspeção, mas esse rótulo não demonstra cobertura da v1.51. Antes de usar qualquer validador como evidência de conclusão, compare sua versão declarada com a referência adotada no teste. Registre limitações, inclusive quando a versão não for informada.

Referência: SVRS: IT 2025.002 v1.60, tabelas de classificação de IBS/CBS, seções 2 e 3. Consultado em 29/09/2026. ↗

Referência: SVRS: NT 2025.002 v1.51, leiaute da NF-e/NFC-e, campos UB13 e UB14. Consultada em 29/09/2026. ↗

Referência: SVRS: Validador RTC da NF-e, referência de versão exibida na página. Consultado em 29/09/2026. ↗

Exemplo: um produto, três cenários e duas decisões ainda abertas

Considere uma distribuidora fictícia que usa o item interno P-17 em venda a cliente, transferência entre seus próprios estabelecimentos e devolução ao fornecedor. O exemplo organiza a revisão; não determina os códigos ou o imposto de uma empresa real.

A exportação do cadastro mostra um único par de CST e cClassTrib para P-17, mas não explica em quais operações o ERP o aplica. O contador pede três amostras de XML, uma de cada cenário, e a descrição das regras de seleção do emissor. Descobre que a venda tem justificativa registrada, a transferência herdou a configuração da venda e a devolução não tem regra documentada.

A equipe abre três linhas de análise para o mesmo item. Na venda, mantém a proposta de classificação para teste porque há fundamento registrado. Na transferência, pede a identificação dos estabelecimentos e revisa o tratamento específico. Na devolução, reúne a nota original e as condições da operação antes de decidir os parâmetros.

O resultado inicial é uma linha com fundamento disponível e duas com decisão pendente, total de três. Nenhuma foi aprovada para produção apenas por aparecer nessa lista. Mesmo a primeira ainda depende da conferência do XML gerado e do aceite do responsável. Essas contagens medem o estado da revisão, não a precisão tributária nem uma economia obtida.

A solução não é necessariamente criar três cadastros do mesmo produto. Primeiro, confirme se o ERP seleciona a tributação por natureza da operação e outras condições. Se o sistema só oferece um valor fixo, registre a limitação com o responsável técnico. Não force uma classificação única para contornar uma restrição de configuração.

Referência: Câmara dos Deputados: LC 214/2025 consolidada, arts. 4º, 6º e 62. Consultada em 29/09/2026. ↗

Leia também: Devolução e cancelamento: confira documentos, reembolso e IBS/CBS

Monte uma ficha curta para cada cenário de emissão

A estrutura abaixo é uma sugestão de controle interno. Ela pode começar em uma planilha e não cria uma obrigação acessória. Use uma linha por combinação relevante de fatos, evitando duplicar linhas que têm o mesmo tratamento sustentado.

Exemplo de identificação: “P-17, saída por transferência, estabelecimento A para B, modelo 55, período analisado”. A descrição deve ser compreensível para quem configura o ERP e para quem revisa o documento depois. Um nome como “regra 07” sem explicação dificulta a conferência.

• Fatos: emitente, regime, destinatário quando relevante, item, NCM, natureza e finalidade da operação, documento e data.
• Enquadramento proposto: CST e cClassTrib completos, hipótese analisada e fundamento com artigo, condição e referência vigente.
• Evidências faltantes: dado necessário, pessoa responsável por fornecê-lo e data combinada para resposta.
• Configuração: regra do ERP que escolhe os códigos, condições de exceção e versão anterior preservada.
• Teste e aceite: XML de teste, resultado esperado, resultado encontrado, divergências, responsável pela revisão e decisão de liberação.

Leia também: Auditabilidade: como explicar uma decisão contábil meses depois

Teste a seleção do código e leia o XML produzido

Comece pelo cenário mais frequente que já tem fundamento completo. Em ambiente de teste, gere o documento com os dados representativos da operação e examine o item no XML. Compare o par de códigos efetivamente gerado com a ficha aprovada. Conferir somente a tela do cadastro deixa de fora regras que o ERP aplica durante a emissão.

Depois altere uma condição que deveria selecionar outra regra, como a natureza da saída no exemplo. Verifique se o emissor muda o tratamento conforme a decisão fiscal documentada. Se continuar reutilizando o mesmo parâmetro, investigue a seleção da regra antes de alterar valores manualmente.

Na conferência técnica, use a nota técnica e as tabelas correspondentes para verificar também os grupos relacionados. Um código corrigido com campos dependentes inconsistentes não encerra o teste. Guarde o XML, a resposta recebida e a comparação realizada; teste em homologação não equivale a documento fiscal de produção.

Após o aceite, combine quem aplicará a configuração e qual será a primeira emissão acompanhada. Preserve a configuração anterior para permitir investigação e reversão controlada, quando cabível. Se surgir divergência, suspenda a liberação daquela regra e encaminhe a decisão ao responsável, sem apagar o histórico nem tratar um ajuste de cadastro como correção automática de notas já emitidas.

Referência: SVRS: IT 2025.002 v1.60, tabelas de classificação de IBS/CBS, seções 2 e 3. Consultado em 29/09/2026. ↗

Referência: SVRS: NT 2025.002 v1.51, leiaute da NF-e/NFC-e, campos UB13 e UB14. Consultada em 29/09/2026. ↗

Leia também: IBS e CBS em 2026: o que conferir na NF-e antes do fechamento

Uma nota autorizada pode continuar exigindo revisão

No esclarecimento de 06/08/2026, Receita Federal e CGIBS distinguiram o adiamento de validações automáticas da obrigação de prestar as informações de IBS/CBS. A flexibilização de rejeições não foi apresentada como dispensa geral de adequação. Por isso, o protocolo de autorização não deve ser a única evidência de que a classificação foi revisada.

Confirme separadamente a regra material, o preenchimento exigido e a validação técnica aplicável ao documento e à data. Não use a ausência de rejeição como argumento para copiar um parâmetro para toda a carteira. O calendário e as condições de cada contribuinte precisam permanecer na análise.

Para notas já emitidas com possível divergência, abra uma ocorrência vinculada ao XML original. A forma de corrigir o documento e os efeitos fiscais dependem do caso. Alterar o cadastro pode evitar repetição, mas não resolve por si só o que já foi autorizado.

Referência: CGIBS e Receita Federal: esclarecimento de 06/08/2026 sobre validação de documentos fiscais. Consultado em 29/09/2026. ↗

Entregue ao cliente o que foi revisado e o que falta decidir

Ao fechar o trabalho, informe quais cenários foram analisados, quais passaram pelo teste combinado e quais permanecem pendentes. Explique o motivo de cada pendência e o próximo responsável. Evite declarar “cadastro adequado à reforma” quando apenas uma operação foi examinada.

Acompanhe duas medidas simples: cenários liberados sobre o total definido no escopo e pendências que voltaram após a primeira emissão acompanhada. Registre também o tempo gasto na análise e no retrabalho, se medido. Cobertura de teste não é percentual de acerto fiscal; tempo liberado não comprova redução de gastos sem comparação de custos.

Para organizar a base documental da carteira, identifique o que falta reunir e quem responderá pela próxima ação com o cliente. A apresentação da my selene para contadores explica o escopo da plataforma. Este procedimento não comprova que o produto classifica operações, configura qualquer ERP ou garante conformidade tributária automaticamente.

Leia também: Como melhorar a precisão da revisão sem esconder as pendências