IBS e CBS no regime normal: o que muda na NF-e e NFC-e do seu ERP com a NT 2025.002

Quando eu leio uma nota técnica que mexe no coração do documento fiscal, eu já penso no efeito em cadeia. Não é só um campo novo. É cadastro, regra de negócio, serialização, validação, teste, suporte e, claro, risco de rejeição. Com a NT 2025.002-RTC, isso fica muito claro para quem emite NF-e modelo 55 e NFC-e modelo 65 no regime normal.

No regime normal, a entrada de IBS e CBS no leiaute da NF-e e da NFC-e muda o item, o total da nota e a lógica fiscal do ERP.

Eu vi muita gente resumindo o tema como “novos tributos na nota”. Só que, para desenvolvedor de ERP, software house e time fiscal, isso é pouco. O que muda mesmo é a forma de estruturar o payload por item, respeitar CST, classificar a operação com cClassTrib, calcular base, informar IBS estadual, IBS municipal, CBS e refletir tudo nos totais. E isso sem improviso.

Neste artigo, eu trato somente de NF-e e NFC-e. Não vou misturar NFS-e, NT-008 ou DANFSe, porque são outros documentos e outra conversa. Meu foco aqui é o cenário de quem precisa adaptar o sistema ao novo leiaute da NT 2025.002-RTC, observando a versão vigente no Portal da NF-e no momento da publicação. Como referência pública de mercado, a explicação do cronograma de obrigatoriedade para 2026 e 2027 mostra que, para empresas do regime normal, o preenchimento dos campos de IBS e CBS na NF-e e NFC-e passou a ser obrigatório em 03/08/2026.

Também considero o histórico da NT, já que a finalização do leiaute para IBS, CBS e IS em versão anterior da NT 2025.002-RTC já indicava a direção do documento, das tabelas e das validações voltadas à apuração assistida.

Se você trabalha com emissão por integração, como eu costumo ver em projetos conectados à Notaas, o ponto central é este: a aplicação não pode mais tratar o bloco tributário da nota como algo fixo. Agora ele depende ainda mais da natureza real da operação.

O que a NT 2025.002 muda, na prática

A NT 2025.002-RTC introduz grupos voltados ao novo modelo de tributação sobre consumo dentro da NF-e e da NFC-e. Na prática, isso exige que o ERP passe a preencher dados por item e também os totais da nota com consistência matemática e fiscal.

A mudança não está só no XML final, mas na modelagem interna do ERP e no fluxo de validação antes da autorização.

Eu costumo dividir o impacto em quatro camadas:

• Cadastro e parametrização fiscal da operação;
• Motor de cálculo por item;
• Geração do XML ou JSON intermediário da nota;
• Testes de consistência e tratamento de rejeições.

Isso parece simples no papel. No sistema real, nem tanto. O mesmo produto pode ter tratamento diferente conforme UF, finalidade da operação, CFOP, tipo de destinatário e enquadramento fiscal. Por isso, não faz sentido adotar um cClassTrib genérico para tudo.

Classificação fiscal não aceita atalho.

Onde entram os grupos IBSCBS e gIBSCBS

No desenho do leiaute, o desenvolvedor precisa olhar com atenção para os grupos criados para detalhar IBS e CBS no item. Em termos práticos, o grupo IBSCBS aparece ligado ao item da nota e o grupo gIBSCBS organiza os dados necessários para cálculo, classificação e valores.

O preenchimento de IBS e CBS passa a ser item a item, e não apenas uma informação resumida no fechamento do documento.

Eu recomendo pensar no item da NF-e ou NFC-e como uma unidade tributária completa. Isso significa que cada item deve sair do ERP já com:

• CST aplicável à operação naquele contexto;
• CClassTrib compatível com a tributação real;
• Base de cálculo correta;
• Alíquota e valor do IBS estadual;
• Alíquota e valor do IBS municipal, quando couber no leiaute previsto;
• Alíquota e valor da CBS;
• Reflexo nos totais do documento.

Essa estrutura pede revisão de objetos internos, banco de dados e contratos de API. Em alguns ERPs, eu já vi o cálculo tributário depender de uma única coluna de “regra fiscal”. Nesse cenário, a chance de retrabalho cresce bastante.

Como tratar CST e cClassTrib sem erro

Esse é o ponto em que eu mais vejo simplificação perigosa. CST e cClassTrib não podem ser preenchidos “por padrão” sem olhar a operação. O CST informa a situação tributária dentro da lógica prevista. Já o cClassTrib tem função classificatória e depende da operação concreta.

O cClassTrib não deve ser fixado de forma genérica para todas as vendas, porque ele depende da natureza da operação e da validação fiscal.

Na prática, eu sugiro que o ERP permita montar a decisão com base em regras combinadas, como:

