Reforma Tributária

Por que agosto de 2026 muda a arquitetura fiscal da sua software house

This article is available in Portuguese only. We keep the original content to preserve technical accuracy.
Executive summary
What changed

O IBS, a CBS e o Imposto Seletivo passam a ter grupos próprios no layout da NF-e, NFC-e e NFS-e. Campos que eram opcionais viraram obrigatórios, e cada item precisa declarar sua situação frente aos novos tributos, mesmo quando isento. A adequação toca cadastro de produto, cálculo, montagem do XML, validação e recepção de documentos de terceiros.

Who is affected

Software houses que desenvolvem sistemas emissores de documentos fiscais eletrônicos, e por consequência as empresas clientes que emitem NF-e, NFC-e e NFS-e. Sistemas que armazenam ou validam CNPJ também são afetados pela mudança para CNPJ alfanumérico, independentemente dos grupos de tributo.

Um mapa técnico do que a Reforma exige do seu XML, das datas que já correm e do trabalho que o time precisa começar agora.

1. A Reforma não é troca de alíquota, é mudança de schema

Existe uma leitura confortável da Reforma Tributária que circula por aí: a de que basta ajustar percentuais e seguir a vida. Para quem escreve o código que emite documento fiscal, essa leitura é perigosa.

O IBS (a fatia estadual e municipal), a CBS (a fatia federal) e o Imposto Seletivo passam a ter grupos próprios no layout dos documentos. Até agora, preencher esses campos era opcional. Isso acabou. A mudança é na própria estrutura do XML que a sua software house já gera hoje.

Na prática, todo item da nota precisa declarar sua situação frente aos novos tributos, mesmo quando é isento. O motor de emissão que não souber montar esses grupos vai gerar documento que a SEFAZ recusa. E documento recusado significa faturamento travado do lado do seu cliente.

O ponto crítico é entender que isso não é uma feature nova a ser encaixada num canto do sistema. É uma alteração transversal que toca cadastro de produto, cálculo, montagem do XML, validação e recepção de notas de terceiros.

O relógio já está correndo

A Reforma tem um calendário longo, que se estende até 2033, quando os tributos antigos deixam de existir. Mas o que exige ação do seu time não está lá na frente. Está agora.

Três datas concentram a urgência técnica do curto prazo. Elas separam o que você precisa fazer hoje do que vai impactar o roteiro depois.

01/07/2026: homologação já cobra os campos novos

O ambiente de homologação já exige os campos de IBS, CBS e IS. É aqui que os seus desenvolvedores deveriam estar testando agora, em ambiente seguro, sem risco para a operação do cliente.

Quem usa esse período para corrigir os erros vira a chave com tranquilidade. Quem deixa para a última hora descobre os problemas na pior hora possível.

03/08/2026: produção passa a rejeitar

A partir dessa data, a produção passa a rejeitar NF-e e NFC-e sem o grupo de IBS/CBS para empresas do Regime Normal (CRT 3). A nota não é autorizada. O faturamento e a operação param.

Durante 2026, o sistema roda com alíquotas de teste para amadurecer o ambiente. A orientação técnica é clara: essas alíquotas de transição vêm de tabela oficial e nunca devem ser fixadas no código.

04/01/2027: a regra alcança Simples e MEI

A obrigatoriedade se estende às empresas do Simples Nacional e MEI (CRT 1, 2 e 4). Em 2027, a CBS passa a valer de verdade e substitui o PIS e a COFINS.

Quem adequou o sistema em 2026 chega nessa data sem risco de multas para os clientes. A janela de trabalho tranquilo é o intervalo entre hoje e agosto.

A família de rejeições que a SEFAZ criou

Aqui está um detalhe que muda a forma de planejar o trabalho. A SEFAZ não criou uma única rejeição para os novos tributos. Criou uma família inteira de códigos, a partir do 1000, cada um sinalizando um tipo específico de problema na montagem do documento.

Um erro no grupo raiz do item, um totalizador que não fecha centavo a centavo, um item isento enviado com valores zerados indevidamente, uma nota de crédito sem a chave referenciada. Cada uma dessas situações dispara um código diferente. A Rejeição 1115, a mais citada quando se fala da virada, é uma entre várias.

