A tabela de CST da Reforma muda de versão como software, mas poucos ambientes SAP tratam ela assim

O Ato Técnico Conjunto RFB/SUFIS/CGIBS nº 8 aprovou, entre outros instrumentos, o Informe Técnico com as tabelas de Código de Classificação Tributária, CST, e Classificação do Crédito Presumido do IBS e da CBS, em vigor desde a publicação. Essa tabela não é parametrização feita uma vez e esquecida: é um artefato que recebe nova versão em ciclo curto, e cada nota emitida depende de qual versão está carregada no ambiente naquele instante. Se ninguém no time sabe dizer em que versão o SAP está agora, a nota sai, mas ninguém sabe com que regra.

O que o Ato Técnico Conjunto nº 8 aprovou

O Ato, de 29 de setembro de 2026, aprova a documentação técnica cujas especificações se aplicam à CBS e ao IBS, reunindo múltiplos instrumentos num único pacote normativo: leiautes de documentos fiscais, notas técnicas de adaptação e, entre eles, o Informe Técnico com as tabelas de Código de Classificação Tributária, CST e Classificação do Crédito Presumido. Essas tabelas definem, de forma padronizada e nacional, como cada operação deve ser classificada para fins de incidência, isenção, diferimento ou crédito presumido de IBS e CBS.

A tabela de CST não é um anexo decorativo da legislação. É o dicionário que o sistema emissor de notas consulta, operação por operação, para decidir qual código lançar no documento fiscal. Sem essa tabela corretamente carregada, não existe classificação tributária válida possível, porque o próprio conceito de CST depende de estar alinhado à versão oficial vigente no momento da emissão.

O ponto que a maioria dos projetos de adequação à Reforma trata como evento único é, na verdade, um fluxo contínuo. O Ato Técnico Conjunto nº 7, do dia anterior, já havia aprovado documentação técnica para a NFS-e. O nº 8 aprova documentação adicional cobrindo NF-e, NFC-e, CT-e e outros documentos, no mesmo pacote que traz a tabela de CST. Normas técnicas desse tipo se sucedem em semanas, não em anos.

Projeto de Reforma tem data de fim. Manutenção de tabela fiscal, não.

Essa diferença de natureza é o que mais costuma passar despercebido no planejamento de adequação. Um projeto de implementação tem escopo fechado, cronograma e entrega final. A tabela de CST, uma vez em produção, não tem data de encerramento: ela continua recebendo novas versões enquanto o regime de IBS e CBS existir, o que, pela própria convivência prevista entre regimes, significa anos de atualização contínua, não um marco único de adequação.

Vale notar que cada novo ato técnico desse tipo não chega isolado: ele costuma vir acompanhado de ajustes correlatos em documentos vizinhos, como visto na sequência dos nº 7 e nº 8 publicados em dias consecutivos. Isso significa que monitorar apenas o informe que trata diretamente da tabela de CST não basta; é preciso acompanhar o conjunto de atos técnicos do período, porque uma mudança aprovada num documento pode ter efeito colateral na forma como outro documento precisa tratar a mesma classificação.

Tabela como release: o ciclo de atualização

Tratar a tabela de CST como release de software, não como parâmetro fixo, é a mudança de mentalidade que esse tipo de norma exige. Toda vez que um novo ato técnico aprova uma versão atualizada da tabela, isso é, na prática, equivalente a um lançamento de versão de um sistema: existe uma versão anterior em produção, existe uma versão nova aprovada, e existe uma janela de tempo em que a empresa precisa migrar de uma para a outra sem gerar nota com classificação inválida no meio do caminho.

O problema é que a maioria das equipes fiscais não tem, hoje, um processo formal de versionamento para tabela de CST comparável ao que a área de TI já aplica a releases de software. Não existe, na maioria dos ambientes, um changelog documentado de quando cada versão da tabela entrou em produção, quem aprovou a mudança, e que testes foram rodados antes de liberar para emissão real.

Versão de tabela sem changelog é versão sem prova. O sistema pode estar certo hoje e ninguém consegue provar.

O risco mais imediato dessa lacuna é silencioso: enquanto a rejeição automática de notas com classificação desatualizada estiver dispensada pelo ambiente nacional, uma nota emitida com CST da versão antiga passa pela autorização normalmente. O erro não aparece no momento da emissão. Ele só se torna visível quando o comitê gestor ou a Receita cruzarem os dados emitidos contra a tabela vigente na data de cada operação, e aí a divergência aparece retroativamente, acumulada ao longo de todo o período em que a tabela desatualizada esteve em uso.

Essa dispensa temporária de rejeição automática tem um efeito colateral pouco discutido: ela remove o incentivo imediato para corrigir o problema. Numa integração com validação rígida, um erro de classificação gera rejeição instantânea, e alguém é forçado a investigar na hora. Sem essa trava, a tabela desatualizada pode continuar em produção por semanas ou meses, silenciosamente, até que um evento externo, como uma intimação ou um cruzamento de dados, force a descoberta.

Essa dispensa de rejeição imediata é compreensível como medida de transição: um ambiente nacional recém-criado não pode travar toda a emissão fiscal do país enquanto milhares de empresas ainda ajustam seus sistemas. Mas a mesma tolerância que viabiliza a transição também é o que esconde o problema de quem não trata a tabela como item de controle contínuo. A flexibilidade do regulador não é permissão para negligência interna: é um prazo de graça que alguém precisa usar para montar o processo, não para adiar indefinidamente essa decisão.