• Tipo de documento, NF-e ou NFC-e;
• CFOP;
• UF de origem e destino;
• Tipo de cliente;
• Finalidade da emissão;
• Tipo de item;
• Cenário tributário definido pelo fiscal ou contador.

Isso reduz a tentação de “resolver” tudo com um único mapeamento. Eu já vi projeto atrasar porque a equipe técnica esperava uma lista universal para cClassTrib, mas ela não existe dessa forma. A classificação depende da operação e precisa ser validada pelo fiscal ou contador da empresa emissora.

Se você acompanha conteúdos sobre documentos fiscais eletrônicos, vale manter um histórico técnico em temas próximos, como a categoria de NF-e do blog da Notaas, porque esse tipo de mudança quase sempre conversa com arquitetura, suporte e governança de emissão.

Base de cálculo e segregação dos valores

Outro erro comum é imaginar que basta reaproveitar a base de um tributo atual e distribuir percentuais. Eu não faria isso sem regra explícita. A NT pede coerência entre base de cálculo, CST, classificação e totalizadores. Então, o ERP deve calcular e armazenar cada parcela de forma separada.

IBS estadual, IBS municipal e CBS precisam sair discriminados por item, com base e valor compatíveis com a regra fiscal aplicada.

No desenho técnico, eu gosto de separar os campos internos em três blocos:

1. Dados de enquadramento, como CST e cClassTrib.
2. Dados de cálculo, como base e alíquotas.
3. Dados de resultado, como valores por item e totais agregados.

Essa divisão ajuda em auditoria, suporte e rastreabilidade. Quando uma nota é rejeitada, a equipe consegue descobrir se o erro veio do cadastro, do cálculo ou da serialização.

Também é uma boa hora para rever automações do ERP. Se sua aplicação já trabalha com filas, respostas assíncronas e webhooks, a adaptação tende a ficar mais controlada. É um cenário em que eu vejo valor em plataformas como a Notaas, porque a emissão via API com retorno estruturado ajuda a testar cenários tributários sem depender de rotina manual.

Diferenças entre NF-e 55 e NFC-e 65

A presença dos grupos de IBS e CBS atinge os dois modelos, mas o contexto operacional deles é bem diferente. NF-e costuma ter mais cenários B2B, remessas, devoluções e combinações fiscais. NFC-e, por outro lado, trabalha com frente de caixa, alto volume e resposta rápida.

Na NFC-e, qualquer falha de cálculo ou classificação pesa mais, porque o erro aparece no fluxo de venda ao consumidor.

Eu trato a diferença assim:

• Na NF-e, o foco é amplitude de cenários fiscais;
• Na NFC-e, o foco é latência baixa e estabilidade na automação do caixa;
• Na NF-e, o saneamento cadastral costuma ser mais trabalhoso;
• Na NFC-e, o risco operacional está na escala de emissão;
• Em ambos, os totais precisam fechar com o item.

Por isso, não basta “ligar” os novos campos no mesmo ritmo para os dois modelos. Eu separaria as trilhas de teste. Uma para NF-e com mais combinações tributárias. Outra para NFC-e com simulação de volume e contingência.

Cenário de teste de 2026 e o que ele não significa

Há um ponto que eu sempre faço questão de separar. O cenário-teste de 2026 com alíquota de 0,1% de IBS e 0,9% de CBS, conforme referências oficiais e materiais públicos sobre a implantação, serve para testes e transição do documento fiscal. Ele não deve ser confundido com regra definitiva de recolhimento em qualquer operação.

Alíquota de teste, obrigação acessória, ativação de validação e recolhimento são temas ligados, mas não são a mesma coisa.

Eu separo assim:

• Alíquota de teste: usada para viabilizar cenários de homologação e transição do documento;
• Obrigação acessória: trata da necessidade de informar campos no documento;
• Ativação das regras de validação: define quando a SEFAZ passa a rejeitar ou cobrar consistência;
• Recolhimento: trata do pagamento do tributo, que não deve ser presumido só pela presença do campo na nota.

Essa distinção evita ruído entre time técnico e fiscal. Eu já vi squad travar sprint porque alguém confundiu “campo obrigatório no XML” com “mesma regra já exigida para recolhimento no processo inteiro”. São assuntos próximos, mas não idênticos.

Exemplo JSON simplificado por item

Em integrações modernas, muitas software houses montam primeiro um payload JSON e depois transformam para o XML fiscal. Abaixo está um exemplo simplificado, apenas para mostrar a lógica de estrutura. Os nomes exatos dos campos devem seguir o leiaute vigente da NT 2025.002-RTC no seu projeto.

O exemplo abaixo é didático e precisa ser ajustado ao leiaute oficial e às regras da sua operação.

