BRASÍLIA/DF — Uma empresa que decide informar voluntariamente os campos do Imposto sobre Bens e Serviços (IBS) e da Contribuição sobre Bens e Serviços (CBS) na Nota Fiscal de Serviço eletrônica (NFS-e) pode ter a emissão impedida se deixar incompletos os dados do adquirente ou destinatário exigidos pela operação. A orientação foi reafirmada pelo Comitê Gestor da NFS-e em comunicado publicado em 29 de outubro de 2026 e esclarece uma dúvida recorrente entre contadores, prestadores de serviços e desenvolvedores de sistemas.
O ponto central é a diferença entre não informar o grupo tributário e informá-lo de maneira incompleta. O Ambiente de Dados Nacional (ADN) foi ajustado para não rejeitar a NFS-e somente pela ausência de IBS/CBS. Entretanto, quando o contribuinte opta pelo preenchimento, os códigos, classificações e informações relacionadas passam pelas verificações técnicas correspondentes. Isso inclui a identificação do adquirente ou destinatário sempre que o tipo de operação exigir esses dados.
A NFS-e será rejeitada se faltar o adquirente após informar IBS e CBS?
Sim, a rejeição é possível quando o leiaute e as regras de validação aplicáveis exigem a identificação e o contribuinte transmite os dados de IBS e CBS sem completar as informações correspondentes. O comunicado oficial não afirma que toda NFS-e precisa identificar um destinatário separado, nem estabelece uma rejeição automática para qualquer campo vazio. A exigência depende da operação representada no documento.
Assim, a pergunta correta não é apenas se os novos tributos foram informados. O emissor precisa verificar quem contratou o serviço, quem figura como adquirente e se existe destinatário distinto que deva ser identificado. Quando essas informações são exigíveis, deixar o cadastro incompleto pode impedir a autorização ou a recepção válida do documento, conforme o ponto em que a verificação ocorre.
Por que informar IBS e CBS voluntariamente ativa novas validações?
A flexibilização anunciada pelo Comitê Gestor busca evitar paralisações durante a adaptação à reforma tributária. Para isso, a ausência do grupo IBS/CBS foi tratada de maneira diferente de um grupo efetivamente transmitido. Uma vez fornecida a informação tributária, o sistema precisa verificar se ela respeita os tipos de dados, códigos e dependências previstas na versão técnica utilizada.
Qual é a diferença entre tomador, adquirente e destinatário na NFS-e?
O tomador é a pessoa identificada na contratação ou tomada do serviço, segundo as regras aplicáveis ao documento. O adquirente é o sujeito considerado na operação para os fins tributários pertinentes ao IBS e à CBS. Já o destinatário pode representar a pessoa ou o estabelecimento ao qual o fornecimento se destina, quando essa identificação for distinta e exigida.
Receba as principais novidades da Reforma Tributária
Cadastre seu e-mail para acompanhar as mudanças mais importantes.
A correta representação depende do fato real e do leiaute aplicável. As evoluções da Nota Técnica nº 009 reorganizam os campos ligados ao destinatário, mas sua implementação é gradual. Por isso, não se deve aplicar prematuramente um caminho de XML previsto para testes a documentos enviados ao ambiente de produção.
É possível emitir a NFS-e sem preencher o grupo IBS/CBS?
Do ponto de vista da validação técnica específica do ADN, sim: o Comitê Gestor informou que a ausência do grupo de IBS e CBS, isoladamente, não provoca rejeição, inclusive para contribuintes enquadrados em obrigações de informação. Essa medida preserva a continuidade operacional durante a transição dos sistemas fiscais.
Contudo, nota autorizada não significa necessariamente obrigação fiscal cumprida. A orientação de 7 de agosto de 2026 esclarece que a omissão das informações exigíveis pode caracterizar desconformidade, observadas as normas e os prazos aplicáveis a cada contribuinte. Não é correto aconselhar uma empresa a retirar o grupo de IBS/CBS somente para contornar um erro, quando ela já está legalmente obrigada a prestar as informações.
Quais informações precisam ser conferidas antes de enviar a DPS?
A Declaração de Prestação de Serviços (DPS), utilizada no processo de geração da NFS-e, deve representar corretamente as pessoas envolvidas e o tratamento tributário. Antes do envio, o emitente deve conferir a identificação do prestador, os dados exigíveis do tomador ou adquirente, a eventual existência de destinatário distinto e os códigos utilizados no grupo de IBS/CBS.
Também é necessário validar a classificação tributária informada, os indicadores da operação e a compatibilidade entre os grupos presentes. O preenchimento de um campo pode tornar outro obrigatório ou impedir determinada combinação, conforme a tabela de regras da versão em produção. Não existe uma lista única de campos que se aplique indistintamente a todos os tipos de serviço.
Como corrigir a rejeição por falta dos dados do adquirente?
O primeiro passo é guardar a mensagem de retorno e identificar em qual etapa ocorreu o bloqueio: no próprio emissor, na integração municipal ou na comunicação com o ambiente nacional. Em seguida, o contador deve revisar a DPS original e confirmar se o grupo IBS/CBS foi enviado voluntariamente ou por obrigação aplicável ao contribuinte.
Depois, é preciso identificar quem efetivamente adquire o serviço e se existe destinatário distinto. Se a operação exige dados adicionais, eles devem ser completados no cadastro e refletidos corretamente no documento. É necessário conferir também os códigos tributários e demais informações vinculadas, porque a mensagem exibida pelo software pode ser consequência de mais de uma inconsistência.
Exemplo prático: empresa preenche tributos e deixa destinatário obrigatório em branco
Imagine uma prestadora de serviços que ainda esteja em fase de adaptação e decida antecipar o envio das informações de IBS e CBS. O programa gera a DPS com os códigos tributários, mas classifica a operação de maneira que exige identificação adicional do destinatário, deixando os dados correspondentes vazios.
Nessa hipótese, é possível que a validação impeça o processamento até que a identificação exigida seja informada corretamente ou que a classificação da operação, se incorreta, seja corrigida. Não se deve concluir, apenas por esse exemplo, que todas as notas destinadas ao consumidor final necessitam de um destinatário separado do tomador.
Outro cenário é a prestação em que tomador, adquirente e destinatário coincidem e o leiaute permite representar essa condição sem cadastro adicional. Nesse caso, não cabe exigir artificialmente uma terceira pessoa. A conclusão depende dos indicadores e das regras efetivamente implementadas no ambiente de emissão.
O problema também ocorre em emissores municipais próprios?
Sim. O comunicado de 29 de outubro esclarece que as mesmas diretrizes de validação alcançam municípios com emissores próprios integrados ao ADN. Uma prefeitura não deve interpretar a flexibilização como autorização para transmitir grupos tributários preenchidos pela metade ou incompatíveis com a estrutura nacional.
Para desenvolvedores de sistemas municipais e fornecedores de software, isso implica revisar a montagem do XML, testar as dependências entre informações cadastrais e tributárias e apresentar mensagens de erro compreensíveis. Um cadastro municipal que sempre foi suficiente para calcular o ISS pode exigir conferências adicionais quando se pretende representar corretamente uma operação envolvendo IBS e CBS.
O que muda para empresas que emitem NFS-e por API?
Empresas com alto volume de notas e escritórios que utilizam ERPs precisam tratar o preenchimento como uma validação de conjunto, não como a simples inclusão de duas novas tags. A aplicação deve verificar se o grupo IBS/CBS está presente e, quando estiver, quais informações relacionadas passam a ser exigidas para aquele tipo de operação.
Um procedimento prudente inclui testar cenários com e sem o grupo tributário, operações em que as pessoas envolvidas coincidem e situações em que há destinatário distinto. Os testes devem ocorrer na versão de esquema compatível com o ambiente usado. Mensagens de retorno, arquivos XML e versões de leiaute precisam ser registrados para facilitar o diagnóstico.
Evitar o envio de campos vazios não significa apagar dados exigíveis. O sistema deve distinguir entre informação realmente não aplicável e informação obrigatória que ainda não foi coletada do cliente. Essa distinção reduz rejeições e melhora a qualidade fiscal dos documentos autorizados.
A Nota Técnica 009 já substituiu integralmente a NT 004 em produção?
Não. Na orientação de 29 de outubro, o Comitê Gestor informou que o ambiente oficial de produção utilizava a estrutura da Nota Técnica nº 004, com complementação da NT nº 007. As versões da NT nº 009 estavam sendo implantadas gradualmente, primeiro em produção restrita, sem efeitos fiscais para os testes.
O cronograma então divulgado previa disponibilizar os primeiros releases em produção até 1º de dezembro de 2026. Essa previsão precisa ser acompanhada nos comunicados oficiais antes de qualquer atualização de integração. Uma funcionalidade já existente no ambiente de testes não pode ser presumida como disponível na emissão fiscal definitiva.
A distinção é particularmente importante para os campos de identificação de participantes e para as posições de CST e cClassTrib no XML. A documentação futura pode reorganizar a estrutura, mas o emissor precisa respeitar o padrão efetivamente habilitado no momento de transmitir a DPS.
O que o contador deve orientar ao cliente para evitar novas rejeições?
A principal orientação é revisar o cadastro de tomadores e a natureza de cada prestação antes da emissão. Empresas que anteciparam o preenchimento de IBS/CBS devem verificar se a informação cadastral coletada corresponde às exigências adicionais do documento. Isso vale tanto para notas geradas manualmente quanto para notas transmitidas por integração.
Também convém manter um registro de erros, acompanhar as atualizações das notas técnicas e distinguir falhas cadastrais de incompatibilidades de códigos tributários. Em caso de dúvida sobre a pessoa que deve constar como adquirente ou destinatário, a resposta precisa considerar os contratos e a operação efetiva, não apenas o nome apresentado na tela do programa.
A conclusão é direta: a flexibilização concedida para a ausência de IBS/CBS não protege o contribuinte de erros no preenchimento voluntário. Quando a operação requer dados do adquirente ou destinatário, esses dados devem estar completos e consistentes. A adaptação à reforma tributária exige conferir tanto os tributos quanto a identificação correta das pessoas envolvidas.
Fontes oficiais consultadas
3. Portal Nacional da NFS-e — Ato Técnico Conjunto nº 7 e aprovação da NT 009, versão 1.01
4. Portal Nacional da NFS-e — Biblioteca de documentação técnica da Reforma Tributária do Consumo
5. Portal Nacional da NFS-e — Documentação de produção restrita e testes
6. Receita Federal — Flexibilização da obrigatoriedade de informações de IBS/CBS em documentos fiscais
Esta reportagem tem caráter informativo e considera as orientações oficiais consultadas na data de publicação. A exigência de dados do adquirente ou destinatário depende da operação, do enquadramento tributário e da versão do leiaute efetivamente utilizada. A aceitação técnica de uma NFS-e não afasta eventuais obrigações legais de preenchimento.