A consequência para a arquitetura é direta. Não basta tratar um caso e considerar o trabalho feito. O motor precisa cobrir o conjunto de situações que a família de rejeições mapeia, porque cada operação fiscal diferente pode esbarrar num código diferente.

É por isso que a adequação não é um patch pontual. É uma revisão da forma como o sistema monta, calcula e valida o documento inteiro.

As frentes de trabalho que a Reforma abre no seu código

Quando se olha o conjunto do que muda, fica claro que a adequação não é uma tarefa, é um projeto com várias frentes. Vale conhecer o mapa antes de estimar prazo.

No coração da mudança está o grupo de IBS/CBS dentro de cada item, com a dupla CST e cClassTrib comandando a classificação de cada produto. Some a isso os totalizadores do rodapé, que precisam bater exatamente com a soma dos itens, sob pena de rejeição por somatório.

A partir daí, o terreno se ramifica. Itens isentos ou imunes seguem uma regra de montagem diferente. Diferimento, quando a empresa empurra o recolhimento para a frente, exige declarar o valor de forma explícita. Combustíveis entram na tributação monofásica, com um grupo próprio. O Imposto Seletivo tem sua própria mecânica para produtos específicos. Vendas para o governo trazem redutor de alíquota. Notas de crédito e débito viram a nova forma de ajustar valores, substituindo a velha carta de correção.

E isso é só a NF-e e a NFC-e. A NFS-e nacional segue seu próprio padrão, com fase de envio declaratório e fase de retorno, além da lógica de gross-up entre valor limpo e valor com impostos. Cada frente tem suas regras de montagem, seus campos condicionais e seus códigos de rejeição associados.

Não vamos detalhar aqui os identificadores de cada campo nem os exemplos de XML de cada cenário. Esse é o conteúdo do guia. O que importa nesta leitura é dimensionar o esforço: são muitas frentes, cada uma com sua armadilha específica, e todas com prazo em comum.

Os pontos que passam despercebidos

Duas mudanças costumam ficar fora do radar de quem foca só nos grupos de tributo, e as duas mordem cedo.

A primeira é o CNPJ alfanumérico. A Receita confirmou o CNPJ com letras, e a mudança começa em julho de 2026. Isso não é opcional nem futuro. Se o banco de dados trata CNPJ como campo numérico, ele quebra silenciosamente ao encontrar uma letra no meio do número. A migração de tipagem, dos parsers e das validações de tela é um trabalho de fundação que precisa acontecer antes do resto.

A segunda é a recepção de documentos. Boa parte da conversa gira em torno de emitir notas. Mas o seu software também recebe as notas dos fornecedores do seu cliente, e é nessa entrada que mora o crédito tributário. A Reforma exige precisão nas alíquotas para o crédito ser aproveitado. Jogar a digitação desses campos quebrados para o teclado do usuário, a partir de um PDF impresso, é a receita para erro de digitação que afunda o caixa.

Há ainda o Split Payment no horizonte, em que a maquininha ou o banco lê a nota, separa a fatia do governo e deposita o resto na conta do cliente. A cobrança fica para o futuro, mas o chão de fábrica no código começa a ser preparado agora.

Por que ter o mapa completo antes da primeira linha de código

Diante de um projeto com tantas frentes e um prazo fixo, a pior estratégia é descobrir cada regra na hora em que a nota é rejeitada em homologação. Isso transforma a adequação numa sequência de sustos, com retrabalho a cada código novo que aparece.

A alternativa é começar pelo mapa. Entender de uma vez o conjunto de mudanças, os campos que cada operação exige, os códigos de rejeição que cada regra evita e a ordem em que faz sentido atacar o trabalho. Com o mapa na mão, a estimativa de esforço para de ser chute e o cronograma até agosto vira algo gerenciável.

Foi com essa lógica que montamos o Guia Prático de adequação à Reforma para software houses. Ele traça cada regra em duas frentes, o que a contabilidade precisa saber e o que o desenvolvedor precisa fazer, com o XML de exemplo de cada cenário e a rejeição que cada campo evita. É o roteiro que o seu time pode seguir do diagnóstico à entrega.

