Rejeição 1115 na NF-e: o que o Portal da NF-e diz e o que testar no SAP

Se a rejeição 1115 não barra a nota, a obrigação que ela protegia continua. A validação técnica UB12-10 (rejeição 1115, "Grupo IBSCBS não informado"), da Nota Técnica 2025.002-RTC v1.52, barra a NF-e emitida sem o grupo IBSCBS no item. O texto do Ato Técnico Conjunto nº 1/2026 não cita a UB12-10, e a NT traz, para a regra, datas de produção (03/08/2026 para o regime normal, 04/01/2027 para Simples Nacional e MEI) junto de uma frase de "implementação futura para produção" que não diz a que se aplica. Isso não muda a obrigação de destacar CBS e IBS nos documentos fiscais eletrônicos aplicáveis, vigente desde 3 de agosto. Se a rejeição não estiver ativa no seu autorizador, o SAP pode emitir nota com o campo errado sem que nada acuse. 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.

O que a Nota Técnica previa

O Ato Técnico Conjunto nº 1/2026 aprova a NT 2025.002 v1.51, cujo histórico registra "alteração do cronograma de implantação das regras de validação UB12-10", mas não usa a palavra suspensão.

O resultado é que parte do mercado fiscal ainda trata agosto como a data de atenção, enquanto, se a rejeição não estiver ativa no autorizador, o sistema não bloqueia a nota. 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 nº 1/2026 não cita a UB12-10 pelo nome. Se a rejeição passar a valer sem aviso prévio, qualquer nota emitida por default desde agosto pode ser questionada 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

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

Na leitura da DFSpro, 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.

Em "SPED do período", a falha costuma morar na rotina, e não no documento. Quando o fechamento só fecha com ajuste manual, a causa está na regra que alimentou o período, não no último dia. Esse padrão tem nome: problema do fechamento fiscal.

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 depender de a rejeição UB12-10 barrar a nota é 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 exige cruzar a determinação tributária de cada documento contra o resultado gravado, incluindo revisar a condição de cálculo correspondente em FTXP para confirmar se a regra realmente cobria o cenário.

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 registro da 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.

Sobre "Onde parametrizar antes que a amostra vire auditoria externa", o seu time consegue provar hoje o que está certo em "SPED do período"? Um primeiro passo sem compromisso: autoavaliação de prontidão fiscal SAP.