Item tributado exige detalhe real.

{

"modelo": "55",

"crt": "3",

"itens": [

{

"numeroItem": 1,

"cfop": "5102",

"ncm": "22030000",

"valorItem": 100.00,

"ibscbs": {

"cst": "000",

"cClassTrib": "preencher_conforme_operacao",

"vBC": 100.00,

"pIBSUF": 0.10,

"vIBSUF": 0.10,

"pIBSMun": 0.00,

"vIBSMun": 0.00,

"pCBS": 0.90,

"vCBS": 0.90

}

}

],

"totais": {

"vBCIBSCBS": 100.00,

"vIBSUF": 0.10,

"vIBSMun": 0.00,

"vCBS": 0.90

}

}

Eu gosto desse tipo de estrutura porque ela deixa claro o vínculo entre item e total. Em APIs de emissão, isso também ajuda na resposta de erro. Se você usa mensageria ou webhooks, pode devolver rejeições e inconsistências de forma mais rastreável.

Exemplo XML simplificado

Quando o ERP gera o XML fiscal, a mesma lógica precisa estar representada no item e nos totalizadores. Mais uma vez, o exemplo abaixo é simplificado.

O XML deve refletir exatamente o leiaute e as regras de validação vigentes no ambiente autorizado da NF-e e da NFC-e.

<det nItem="1">

<prod>...</prod>

<imposto>

<IBSCBS>

<gIBSCBS>

<CST>000</CST>

<cClassTrib>preencher_conforme_operacao</cClassTrib>

<vBC>100.00</vBC>

<pIBSUF>0.10</pIBSUF>

<vIBSUF>0.10</vIBSUF>

<pIBSMun>0.00</pIBSMun>

<vIBSMun>0.00</vIBSMun>

<pCBS>0.90</pCBS>

<vCBS>0.90</vCBS>

</gIBSCBS>

</IBSCBS>

</imposto>

</det>

<total>

<vBCIBSCBS>100.00</vBCIBSCBS>

<vIBSUF>0.10</vIBSUF>

<vIBSMun>0.00</vIBSMun>

<vCBS>0.90</vCBS>

</total>

Em um projeto mais maduro, eu registraria também o snapshot da regra aplicada no momento da emissão. Isso ajuda muito quando o time precisa justificar por que determinada classificação foi usada naquele item.

Checklist de testes no ERP

Antes de liberar isso em produção, eu faria uma bateria de testes bem objetiva. Não é o momento de validar só “uma nota que autorizou”. O que vale é cobrir variação de cenário.

Testar IBS e CBS no regime normal exige casos felizes, casos de borda e casos de rejeição.

Minha checklist mínima seria esta:

• NF-e modelo 55 com um item tributado e totais simples.
• NF-e com múltiplos itens e combinações diferentes de CST.
• NFC-e modelo 65 com emissão em sequência e alto volume.
• Casos com desconto e conferência da base de cálculo.
• Casos com devolução ou finalidade específica, se aplicável ao ERP.
• Validação de arredondamento por item e no total.
• Ausência de campos obrigatórios no grupo IBSCBS.
• CClassTrib incompatível com a natureza da operação.
• Diferença entre soma dos itens e total informado.
• Teste de retorno por webhook e persistência da rejeição.

Se seu sistema usa emissão distribuída por API, vale olhar também como a integração trata respostas assíncronas. Na categoria de automação da Notaas, esse tema conversa bem com rotinas de fila, reprocessamento e consistência operacional.

Principais rejeições que eu esperaria ver

As regras exatas dependem do ambiente e da versão vigente da NT, mas alguns padrões de erro são previsíveis desde já. Eles nascem de omissão, classificação ruim ou fechamento inconsistente.

As rejeições mais comuns tendem a envolver falta de campos, incompatibilidade de CST e divergência entre item e total.

Eu prepararia monitoramento para, pelo menos, estes grupos de falha:

• Grupo IBSCBS não informado quando exigido para o CRT do emitente;
• CST ausente ou inválido para aquela operação;
• CClassTrib ausente, inválido ou incompatível;
• Base de cálculo zerada sem amparo na regra fiscal;
• Valor de IBS estadual ou municipal divergente da alíquota e da base;
• Valor de CBS divergente do cálculo esperado;
• Totalizadores do documento diferentes da soma dos itens;
• Preenchimento indevido em cenário não compatível.

Quando eu penso em suporte, gosto de transformar cada rejeição em mensagem interna legível pelo fiscal e pelo desenvolvedor. Isso encurta o caminho entre erro técnico e correção operacional.

Arquitetura, versionamento e rollout

