A rejeição 1115 foi adiada, mas o grupo IBSCBS errado continua saindo do SAP

A rejeição 1115 foi suspensa, não a obrigação que ela protegia. A validação técnica UB12-10, que barraria automaticamente qualquer NF-e emitida sem o grupo IBSCBS preenchido, entrou em compasso de espera por Ato Técnico Conjunto entre Receita Federal e Comitê Gestor do IBS, e a Nota Técnica 2025.002-RTC já trata a rejeição como implementação futura, sem data definida. Isso não significa que o grupo de tributos deixou de ser exigível. Significa que o sistema parou de brigar com quem erra o preenchimento. A obrigação de destacar CBS e IBS nos documentos fiscais eletrônicos aplicáveis continua valendo desde 3 de agosto, e o SAP continua emitindo nota com o campo errado sem acusar nada. Sem rejeição técnica, a malha perde o ponto em que o erro era mais barato de corrigir, e um default silencioso em agosto some do radar justamente no trimestre em que companhias abertas já reconhecem essa obrigação em nota de resultado.

O que a Nota Técnica previa e onde as fontes divergem

A confusão em torno dessa data tem origem dupla. Fornecedores de tecnologia fiscal publicaram, em maio, que toda NF-e sem o grupo IBS/CBS seria rejeitada a partir de agosto, tratando a data como ponto final de tolerância. A SEFAZ, via Ato Técnico Conjunto RFB/CGIBS, suspendeu a rejeição automática antes mesmo de ela entrar em vigor plena, sem anunciar nova janela de reativação, e nenhum calendário publicado até agora prevê quando a validação volta a travar documentos.

O resultado é que parte do mercado fiscal ainda trata agosto como a data de atenção, enquanto o sistema real não bloqueia nada desde o primeiro dia do mês. Isso cria uma lacuna de percepção perigosa: o time fiscal acredita que, se a nota saiu, ela está correta. A rejeição nunca foi o critério de correção, era só o mecanismo que convertia erro de dado em bloqueio visível no momento em que o erro era mais barato de corrigir, antes de a nota circular e virar base de apuração.

Sem essa conversão, o erro de dado deixa de ser evento e vira silêncio. E silêncio, em ambiente fiscal, é problema sem data de descoberta. O Ato Técnico Conjunto suspendendo a UB12-10 é fato documentado; que a Receita não reative essa validação em 2026 é leitura nossa, não certeza. Se a reativação vier sem aviso prévio, qualquer nota emitida por default desde agosto passa a estar sujeita a rejeição retroativa na malha, transformando um passivo hoje silencioso em lote de correção sob prazo de terceiro, não de agenda interna.

O que o mercado continua tratando como data de atenção

A rejeição é mecanismo de enforcement. A obrigação é norma. Quem acompanha essas normas por clipping tende a tratar a rejeição como o evento que importa, e a obrigação legal como detalhe subordinado a ela. Essa inversão desloca o esforço de verificação para depois do fechamento, quando o custo de corrigir já multiplicou, porque o volume emitido no intervalo cresceu junto.

Uma empresa pode estar isenta de ter a nota rejeitada e, ao mesmo tempo, seguir descumprindo o destaque informativo exigido desde 3 de agosto. A checagem de que o campo gravado corresponde à regra de determinação, e não ao enforcement externo, é responsabilidade da área fiscal, não de TI, e deveria acontecer antes de consolidar o fechamento, não depois que a nota já circulou e compôs o SPED do período.

Presumir que o sistema avisaria se algo estivesse errado custa mais caro do que desconhecer a lei.

Na prática, quem primeiro percebe o default não é o fiscal: é a controladoria, ao reconciliar o resultado publicado contra o SPED, geralmente trimestres depois da emissão.

Quando existe auditoria própria, o time confronta o campo gravado contra a regra de determinação antes de consolidar o período, e qualquer default suspeito vira item de revisão ainda dentro do mês. Quando não existe, o fechamento roda sobre o que o sistema entregou sem contestação, e o primeiro confronto real só acontece quando alguém de fora decide comparar, muitas vezes já fora da janela em que corrigir custa pouco.

Onde esse reconhecimento já apareceu, fora do SPED

Há pelo menos um caso público de companhia aberta que já incorporou essa obrigação em notas explicativas de resultado trimestral, tratando a fase de transição como algo que contempla, entre outras obrigações, o destaque individualizado e informativo da CBS e do IBS nos documentos fiscais eletrônicos aplicáveis.

Quando uma obrigação aparece em nota de resultado, ela deixa de ser só ponto de atenção da área fiscal e vira fato reconhecido pela companhia perante o mercado, sujeito a parecer de auditoria independente. Esse parecer cobre o resultado publicado, não o XML emitido por trás dele, e é exatamente nessa lacuna entre os dois documentos que a divergência de dado sobrevive sem ser notada.

O padrão de prova interno sobe de patamar: não basta a área fiscal saber que o campo existe, é preciso que o dado que sai no XML seja o mesmo que a empresa já declarou cumprir. Essa reconciliação normalmente recai sobre quem responde pela controladoria ou pela área fiscal no fechamento trimestral, e o gap não aparece em auditoria de rotina: aparece quando alguém de fora compara os dois documentos, e aí a pergunta deixa de ser técnica e vira pergunta de governança, porque envolve o que foi assinado por quem responde pelo resultado publicado.

O efeito real na base fiscal, quando não há rejeição