Quem atualiza no SAP e em qualquer add-on fiscal

Numa operação SAP com localização Brasil, a tabela de CST de IBS e CBS normalmente precisa ser mantida em pelo menos dois lugares: na parametrização nativa de código fiscal do próprio SAP, e em qualquer motor fiscal complementar instalado para tratar especificamente as regras da Reforma, quando esse tipo de camada adicional existir no ambiente. Os dois precisam estar sincronizados com a mesma versão de tabela, ao mesmo tempo, porque uma nota emitida com uma camada numa versão e outra camada noutra versão produz resultado inconsistente.

A pergunta que decide se essa atualização acontece de forma confiável é simples e raramente tem resposta pronta: existe um responsável nomeado, dentro ou fora da empresa, que monitora a publicação de cada novo ato técnico ou informe, e que tem autoridade e processo para atualizar a tabela em todos os sistemas relevantes antes que a próxima nota precise sair? Se a resposta depende de alguém notar, por acaso, uma notícia sobre a mudança, o processo não é controlado, é sorte.

Essa responsabilidade também precisa sobreviver a trocas de equipe. Se o conhecimento de onde a tabela vive, como ela é atualizada e qual é o canal oficial de publicação de novas versões está concentrado numa única pessoa, a saída dessa pessoa da empresa cria uma lacuna de governança que só aparece quando a próxima versão da tabela for publicada e ninguém souber, com segurança, o que fazer.

Conhecimento concentrado numa pessoa não é governança. É dependência disfarçada de processo.

Há também a questão de quem tem autoridade formal para aprovar a mudança de versão antes dela ir para produção. Mesmo quando existe alguém tecnicamente capaz de atualizar a tabela, se não houver um ponto de aprovação definido, com critério claro sobre o que precisa ser testado antes da liberação, a atualização pode acontecer de forma apressada, sob pressão do prazo de vigência da norma, sem o teste de regressão que deveria preceder qualquer mudança em produção.

Ficha de versão e teste de regressão

O equivalente fiscal de um changelog de software é uma ficha de versão: um registro simples que amarra, para cada versão da tabela de CST, a data em que o ato técnico correspondente foi publicado, a data em que a tabela entrou em produção no ambiente, quem autorizou a mudança, e que teste foi rodado antes da liberação. Sem esse registro, uma pergunta aparentemente simples, como "em que versão o ambiente estava emitindo notas no dia X", vira trabalho de arqueologia de sistema, não consulta a documento.

O teste mínimo de regressão, antes de qualquer atualização de tabela ir para produção, deveria cobrir uma amostra representativa dos cenários de classificação mais usados pela operação: os CSTs de tributação normal mais frequentes, qualquer cenário de crédito presumido relevante para o negócio, e qualquer cenário de isenção ou diferimento que a operação utilize com regularidade. Rodar essa amostra contra a nova versão, comparando o resultado da classificação antes e depois da atualização, expõe rapidamente se a mudança de versão alterou o comportamento esperado para algum tipo de operação específica.

Teste de regressão não prova que a tabela nova está certa. Prova que a mudança não quebrou o que já funcionava.

Vale registrar também que, segundo material técnico do próprio ecossistema de implementação de ERP para a Reforma, há previsão de operação paralela entre o regime antigo e o novo até 2033, com convivência entre tributos substituídos e substitutos durante esse período. Isso significa que a tabela de CST do regime novo não substitui integralmente, de imediato, toda a lógica fiscal anterior: por um bom tempo, o sistema precisa saber aplicar a regra certa conforme o momento da operação, o que torna a governança de versão ainda mais crítica, porque o erro de aplicar a tabela errada ao período errado se soma ao risco comum de aplicar uma versão desatualizada da tabela certa.

Essa convivência prolongada entre regimes também significa que a ficha de versão precisa registrar não apenas a versão da tabela de CST do regime novo, mas também até quando cada regra do regime antigo ainda se aplica a determinado tipo de operação. Um sistema que atualiza corretamente a tabela nova, mas aposenta prematuramente uma regra do regime antigo que ainda deveria estar ativa para certas operações em transição, cria um segundo tipo de erro de classificação, tão silencioso quanto o primeiro e igualmente dependente de prova documentada para ser corrigido com segurança.

Um ponto final vale registrar na ficha de versão: nem toda mudança de tabela afeta todos os tipos de operação igualmente. Uma empresa com portfólio de produtos concentrado em poucas categorias fiscais pode ser atingida por uma atualização específica de CST enquanto outra, com catálogo mais diversificado, fica praticamente indiferente à mesma mudança. Classificar o impacto esperado de cada nova versão, antes de liberar para produção, ajuda a priorizar onde o teste de regressão precisa ser mais rigoroso.

A pergunta que fecha esse tema não é sobre a Reforma em si, é sobre maturidade operacional: existe hoje, documentado, quem atualiza a tabela, quando atualiza e com que teste, de forma que, a qualquer momento, alguém consiga provar em que versão o ambiente estava emitindo notas numa data específica? Esse é exatamente o tipo de rotina que a sustentação fiscal consultiva de um AMS existe para sustentar, monitorando a publicação de cada novo ato técnico, traduzindo isso em mudança controlada de tabela, e mantendo a ficha de versão viva para qualquer consulta futura.