Por que agosto de 2026 muda a arquitetura fiscal da sua software house
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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
Migrate Newsletter
The right information. At the right time!
Get relevant tax content and updates straight to your inbox.