A adequação é trabalho de fôlego, mas é um trabalho mapeável. Quem tem o mapa completo em mãos vira a chave sem susto, para si e para os clientes que dependem do sistema.

Perguntas Frequentes

  1. A partir de quando a produção rejeita notas sem os novos tributos?
    Para empresas do Regime Normal (CRT 3), a produção passa a rejeitar NF-e e NFC-e sem o grupo de IBS/CBS a partir de 03/08/2026. Para Simples Nacional e MEI (CRT 1, 2 e 4), a regra alcança a partir de 04/01/2027. O ambiente de homologação já cobra os campos desde 01/07/2026.
  1. A Reforma muda só as alíquotas ou muda o layout do documento?
    Muda a estrutura. IBS, CBS e Imposto Seletivo passam a ter grupos próprios no layout da NF-e, NFC-e e NFS-e. Campos que eram opcionais viraram obrigatórios, e a montagem do XML precisa ser revista.
  1. A Rejeição 1115 é a única que preciso me preocupar?
    Não. A SEFAZ criou uma família de códigos a partir do 1000 para os erros ligados aos novos tributos. A 1115 é a mais citada, mas cada tipo de problema na montagem do documento dispara um código diferente, e o motor precisa cobrir o conjunto.
  1. O CNPJ alfanumérico afeta o meu sistema mesmo que eu não mexa em tributos?
    Sim. O CNPJ com letras começa em julho de 2026 e afeta qualquer sistema que armazene ou valide CNPJ. Bancos de dados que tratam o campo como numérico quebram ao encontrar uma letra. É uma migração de tipagem independente dos grupos de tributo.
  1. As alíquotas de teste de 2026 podem ser fixadas no código?
    Não. As alíquotas de transição vêm de tabela oficial e mudam. Fixar valores no código gera retrabalho a cada atualização. A recomendação é buscar sempre a tabela oficial como dado vivo.
  1. Onde encontro o detalhamento técnico de cada campo e os exemplos de XML?
    No Guia Prático de adequação à Reforma para software houses. Ele traz os identificadores de cada campo, os exemplos de XML por cenário e o checklist de entrega, organizados por data de obrigatoriedade.

Migrate ao seu lado na adequação à Reforma

Adequar o motor fiscal à Reforma é um projeto com prazo fixo e muitas frentes. Fazer isso no escuro, descobrindo cada regra na rejeição, custa meses de patch e sustos em produção. Ter o mapa completo desde o início muda o jogo.

A Migrate vive o fisco todos os dias, com IBS, CBS e IS já em produção em NF-e, NFC-e, NFS-e, CT-e e MDF-e. Reunimos essa experiência num Guia Prático que traça cada regra em duas frentes, o que a contabilidade precisa saber e o que o desenvolvedor precisa fazer, com XML de exemplo e a rejeição que cada campo evita.

Baixe o Guia Prático completo e comece a adequação da sua software house com o roteiro na mão!

Referências

BRASIL. Emenda Constitucional nº 132/2023. Reforma Tributária do consumo.

BRASIL. Lei Complementar nº 214/2025, alterada pela Lei Complementar nº 227/2026.

BRASIL. Receita Federal. Nota Técnica 2025.002-RTC (NF-e/NFC-e). Portal Nacional da NF-e. https://www.nfe.fazenda.gov.br

BRASIL. Receita Federal. Nota Técnica 2026.004 (CNPJ alfanumérico). Portal Nacional da NF-e. https://www.nfe.fazenda.gov.br

BRASIL. Notas Técnicas SE/CGNFS-e 008 e 009 (NFS-e). Portal Nacional da NFS-e. https://www.gov.br/nfse

MIGRATE. Reforma Tributária: página de conteúdo técnico para desenvolvedores. https://desenvolvedores.migrate.info

MM
Matheus Melo
Migrate Team

Migrate's specialists closely follow changes in tax legislation and electronic fiscal documents.

Migrate Newsletter

The right information. At the right time!
Get relevant tax content and updates straight to your inbox.