NFS-e com IBS e CBS: o campo que a classificação de produto vai expor a partir de outubro

A partir de 1º de outubro de 2026, a NFS-e dos serviços também sujeitos ao ISS, fora dos itens que já tinham regra própria na Lei Complementar nº 116, passou a exigir os campos de IBS e CBS. Isso não é um ajuste de leiaute. É um teste de cadastro. Toda nota emitida depois dessa data obriga o sistema a responder, produto a produto, uma pergunta que a maioria das operações de serviço nunca formalizou: qual documento fiscal sustenta essa receita, e com base em que regra o cadastro decidiu isso. A resposta não está na legislação. Está no SAP.

O calendário que chegou na NFS-e

O Ato Conjunto RFB/CGIBS nº 4, de 30 de julho de 2026, define o cronograma de entrada em vigor dos campos de IBS e CBS nos documentos fiscais eletrônicos. Para os fornecimentos de serviços também sujeitos ao ISS, enquadrados na lista anexa à Lei Complementar nº 116 de 2003 e fora das alíneas que já tinham tratamento específico, a data definida é 1º de outubro de 2026. O Ato Técnico Conjunto RFB/SUFIS/CGIBS nº 7, de 28 de setembro de 2026, aprovou a documentação técnica correspondente: a Nota Técnica SE/CGNFS-e nº 009 na versão que trata dos leiautes e das regras de negócio da NFS-e, fechando o padrão que o emissor precisa atender campo a campo.

O ponto que costuma passar despercebido é que o calendário não cria uma obrigação nova de classificar. Ele só torna visível uma classificação que já precisava existir. Antes de outubro, um erro de enquadramento ficava absorvido pela margem de tolerância do sistema antigo. Depois de outubro, o mesmo erro aparece como campo de IBS ou CBS preenchido com a regra errada, numa nota que vai para o município ou para o comitê gestor com o carimbo de que foi revisada.

Em operações com receita de serviço diversificada, isso tende a pesar mais em uma linha específica: a de serviços de valor agregado, onde o mesmo produto pode, a depender da leitura contratual, caminhar tanto pela tributação de comunicação quanto pela de serviço. É exatamente aí que a pergunta de outubro aperta.

O prazo não pergunta se a empresa está pronta. Pergunta se o cadastro já estava certo antes da pergunta existir.

NFCom ou NFS-e: o critério não está na nota, está no cadastro

Em operadoras e prestadoras de serviço de valor adicionado, a receita de SVA convive, na mesma estrutura comercial, com produtos que têm natureza jurídica diferente. Parte pode caracterizar serviço de comunicação, sujeito à NFCom. Parte pode caracterizar prestação de serviço na forma da lista da LC 116, sujeita à NFS-e. A distinção entre os dois documentos não é estilística: é a distinção entre dois regimes de tributação diferentes, com campos, regras de validação e destinos de arrecadação diferentes.

O problema é que, no SAP, essa decisão normalmente não mora num único lugar visível. Ela mora espalhada entre o cadastro de material ou serviço, a condição de preço, o grupo de impostos no registro de cliente e a regra de determinação de imposto configurada no SD. Quando o time fiscal muda de pessoa, ou quando um produto novo entra no catálogo comercial sem passar pela mesma régua dos produtos antigos, a decisão para de ser auditável. Ela continua existindo, só que decidida por default de sistema, não por critério documentado.

Em operações com catálogo de serviço maduro, o padrão tende a se repetir: parte dos itens tem regra fiscal explícita e revisada; parte herdou a regra do item anterior na mesma família, sem ninguém reconfirmar se ainda fazia sentido. Cada campo de imposto no cadastro de material carrega uma decisão. A maioria delas nunca foi tomada por ninguém vivo.

Na prática, o grupo de impostos de um material costuma ser copiado de um produto parecido no momento da criação, um atalho razoável quando o catálogo é pequeno. O problema aparece quando o catálogo cresce por aquisição de carteira, reposicionamento comercial ou criação de pacotes combinando voz, dados e conteúdo. Cada cópia herda o erro da anterior, e nenhum relatório do SAP aponta isso como inconsistência, porque tecnicamente a nota sai sem erro de sintaxe. O erro é de substância, não de formato, e por isso não aparece em nenhum log padrão.

