Migração de ERP deixou de ser só um projeto de tecnologia. Trocar de sistema, seja para SAP S/4HANA, TOTVS Protheus, Oracle ou qualquer outro, significa levar o cadastro de materiais inteiro para o ambiente novo, com tudo que ele carrega. No modelo do IBS e da CBS, instituído pela Emenda Constitucional 132/2023 e regulamentado pela Lei Complementar 214/2025, esse cadastro inclui a classificação fiscal de cada item, que alimenta o campo cClassTrib exigido em todo documento fiscal eletrônico. Se a base de origem tem NCM ausente, genérico ou divergente entre itens iguais, a migração não resolve isso: apenas transporta o erro para um sistema que passa a rejeitar nota por causa dele.
Este texto mostra por que o cadastro de materiais decide o sucesso de uma migração de ERP, quando isso vira urgência fiscal e o que revisar antes do go-live.
O que muda na migração de ERP com a reforma tributária?
Antes, migrar de ERP era decisão de TI e de Suprimentos. O cronograma girava em torno de parametrização, integração e treinamento de usuário. Um NCM errado no cadastro migrado virava, na pior hipótese, um ajuste de relatório fiscal meses depois.
Com o IBS e a CBS, o cadastro de materiais migrado alimenta diretamente a validação da nota fiscal eletrônica, através do cClassTrib. Esse código de seis dígitos, definido pela Nota Técnica RT 2025.002 do Portal Nacional da NF-e, identifica o tratamento tributário do item e leva em conta a classificação fiscal do material, entre outros elementos do enquadramento definido pela Lei Complementar 214/2025. Quando falta essa informação no cadastro que entrou no sistema novo, não existe forma sistêmica de preencher o cClassTrib corretamente, e a nota é rejeitada na validação, logo no início da operação do ERP novo.
Isso muda quem precisa estar na mesa do projeto. Migração de ERP deixa de ser pauta só de TI e Suprimentos e passa a exigir o Fiscal e o Tributário desde o desenho do de-para entre sistemas, porque é esse time que responde pela apuração quando a nota trava.
Por que o cadastro de materiais decide se a migração de ERP funciona?
Porque o ERP novo não interpreta a natureza técnica do material, ele só reflete o que recebeu no cadastro migrado. Um parafuso registrado como "PRF M8" na base antiga chega como "PRF M8" na base nova, sem composição, sem norma, sem informação suficiente para enquadramento na TIPI vigente. O sistema novo não corrige isso sozinho.
O mesmo vale para duplicidade. Se a base de origem tem o mesmo rolamento cadastrado três vezes, com três NCM diferentes, a migração replica os três registros e os três códigos, agora sob validação mais rígida. E se um item de segurança, como uma luva nitrílica, está com NCM genérico usado para toda a família de EPI, a classificação não sustenta o enquadramento correto de nenhuma delas.
O ponto que costuma surpreender times de projeto: quanto mais limpo o de-para entre sistemas, mais rápida a migração. Base com descrição padronizada e classificação fiscal completa reduz decisão manual durante a carga, porque não sobra ambiguidade sobre qual item é qual.
Quando a migração de ERP vira urgência fiscal?
Depende da fase do calendário da reforma em que o cutover acontece.
| Ano | O que acontece | Efeito na migração de ERP |
|---|---|---|
| 2026 | Fase de teste, CBS a 0,9% e IBS a 0,1% (Lei Complementar 214/2025) | Ainda não cobra valor cheio, mas já rejeita nota com cClassTrib incompatível: é a janela para migrar com a base já corrigida |
| 2027 | CBS plena, PIS e COFINS extintos em 31 de dezembro de 2026, Imposto Seletivo em vigor (Lei Complementar 214/2025) | O sistema novo entra em produção já sob a regra cheia, e erro de cadastro migrado passa a travar faturamento real, não só teste |
| 2029 a 2032 | Transição com redução progressiva de ICMS e ISS enquanto o IBS assume a arrecadação (Emenda Constitucional 132/2023) | Quem migrou com a base errada carrega o mesmo erro nas duas apurações simultâneas, durante todo o período |
A leitura prática: cutover feito em 2026, com base já saneada, entra no regime pleno de 2027 sem herdar problema. Cutover feito depois, sobre uma base ainda suja, carrega o erro para dentro do sistema novo bem no momento em que ele passa a custar. O detalhe de cada fase está em NCM errado na reforma tributária.
Como preparar o cadastro de materiais antes de migrar de ERP?
A ordem dos passos importa, porque carregar erro para o sistema novo custa mais caro do que corrigir antes da carga.
- Extraia a base de origem completa antes de desenhar o de-para. Levante quantos itens estão sem NCM, com código genérico, ou com classificação divergente entre materiais equivalentes.
- Saneie a descrição técnica antes da carga, não depois do go-live. Composição, função, medida e norma aplicável precisam estar no registro que vai ser migrado, porque o sistema novo não deduz isso sozinho.
- Elimine duplicidade por característica técnica, não por texto. Uma válvula esfera de uma polegada cadastrada de três formas diferentes precisa virar um único registro antes da migração, ou o de-para herda os três.
- Classifique na TIPI vigente com justificativa registrada. Cada NCM migrado precisa sobreviver a auditoria, e isso exige rastreabilidade do porquê da classificação, não só o código.
- Valide o cClassTrib de uma amostra em homologação, antes do go-live real. Teste um lote representativo de itens no ambiente novo, incluindo famílias de maior volume, para achar erro de enquadramento antes que ele apareça em produção.
- Trate a base saneada como pré-requisito de go-live. Adiar o saneamento para depois da migração inverte a ordem: agora o sistema novo, mais rígido, é que vai expor o erro.
O passo mais pulado é o primeiro. Times de migração costumam ir direto para parametrização do sistema novo, sem medir o tamanho real do problema na base de origem, e descobrem a extensão do erro só quando a nota começa a ser rejeitada. O caminho para essa etapa está detalhado em saneamento de cadastro de materiais.
O que fazer se a migração de ERP já aconteceu sem saneamento?
Se o cutover já passou e a base foi migrada sem correção, o erro está reproduzido no sistema novo, não eliminado. A correção nesse ponto segue a mesma lógica de um saneamento comum, aplicada agora sobre a base já em produção: medir o tamanho do problema, priorizar por volume de compra e por alíquota, e corrigir item a item com justificativa registrada. A diferença é que, sem esse trabalho, cada nota rejeitada volta a consumir tempo do time fiscal para descobrir qual item está com o cadastro inconsistente.
Sem uma regra de entrada para item novo depois da correção, a base migrada suja de novo em poucos meses, porque o cadastro continua recebendo item novo todos os dias. Esse é o papel da governança, descrito em governança de dados mestres.
O que fazer agora
Se a sua empresa está planejando ou já está em projeto de migração de ERP, o primeiro passo não é esperar o cronograma do sistema novo definir a prioridade da base. É medir agora: quantos itens ativos estão sem NCM, com código genérico ou com classificação divergente, e qual o volume de compra associado a eles. Esse número muda a conversa de quanto custa saneiar antes para quanto custa migrar o erro para dentro do sistema novo.
A DataStruct faz esse diagnóstico sem custo. Você envia uma amostra da base em CSV e recebe um relatório com os pontos críticos encontrados e a estimativa de exposição para a sua operação. Peça a análise da sua base antes do próximo cutover.