A rejeição automática da NFCom sem os campos de IBS e CBS foi dispensada. A obrigação de informar esses tributos não foi. Essa diferença, que parece sutil em um comunicado técnico, é exatamente o que separa uma empresa de telecomunicações em conformidade de uma com passivo silencioso acumulando desde outubro. O sistema aceita a nota. O Fisco não esquece o campo vazio.
Em operadoras de telecomunicações, o padrão mais provável não é o campo totalmente vazio. É o campo preenchido com um valor que parece certo, herdado de uma tabela de classificação fiscal pensada para ICMS e PIS/COFINS, nunca revisada para IBS e CBS.
É engenharia de validação em duas camadas que o mercado está lendo como uma só.
A linha do tempo que criou essa confusão
Em 30 de julho de 2026, a Receita Federal e o Comitê Gestor do IBS publicaram o Ato Conjunto RFB/CGIBS nº 4. O texto lido por inteiro fixa, no art. 1º, inciso X, a obrigatoriedade de emissão do documento fiscal eletrônico da NFCom, modelo 62, com os campos de IBS e CBS, a partir de 1º de outubro de 2026. Um dia depois, 31 de julho, o Ato Técnico Conjunto nº 1 aprovou a documentação técnica que regula essas especificações, incluindo a Nota Técnica 2026.002 em sua versão 1.01.
Isso não nasceu em 2026. A NFCom já era obrigatória em produção desde 1º de novembro de 2025, conforme publicado em portal estadual de Secretaria da Fazenda. O que mudou em outubro de 2026 não foi o documento fiscal em si, foi a camada de tributos da Reforma embutida nele. Uma operadora de telecomunicações que já emite NFCom para banda larga e serviços de valor agregado desde 2025 está lidando, agora, com uma segunda exigência sobreposta à primeira: os mesmos documentos, com campos novos, regidos por uma nota técnica que muda a estrutura de validação.
Duas obrigações, dois calendários, uma única nota fiscal no meio.
O que a dispensa de rejeição realmente dispensa
Um escritório de advocacia publicou, em 10 de agosto de 2026, uma análise sobre a flexibilização das validações dos documentos fiscais eletrônicos na Reforma Tributária. O trecho relevante, lido integralmente: "Embora as notas fiscais sem o preenchimento dos campos de IBS e CBS continuem sendo autorizadas, a obrigação de informar esses tributos permanece vigente." Duas frases, duas obrigações diferentes. A primeira é sobre o que o sistema de validação da Receita aceita no momento da emissão. A segunda é sobre o que a empresa deve entregar à base de dados do Fisco, independentemente de a nota ter sido rejeitada ou não.
Dispensar a rejeição automática não é o mesmo que dispensar a escrituração correta. É um prazo de adaptação técnica, não um perdão fiscal. A nota técnica de validação completa da NFCom, que faria o sistema recusar automaticamente documentos com campos de IBS e CBS ausentes ou inconsistentes, ainda não foi aberta em produção. Isso significa que, hoje, uma nota pode sair autorizada com o campo de IBS zerado, com a CBS ausente, ou com uma combinação de alíquota e código de classificação que não bate com a operação real. O sistema não vai barrar. O cruzamento posterior da Receita com a base do CGIBS, sim.
Ato Conjunto RFB/CGIBS nº 4, de 30 de julho de 2026, art. 1º, inciso X: "NFCom, modelo 62: 1º de outubro de 2026".
O risco não é a rejeição que não aconteceu em outubro. É a inconsistência que foi autorizada, entrou na base, e que a empresa vai precisar retificar até 31 de dezembro de 2026 para seguir no programa de conformidade. O que hoje é um campo vazio sem alarde algum se torna, no fechamento do ano, uma pendência de regularização sob prazo. Regularizar centenas ou milhares de notas de outubro em dezembro custa mais caro, em horas de equipe fiscal e de TI, do que ter acertado o parâmetro desde o primeiro dia.
Cuidado com uma leitura precipitada aqui: não há, nas fontes oficiais lidas, qualquer indicação de que a NFCom "será rejeitada" quando a validação completa entrar em vigor. A flexibilização relatada é descrição de escritório de advocacia sobre o estado atual, não antecipação de um evento futuro certo. O que é fato, hoje, é que a obrigação de informar está vigente e o campo errado vira inconsistência a resolver, com ou sem rejeição automática.
Por que isso recai sobre o SAP, e não sobre a SEFAZ
A NFCom não nasce na interface de emissão. Ela nasce no faturamento. Em operações de telecomunicações rodando SAP S/4HANA, o módulo de Sales and Distribution registra o contrato de banda larga ou SVA, aplica a tabela de condições de preço e tributo, e entrega esse resultado ao módulo de Finanças para a geração do documento fiscal. Os campos de IBS e CBS não aparecem na nota por mágica: eles dependem de parametrização de tabela de classificação fiscal, de regra de determinação de imposto e de integração correta entre o módulo de faturamento e o emissor de NFCom, seja ele nativo do SAP ou um componente de terceiros acoplado ao processo.
Se a tabela de classificação não foi atualizada com os novos códigos da Reforma, ou se a regra de determinação de imposto ainda aponta para uma lógica pensada só para ICMS e PIS/COFINS, o sistema vai gerar a nota, vai calcular o que sabe calcular, e vai deixar os campos de IBS e CBS com valor zero ou ausente. A nota sai. É autorizada. Ninguém no faturamento percebe nada de errado porque, tecnicamente, nada travou.
É o tipo de falha que não aparece em nenhum dashboard operacional. Aparece quando alguém cruza a base de notas emitidas com a base declarada ao CGIBS, e os números de IBS e CBS não fecham.
Há ainda uma camada que raramente entra na conversa sobre NFCom, e que vimos repetir em mais de uma operação de telecomunicações com franquia de dados e pacote promocional combinados na mesma fatura: contratos de SVA costumam atravessar mais de uma condição de preço, e cada condição pode estar vinculada a uma regra de determinação de imposto diferente dentro do SAP. Basta uma delas não ter sido revisada para a nota sair com IBS e CBS corretos em uma linha e ausentes em outra, na mesma fatura, para o mesmo cliente. Esse tipo de inconsistência parcial é mais difícil de detectar do que um campo totalmente vazio, porque a nota "parece" correta à primeira vista, e foi justamente esse tipo de parcela que mais vezes escapou da primeira rodada de revisão nos casos que acompanhamos.
A pergunta que poucos times fiscais estão fazendo agora
Se a Receita cruzasse hoje as notas de outubro de uma operadora de banda larga e SVA com a base de informações do CGIBS, quantas delas sairiam com IBS e CBS ausentes ou inconsistentes? E, mais importante: quem dentro da empresa teria como responder essa pergunta com uma consulta no SAP, sem depender de uma extração manual de dados feita sob pressão?
Essa é a pergunta executiva real por trás do comunicado técnico. Não é "estamos emitindo a NFCom". É "estamos emitindo a NFCom com os campos certos, e temos como provar isso com uma amostra auditável, antes que o Fisco peça".
Quem só tem a primeira resposta pronta ainda não mediu o próprio risco.
Medindo a qualidade de campo nas notas de outubro
Medir qualidade de dado fiscal não é olhar se a nota foi autorizada. É comparar, nota a nota, o que foi emitido contra o que a Nota Técnica 2026.002 exige como estrutura de campo. Isso envolve, no mínimo, três verificações sobre uma amostra representativa do volume de outubro: primeiro, se o campo de IBS e o campo de CBS estão preenchidos em todas as notas de faturamento recorrente, não só nas emitidas manualmente; segundo, se a tabela de classificação fiscal usada bate com a tabela oficial vigente na data de emissão, já que atos técnicos da Reforma têm sido revisados em ciclos curtos; terceiro, se o valor calculado de IBS e CBS é compatível com a operação de telecomunicações declarada, e não um valor padrão herdado de uma parametrização genérica copiada de outro ramo de atividade.
Vale acrescentar um quarto ponto, menos óbvio, e que normalmente escapa da primeira revisão: a amostra precisa cobrir também as notas de ajuste e de cancelamento emitidas no mesmo período, não só as faturas regulares. É comum que o processo de parametrização trate a nota principal com cuidado e deixe o fluxo de complementar ou de estorno rodando na regra antiga, porque ninguém lembrou de replicar o ajuste nesses caminhos secundários do SAP.
Uma nota autorizada e uma nota correta são coisas diferentes, e só a segunda sobrevive a uma auditoria. O trabalho de conferência não substitui o trabalho de parametrização. Ele serve para encontrar, antes de dezembro, onde a parametrização já falhou sem avisar.
Quem é dono do campo: Fiscal, TI e faturamento
Esse é o ponto onde a maioria das operações trava, e não é um ponto técnico. É um ponto de governança. O campo de IBS e CBS na NFCom nasce de uma regra fiscal, passa por uma parametrização de sistema, e sai dentro de um processo de faturamento que raramente tem o time fiscal olhando nota a nota. Quando a nota sai errada, a primeira pergunta que qualquer diretor fiscal vai ouvir é "quem configurou isso". E a resposta honesta, na maior parte das operações que ainda não revisaram esse fluxo desde a publicação dos atos de julho, é que ninguém tem clareza sobre isso hoje.
O time fiscal entende a regra, mas não necessariamente valida a parametrização técnica. O time de TI mantém o sistema rodando, mas não decide qual alíquota ou código de classificação deveria estar ali. O faturamento só processa o que o sistema entrega. Essa divisão de responsabilidade, que funciona bem quando a regra tributária é estável, vira um ponto cego exatamente quando a regra muda rápido, como está mudando agora com a coexistência entre o sistema antigo e o novo regime de IBS e CBS.
Três times, três responsabilidades parciais, nenhum dono do campo inteiro.
Decidir a tese tributária, como o alcance exato do art. 1º, inciso X, para um caso concreto de SVA ou de pacote combinado, é trabalho do cliente e do seu corpo jurídico tributário. O papel de quem desenha e sustenta o SAP é garantir que, uma vez tomada essa decisão, ela esteja refletida com consistência em cada nota emitida, e que exista uma forma auditável de provar isso.
O que fazer antes que a flexibilização termine
A nota técnica de validação completa não vai ficar suspensa indefinidamente. Quando ela entrar em vigor, a rejeição automática volta, e aí o custo de corrigir parametrização sob pressão de produção é maior do que corrigir agora, com tempo e sem a urgência de uma nota travada no meio do faturamento mensal. O intervalo criado pela dispensa de rejeição é uma janela de trabalho, não uma pausa.
O Diagnóstico Fiscal Estruturado da DFSpro parte exatamente desse ponto: conferir uma amostra de NFCom de outubro contra a Nota Técnica 2026.002 e as tabelas oficiais vigentes, e identificar onde os campos de IBS e CBS estão ausentes ou inconsistentes, para que a correção aconteça por escolha, e não sob prazo. A DFSpro desenha, configura e prova o comportamento do SAP e do Guepardo diante de documentos fiscais eletrônicos; a decisão sobre a tese tributária aplicável a cada cenário de faturamento continua sendo do cliente.
TAKEAWAYS
- A dispensa de rejeição automática da NFCom é um prazo técnico de adaptação, não uma dispensa da obrigação de informar IBS e CBS, que segue vigente desde 1º de outubro de 2026.
- O padrão mais provável não é o campo vazio, é o campo preenchido com valor herdado de tabela de classificação nunca revisada para IBS e CBS.
- A inconsistência que hoje passa sem rejeição vira pendência de retificação com prazo até 31 de dezembro de 2026 para a empresa seguir no programa de conformidade.
- O campo de IBS e CBS na NFCom depende de parametrização de tabela de classificação fiscal e de integração entre faturamento e emissor no SAP, incluindo notas de ajuste e cancelamento, não só a fatura principal.
- Sem um dono claro do campo entre Fiscal, TI e faturamento, a janela aberta pela flexibilização se fecha sem que a operação tenha corrigido nada.
Head of Business, DFSpro, Curitiba, 2026
Especialista em estratégia B2B para operações fiscais críticas em SAP e Guepardo Tax. Atua na interface entre governança fiscal, tecnologia e decisão executiva.
DFSpro, estabilidade fiscal em SAP e Guepardo Tax.