Esse tipo de mudança fiscal não combina com ajuste direto em produção. Eu faria rollout controlado, por empresa, por filial ou por grupo de documentos, sempre com feature flag e versionamento de schema.

O ERP precisa saber qual versão do leiaute fiscal está ativa e qual regra de obrigatoriedade vale para cada emissor.

Na prática, eu montaria este fluxo:

1. Versionar payload interno e XML.
2. Separar regra por CRT e por data de obrigatoriedade.
3. Registrar auditoria da classificação aplicada.
4. Habilitar validação preventiva antes do envio à SEFAZ.
5. Monitorar rejeições por tipo e por cliente.

Se a sua operação também depende de integração, arquitetura e escala, vale acompanhar conteúdos relacionados em tecnologia. Muitas vezes, o problema não está no cálculo em si, mas no jeito como o sistema distribui regras e versões.

Também ajuda manter a base de conhecimento do time em temas próximos, como chave de acesso na NF-e, estrutura, consulta e uso prático. E eu deixo um alerta simples: não confunda essa pauta com o conteúdo de NFS-e, emissão e integração por API, porque aqui estamos falando só de NF-e 55 e NFC-e 65.

Conclusão

Na minha leitura, a NT 2025.002-RTC marca uma mudança de verdade no tratamento fiscal da NF-e e da NFC-e para empresas no regime normal. Não é apenas um ajuste cosmético no XML. É uma revisão da lógica tributária por item, da forma de fechar totais e da responsabilidade do ERP em carregar a classificação correta para cada operação.

Quem trabalha com IBS e CBS no regime normal precisa tratar cadastro, cálculo, totalização e validação como partes de um mesmo problema.

Eu também penso que o maior erro agora é correr para preencher campos sem revisar o fundamento fiscal. cClassTrib não é valor decorativo. CST não pode ser herdado sem contexto. Base de cálculo não pode ser presumida. E os totais não podem “fechar na marra”.

Se eu tivesse que resumir em uma frase, seria esta: a nota fiscal ficou mais declarativa sobre a operação real. Isso pede ERP mais preparado, time fiscal mais próximo da tecnologia e testes mais sérios antes da virada de obrigatoriedade.

Se você quer validar payloads de NF-e e NFC-e com os novos grupos de IBS e CBS, meu conselho é começar pelos cenários de homologação e testar a integração com uma API preparada para automação fiscal. A Notaas pode ajudar nesse processo, especialmente para quem precisa emitir, versionar e acompanhar respostas de forma estruturada. Teste seus payloads IBS/CBS na API de NF-e/NFC-e da Notaas e veja como sua aplicação se comporta antes da pressão da produção.

Perguntas frequentes

O que muda no ERP com IBS e CBS?

No ERP, muda a estrutura do item da NF-e e da NFC-e, o cálculo tributário, os totalizadores e as validações antes da transmissão. Passa a ser necessário informar grupos de IBS e CBS com CST, cClassTrib, base de cálculo, valores de IBS estadual, IBS municipal e CBS, além de garantir que a soma dos itens feche com o total do documento.

Como emitir NF-e no regime normal com IBS e CBS?

Para emitir NF-e no regime normal com IBS e CBS, eu recomendo seguir o leiaute vigente da NT 2025.002-RTC, parametrizar corretamente o CRT do emitente, classificar cada item conforme a operação, calcular base e valores por item, gerar os totalizadores e validar tudo antes do envio. A classificação deve ser confirmada pelo fiscal ou contador, sem adotar cClassTrib genérico para todas as operações.

IBS e CBS substituem quais impostos atualmente?

No contexto da reforma do consumo, IBS e CBS fazem parte da nova estrutura que substitui tributos atuais incidentes sobre consumo. Neste artigo, meu foco ficou na adaptação do documento fiscal eletrônico, então o ponto prático é que o ERP precisa se preparar para informar esses novos tributos no leiaute da NF-e e da NFC-e conforme a obrigação aplicável.

Quais empresas devem usar o regime normal de IBS e CBS?

Aqui estamos falando das empresas enquadradas no regime normal, normalmente identificadas pelo CRT 3 no contexto da NF-e e da NFC-e. Segundo o cronograma público já divulgado, a obrigatoriedade dos campos de IBS e CBS para esse grupo começou antes dos demais enquadramentos, o que exige atenção especial de ERPs, software houses e áreas fiscais dessas empresas.

Como implementar as mudanças da NT 2025.002 no sistema?

Eu implementaria em etapas: revisão do modelo de dados, criação dos campos e grupos de IBS/CBS por item, ajuste do motor de cálculo, geração dos totalizadores, validação pré-envio, testes por cenário e rollout controlado por cliente ou filial. Também manteria versionamento do leiaute e trilha de auditoria da classificação usada em cada emissão para reduzir erro e retrabalho.