No SAP, o grupo IBSCBS é determinado por regra de sistema, amarrada ao cClassTrib e à combinação de tipo de operação, natureza da transação e parametrização de tax code. Quando a regra cobre o cenário, o campo sai certo. Quando não cobre, por exceção de processo, operação nova ou cadastro de item sem atualização, o sistema não trava a emissão: preenche por default, geralmente com o valor mais genérico configurado, e segue o documento adiante sem registrar que uma decisão de dados foi tomada sem regra de negócio por trás.

O padrão que costuma se repetir na operação de transmissão e distribuição de energia é esse: o cadastro mestre de itens e serviços foi parametrizado uma vez, no projeto original de IBS/CBS, e cada aditivo de contrato, cada ativo novo entrando em operação comercial e cada revisão tarifária subsequente geram transações que a árvore de determinação original nunca previu, e que por isso caem no default genérico até alguém revisitar a parametrização.

O sinal técnico fica no log de determinação tributária: toda vez que o motor fiscal resolve o tax code sem encontrar condição específica de cClassTrib para o cenário, ele grava a entrada na condição genérica em vez de uma condição de negócio nomeada. É esse carimbo, não o valor final do campo, que isola o default dentro da trilha. O documento circula, é escriturado, entra no SPED, compõe a base do período, e o erro só existe de fato quando alguém o compara contra a regra que deveria ter sido aplicada, o que normalmente acontece na apuração assistida, não na emissão.

É nesse ponto que o erro muda de natureza. Deixa de ser campo mal preenchido em nota isolada e vira divergência estrutural na base, porque o mesmo default provavelmente se repetiu em toda transação parecida durante todo o período sem rejeição. Um erro que numa janela de dias seria ajuste pontual, numa janela de meses vira padrão difícil de isolar sem revisitar todo o volume emitido, e quanto mais tarde a comparação acontecer, maior o lote que precisa ser revisado documento a documento. Cadastro de item novo sem revisão de cClassTrib é o gatilho que mais aumenta a chance do default, porque entra no fluxo de faturamento antes de a área fiscal validar a classificação tributária correspondente.

Por que isso vira passivo de conciliação, não erro pontual

Quando a apuração assistida finalmente cruza o volume de documentos contra a exigência legal, o que aparece não é um erro isolado. É um padrão de preenchimento repetido em série, que precisa ser reconciliado retroativamente, documento a documento, para sustentar a apuração diante de qualquer questionamento posterior, seja de auditoria interna, seja de fiscalização. Numa base com volume mensal relevante, isso significa revisitar manualmente cada documento emitido desde agosto que passou pela regra de default, um a um, para reconstruir a justificativa que deveria ter existido na emissão, e não existe atalho automatizado para essa reconstrução retroativa.

Um teste de amostra que não depende da rejeição voltar

A forma prática de não esperar a Receita decidir reativar a UB12-10 é tratar a verificação como rotina de auditoria por amostra, não como evento dependente de validação externa. Isso significa selecionar um recorte de NF-e emitidas desde agosto, cruzar o grupo IBSCBS efetivamente gravado contra o que a regra de determinação deveria ter produzido, e isolar os casos em que o valor saiu por default em vez de por regra.

O dado que importa não é se o documento foi aceito. É quantos tiveram o campo preenchido por regra de negócio reconhecida e quantos porque nenhuma regra específica se aplicou e o sistema usou o valor padrão. Essa distinção não aparece em relatório padrão do SAP: exige cruzar o log de determinação tributária contra o resultado gravado no documento, incluindo revisar a condição de cálculo correspondente em FTXP para confirmar se a regra realmente cobria o cenário, operação que hoje provavelmente não está documentada em lugar nenhum e depende de quem conhece a árvore de determinação original.

Onde parametrizar antes que a amostra vire auditoria externa

A correção de causa raiz está na revisão da árvore de determinação do tax code e do cClassTrib dentro do motor fiscal, cenário por cenário, com atenção aos processos criados ou alterados depois da parametrização original do projeto. Não é ajustar um campo manualmente em nota já emitida. É garantir que a regra, e não o default, resolva o caso antes de o documento sair, o que exige mapear exceções como trabalho contínuo, não projeto fechado em uma data.

O monitoramento contínuo de mudança fiscal é o que normalmente sustenta essa revisão sem depender de um evento de rejeição para forçar a reparametrização. Se essa lacuna chegar sem tratamento ao fechamento do próximo trimestre, o risco deixa de ser só operacional: vira item que o parecer de auditoria externa pode qualificar, porque a mesma obrigação que uma companhia aberta já reconheceu em nota de resultado passa a ter um dado de origem que ninguém confrontou contra a regra.

A evidência que precisa ficar arquivada para sustentar a amostra diante de qualquer fiscalização futura é a tríade completa por documento selecionado: o log de determinação tributária, a regra de negócio que deveria ter se aplicado ao cenário e, quando houver divergência, o parecer técnico que justifica por que ela ocorreu. Sem essa tríade documentada, a amostra prova que o problema existe, mas não prova que a empresa tratou cada caso com critério.

A pergunta que fica, e que cada operação deveria conseguir responder hoje, sem esperar a próxima nota técnica: quantos documentos fiscais eletrônicos de 2026 saíram com o grupo IBSCBS determinado por regra de negócio real, e quantos porque nenhuma regra cobria o caso e o sistema resolveu sozinho.

Na DFSpro, o primeiro passo é sempre um diagnóstico real. Se essa pergunta ainda não tem resposta na sua operação, pode ser o momento certo para um Diagnóstico Fiscal Estruturado.