Por que a classificação histórica não é prova de classificação correta

Um argumento comum nesse momento é "sempre emitimos assim, nunca deu problema". Isso prova continuidade, não prova correção. A continuidade de um cadastro fiscal não é feita por revisão recorrente, é feita por inércia: uma vez configurado, o sistema repete a regra indefinidamente, até alguém mudar manualmente. Ausência de erro reportado não é o mesmo que ausência de erro.

O ponto cego fica mais evidente quando o produto muda de característica comercial sem que o cadastro acompanhe. Um serviço de valor agregado que começou como complemento de um plano de voz pode, anos depois, ter migrado para uma oferta empacotada de dados, conteúdo e suporte técnico. A natureza jurídica da receita pode ter mudado. A régua fiscal, em muitos casos, não acompanhou, porque não existe gatilho automático que force a revisão quando o time comercial reposiciona um produto.

A Reforma não cria esse risco. Ela expõe um risco que já existia, só que antes ficava absorvido pela convivência entre dois regimes antigos, ICMS sobre comunicação e ISS sobre serviço, que já tinham zonas de fronteira discutíveis. A partir de outubro, cada nota emitida carrega um campo adicional, de IBS ou de CBS, que depende diretamente de qual documento foi escolhido. Dois regimes de fronteira incerta agora alimentam um terceiro sistema desenhado para precisão, não para ambiguidade.

Sistema novo, dúvida antiga. A Reforma herdou o problema que ninguém resolveu antes dela.

Há ainda uma camada que raramente entra na conversa: a versão do SAP e do módulo de faturamento em uso. Operações que ainda rodam em ECC, com regras de determinação fiscal configuradas há anos em transações como FTXP e nas tabelas de condição do SD, tendem a ter menos rastreabilidade sobre quem alterou o quê e quando, porque o histórico de mudança de configuração fiscal raramente é tratado com o mesmo rigor que o histórico de alteração de preço ou de crédito.

O que o mercado costuma fazer, e por que não resolve

A resposta mais comum a um prazo como esse é tratá-lo como projeto de integração: ajustar o leiaute, testar o envio, confirmar que a nota sai sem erro de schema. Isso resolve o problema técnico de transmissão e não toca o problema de classificação. Uma nota pode sair tecnicamente perfeita, aceita pelo ambiente nacional, com todos os campos de IBS e CBS preenchidos, e ainda assim estar classificada no documento errado, porque o cadastro de origem já estava errado antes do projeto começar.

O resultado típico desse atalho é descobrir o problema tarde: quando a prefeitura questiona por que uma receita que parece serviço de comunicação está sendo recolhida como ISS, ou quando o comitê gestor do IBS cruza dados entre documentos e identifica inconsistência entre o que a empresa emitiu como NFCom e o que emitiu como NFS-e para produtos de características semelhantes. Nesse ponto, a correção deixa de ser ajuste de cadastro e vira explicação de histórico.

Projeto de TI testa o envio. Ninguém testa a premissa por trás do envio.

Vale notar que o ambiente nacional de documentos fiscais, construído sobre a mesma espinha dorsal que recebe NFCom, NFS-e e NF-e, foi desenhado justamente para permitir esse tipo de cruzamento entre documentos de uma mesma empresa. O que antes exigia fiscalização física, comparar notas em papel ou em sistemas separados, hoje é consulta direta de banco de dados. Isso encurta o intervalo entre o erro de classificação e a pergunta formal sobre ele.

A matriz que falta, e quem precisa assinar essa decisão

O que resolve esse ponto cego não é um projeto de TI, é uma matriz de decisão por produto, documentada e rastreável. Para cada item do catálogo de serviço, o cadastro precisa registrar quatro informações juntas: o produto, o documento fiscal correspondente, NFCom ou NFS-e, o tributo incidente na transição, e a regra ou base legal que sustenta essa escolha. Sem essa matriz, qualquer resposta a uma autuação ou a um questionamento municipal vira reconstrução de memória, não consulta a registro.

A pergunta certa não é "o SVA é tributado por ISS ou por ICMS de comunicação". Essa decisão é do cliente, e depende da natureza jurídica de cada contrato e de cada oferta comercial, não do sistema. A pergunta que o sistema precisa responder é outra: para cada produto do catálogo, existe hoje um registro explícito de qual documento o sustenta, quem tomou essa decisão e quando ela foi revisada pela última vez. Se a resposta for "não sabemos ao certo", o risco não está na alíquota. Está na ausência de prova de que a classificação foi uma decisão, e não um acidente de configuração herdado.

Construir essa matriz é trabalho de leitura de cadastro, não de parametrização nova. Significa extrair, do SAP SD e FI e do faturador que gera a nota, todos os grupos de impostos e condições ativas por produto, cruzar com o enquadramento declarado em cada contrato comercial, e expor as divergências antes que elas apareçam como inconsistência num cruzamento de dados do comitê gestor.

Essa leitura revela um segundo tipo de divergência, menos discutido: produtos com o mesmo código de material usados em contratos com cláusulas comerciais diferentes, onde a natureza do serviço prestado varia conforme o pacote vendido ao cliente final. Nesse cenário, o cadastro de material sozinho não basta: a regra de determinação precisa considerar também o tipo de contrato ou a condição comercial associada, o que exige revisar a lógica de determinação de imposto no SD, não apenas o dado estático do material.

Uma tabela não decide tributo. Uma tabela prova que alguém decidiu.

O ponto que a área fiscal sozinha não resolve é quem detém a autoridade de mudar a classificação de um produto depois que ela está registrada na matriz. Hoje, em muitas operações, essa mudança acontece no comercial, quando um produto é reposicionado, sem passagem formal pelo fiscal. A matriz só funciona se existir um dono nomeado para essa decisão, com um processo mínimo de revisão sempre que um produto for lançado, reposicionado ou descontinuado.

Isso não é burocracia adicional. É a diferença entre uma operação que sabe explicar por que cada nota saiu do jeito que saiu, e uma operação que descobre a explicação no mesmo dia em que precisa apresentá-la a um auditor. Esse dono não precisa ser um cargo novo. Pode ser uma responsabilidade adicionada a uma função fiscal já existente, desde que o processo de lançamento de produto no catálogo comercial passe, formalmente, por essa validação antes de ir para produção no SAP.

O custo de inserir esse passo é baixo. O custo de não inserir aparece meses depois, numa planilha de reconciliação tentando explicar por que dois produtos parecidos foram tratados de formas diferentes.

O que verificar antes de fechar outubro

Antes de considerar o ajuste de outubro concluído, vale confirmar cinco coisas no próprio sistema, não na intenção do projeto. Primeiro, se existe hoje uma lista única, e não uma reconstrução feita às pressas, de todos os produtos de serviço com o documento fiscal correspondente e a regra que sustenta essa escolha. Segundo, se os produtos que mudaram de característica comercial nos últimos anos tiveram o cadastro fiscal revisado na mesma época, ou se carregam ainda a regra original.

Terceiro, se existe um responsável nomeado, não uma área genérica, para aprovar qualquer mudança futura de classificação antes que ela entre em produção. Quarto, se o processo de criação de produto novo no catálogo comercial inclui uma etapa de validação fiscal, ou se o cadastro é liberado com base em cópia de um item parecido. Quinto, se a equipe fiscal consegue extrair em poucas horas a lista completa de produtos e suas regras vigentes, ou se essa extração depende de conhecimento informal de quem configurou o sistema originalmente.

Nenhuma dessas cinco verificações exige escolha tributária. Exigem leitura de cadastro, disciplina de documentação e clareza de responsabilidade. É exatamente o tipo de trabalho que o Diagnóstico Fiscal Estruturado da DFSpro foi desenhado para fazer: mapear a matriz real de produto, documento e tributo no SAP e no faturador, expor onde a regra está implícita em vez de registrada, e devolver ao cliente uma base que ele consegue defender, sem decidir por ele qual é o enquadramento tributário correto.