A emissão de documentos fiscais eletrônicos depende tanto da montagem correta do XML quanto da coerência entre os dados enviados e os cadastros consultados pela autorização. A Nota Técnica 2026.007, versão 1.11, do Projeto NF-e, traz uma mudança relevante nesse encontro entre software, cadastro e operação fiscal: em condições delimitadas, passa a admitir a emissão de NF-e modelo 55 sem a Inscrição Estadual do emitente para contribuinte exclusivo de IBS/CBS.
A mesma nota atualiza validações que usam a Lista Centralizada de Contribuintes da Receita Federal do Brasil (LCC-RFB) e o Cadastro Centralizado de Contribuintes (CCC). Para quem desenvolve ou mantém um emissor em Delphi, isso significa revisar regras de geração, roteamento de autorização, tratamento de retornos e testes. Para a área contábil e fiscal, significa conferir se o enquadramento e os dados cadastrais efetivamente sustentam o comportamento esperado do sistema.
Este artigo explica o que a versão 1.11 determina, distingue a NF-e da NFC-e, organiza os pontos de cadastro e propõe um roteiro prático de adequação. O foco é evitar duas simplificações perigosas: tratar a ausência de IE como mera mudança de tag no XML ou concluir que toda empresa ligada ao IBS/CBS poderá emitir sem Inscrição Estadual.
O que a NT 2026.007 v1.11 trata
A NT 2026.007 tem como tema a emissão por contribuinte exclusivo de IBS/CBS. Sua versão 1.11 é uma especificação técnica aplicável à NF-e modelo 55 e à NFC-e modelo 65, aprovada no Ato Técnico Conjunto RFB/SUFIS/CGIBS/Diretoria-Executiva nº 10, de 28 de outubro de 2026, publicado em 29 de outubro de 2026.
A versão 1.11 altera o cronograma das versões anteriores, sem criar novas regras de conteúdo. A implantação em produção indicada pela nota é 16 de novembro de 2026. Essa data é operacional: ela informa a entrada em produção das especificações, não estabelece por si só um prazo individual de adesão, regularização ou entrega para cada contribuinte.
O documento reúne duas frentes que precisam ser analisadas juntas:
- a possibilidade de NF-e sem a tag
emit/IEpara o contribuinte que se enquadre como exclusivo de IBS/CBS; e - as verificações cadastrais associadas à LCC-RFB e ao CCC, que abrangem participantes e situações específicas do fluxo de emissão e de eventos.
A aprovação conjunta do ato dá respaldo à versão 1.11. Ainda assim, a interpretação de campos, regras de validação, exceções e cronograma técnico deve se apoiar na própria nota técnica, pois é nela que esses detalhes estão descritos.
NF-e sem IE: permissão condicionada, não retirada genérica de campo
A principal alteração de leiaute expressa na nota é a mudança de ocorrência do campo C17/emit/IE, que passa a admitir ocorrência de zero a uma vez. Em termos práticos, a Inscrição Estadual do emitente pode deixar de ser informada em determinados XMLs de NF-e.
Isso não autoriza, porém, a remoção indiscriminada da IE da emissão. A condição descrita para o enquadramento como contribuinte exclusivo de IBS/CBS reúne três elementos:
- o emitente não informa
emit/IE; - o CNPJ está ativo na Receita Federal; e
- não existe IE habilitada para ICMS na UF, conforme consulta ao CCC.
Portanto, a ausência de IE no XML é apenas uma parte do cenário. A autorização depende da situação cadastral que os ambientes autorizadores verificam. Uma aplicação que simplesmente deixe de serializar a tag poderá receber rejeição caso o CNPJ não corresponda à condição cadastral prevista.
Essa distinção é importante para a conversa entre tecnologia e contabilidade. O desenvolvedor precisa implementar o comportamento condicional e exibir retornos compreensíveis. Já o responsável fiscal precisa reconhecer que o cadastro não é um detalhe externo ao ERP: ele integra o critério de validação da emissão.
Autorização pela SVRS
Para a NF-e emitida por contribuinte exclusivo de IBS/CBS, a autorização é centralizada na Sefaz Virtual do Rio Grande do Sul (SVRS). O impacto técnico não se limita à estrutura de emit/IE; há efeito no destino da comunicação.
Sistemas com roteamento baseado somente na UF do emitente precisam ser revisados. A regra também alcança os eventos do próprio emitente nesse contexto, conforme a orientação técnica resumida na nota. Em uma arquitetura com componente fiscal reutilizável, é recomendável que a decisão de endpoint seja derivada de uma regra de negócio explícita, e não dispersa em rotinas específicas de emissão, cancelamento ou outros eventos.
Para equipes Delphi, vale evitar soluções baseadas em exceções manuais no código de cada tela. Uma camada única de resolução de serviço, alimentada pelo modelo do documento e pela condição cadastral aplicável, reduz a chance de a NF-e seguir corretamente à SVRS enquanto um evento posterior é enviado a um autorizador incompatível.
NFC-e continua com restrição própria
A mudança não deve ser transportada automaticamente da NF-e para a NFC-e. A regra C17-42 mantém a rejeição de NFC-e modelo 65 para emitente sem IE. A própria regra prevê que ela não se aplica a partir de 2033, mas essa previsão futura não altera o tratamento requerido no cronograma abordado pela NT 2026.007 v1.11.
Na prática, o ERP precisa separar os comportamentos por modelo. Uma mesma empresa pode operar com regras distintas para modelo 55 e modelo 65. Permitir NFC-e sem IE por reutilizar a lógica implementada para NF-e seria uma conclusão incompatível com a regra indicada.
Cadastro, CRT e validações centralizadas
A NT atualiza regras de verificação dos cadastros presentes na LCC-RFB e no CCC. A LCC-RFB é usada para validações relativas aos dados cadastrais centralizados, enquanto o CCC participa da apuração da existência de IE habilitada para ICMS na UF e de condições relacionadas ao contribuinte exclusivo de IBS/CBS.
As validações da LCC-RFB alcançam o emitente, o destinatário, os CNPJs informados nos locais de retirada e de entrega e o autor de eventos. O alcance é relevante porque um projeto de adequação não deve se restringir ao cadastro principal do emitente. Rotinas de entrega, retirada, manifestação e demais eventos precisam ser incluídas no levantamento técnico.
A nota também prevê verificações de existência e situação cadastral do CNPJ e de compatibilidade entre o Código de Regime Tributário (CRT) informado e o regime registrado na LCC-RFB. Não se deve interpretar isso como uma orientação para o software substituir a análise fiscal do contribuinte. Trata-se, antes, de uma razão para reduzir divergências entre o cadastro interno do ERP, a parametrização tributária usada para gerar o XML e as bases consideradas nas validações.
Produção como referência também em homologação
Um ponto operacional que merece atenção é o uso da LCC-RFB do ambiente de produção inclusive pelos Web Services de homologação. A consequência é direta: um teste em homologação pode depender de dados centralizados reais de produção, e não de uma base cadastral isolada exclusivamente para testes.
A versão preserva exceções de homologação. Entre elas, estão a não rejeição do emitente ou autor de evento quando o CCC indicar indContribTeste=1 e a não rejeição de CNPJ alfanumérico de destinatário ou dos locais de retirada e entrega. Essas exceções não justificam supor que toda validação cadastral ficará relaxada em homologação, nem permitem concluir que sejam permanentes: a evidência disponível não fixa uma data de encerramento para elas.
Para a governança de testes, a conclusão prudente é que ambientes de homologação exigem dados de cenário cuidadosamente selecionados. CNPJ, condição no CCC, CRT e papel exercido no XML podem influenciar o resultado tanto quanto a assinatura, o schema ou o certificado.
Tributação, CFOP e grupo IBSCBS
A emissão pela condição de contribuinte exclusivo de IBS/CBS envolve também regras de operação e tributação. A nota prevê CFOPs permitidos em tabela própria, contempla vedação geral de ICMS e ICMSUFDest e exige o grupo IBSCBS para o contribuinte exclusivo.
Essas regras devem ser tratadas como um conjunto. Não é suficiente tornar emit/IE opcional se o gerador continuar inserindo grupos incompatíveis ou deixar de produzir o grupo tributário requerido. Do ponto de vista de engenharia, a condição do emitente deve influenciar a montagem de todos os grupos relacionados, e não apenas um campo cadastral.
A tabela de CFOP mencionada na documentação possui a coluna indExclIBSCBS. Como a tabela aplicável não foi conferida nesta apuração, não é apropriado publicar uma lista de CFOPs autorizados nem embutir uma relação presumida no sistema. A ação segura é consultar a versão oficial correspondente antes de parametrizar ou bloquear códigos.
A mesma cautela vale para interpretações materiais sobre IBS/CBS fora das validações expressas na NT. A nota técnica informa comportamentos do documento fiscal eletrônico; ela não substitui a leitura dos instrumentos legais e regulamentares necessários para decisões tributárias mais amplas.
Rejeições: como transformar retorno técnico em ação operacional
A nota reúne rejeições associadas às regras novas e atualizadas, com destaque para faixas de códigos 156 a 164, 178 a 188 e 209. A presença desses códigos não significa que todos serão aplicáveis a qualquer documento. A incidência depende da combinação entre modelo, participante, dados enviados, cadastro consultado e condição operacional.
No ERP, o objetivo não deve ser apenas mostrar o texto bruto retornado pelo serviço. Uma rejeição fiscal precisa ser preservada integralmente para auditoria, mas pode receber uma orientação contextual ao usuário. Por exemplo, conforme a situação identificada, a aplicação pode direcionar a conferência para CNPJ, situação cadastral, CRT, IE, modelo de documento, grupo IBSCBS ou rota de autorização.
É importante não converter essa orientação em diagnóstico definitivo quando o retorno não permitir tal conclusão. O sistema pode informar que há uma inconsistência a conferir entre o XML e as bases cadastrais consultadas, mas não deve afirmar automaticamente que um cadastro público está errado sem evidência específica do retorno e sem procedimento de validação pela área responsável.
Limitações e cuidados de interpretação
A análise deve respeitar alguns limites das evidências disponíveis. A versão oficial conferida é a 1.11, de outubro de 2026. Embora o índice do portal apresente referência a publicação em 30 de outubro, a data diária não foi confirmada no trecho do PDF acessível; por isso, é mais seguro referir-se à versão de outubro de 2026.
Também não foram conferidos nesta pesquisa os pacotes de schemas, nem alterações em DANFE, QR Code ou outros Web Services. A alteração de leiaute expressamente identificada é a ocorrência de zero a uma para C17/emit/IE. Conclusões sobre outros arquivos técnicos exigem consulta específica aos materiais oficiais distribuídos no portal.
Por fim, a implantação em produção em 16 de novembro de 2026 não deve ser apresentada como data de obrigação cadastral genérica. Ela sinaliza o cronograma de produção da especificação. Cada organização ainda precisa avaliar seus cadastros, fluxos de negócio e a configuração efetiva do emissor.
Aplicação prática
A preparação mais consistente combina levantamento fiscal, desenvolvimento controlado e testes representativos. O roteiro a seguir separa o que decorre diretamente da nota do que é uma recomendação de engenharia para tornar a adequação rastreável.
1. Classifique os cenários antes de alterar o XML
Comece identificando quais emitentes poderiam estar no cenário de contribuinte exclusivo de IBS/CBS. A checagem deve considerar a ausência de emit/IE, o CNPJ ativo e a inexistência de IE habilitada para ICMS na UF conforme o CCC. Não use apenas uma flag interna chamada “sem IE”, pois ela não expressa todos os critérios da regra.
Em seguida, separe as emissões por modelo. NF-e modelo 55 e NFC-e modelo 65 não recebem o mesmo tratamento quanto à ausência de IE. Mantenha um bloqueio claro para NFC-e sem IE, observada a regra C17-42.
2. Centralize regras no componente fiscal
No emissor Delphi, implemente a decisão de gerar ou não emit/IE em uma camada central de validação e serialização. Essa camada deve ser usada por todas as rotinas que construam NF-e, inclusive integrações em lote ou processos sem interface gráfica.
Pela mesma razão, centralize a resolução do autorizador. Quando a condição de contribuinte exclusivo de IBS/CBS se aplicar à NF-e, o fluxo deve direcionar a autorização à SVRS. Inclua os eventos do próprio emitente na matriz de testes de roteamento. A recomendação técnica é registrar, em log, o modelo, a condição aplicada, o endpoint selecionado e o retorno recebido, sem expor dados pessoais além do necessário.
3. Revise a composição tributária e os CFOPs
Verifique se o gerador passa a exigir o grupo IBSCBS quando o emitente estiver no cenário abrangido e se evita a inclusão de ICMS e ICMSUFDest nas situações vedadas pela nota. Faça essa revisão junto da área fiscal: regras tributárias não devem ficar inferidas a partir de campos de tela ou de defaults antigos.
Antes de codificar regras de CFOP, consulte a tabela oficial correspondente e sua coluna indExclIBSCBS. Não cadastre uma lista baseada em memória, em notas de terceiros ou em testes isolados. A tabela é parte essencial da parametrização e precisa ter origem documentada e versão controlada.
4. Construa uma matriz de homologação
Prepare casos com emitente, destinatário, retirada, entrega e autor de evento quando aplicável. Inclua combinações de CNPJ, CRT e condições cadastrais que permitam observar as validações da LCC-RFB e do CCC. Como a LCC-RFB de produção é usada também em homologação, os dados selecionados devem ser conferidos previamente.
Registre ainda os casos especiais previstos para homologação, como indContribTeste=1 e CNPJ alfanumérico nas posições explicitamente excepcionadas. Testar a exceção é diferente de projetar o processo como se ela eliminasse toda validação cadastral.
5. Mapeie as rejeições para atendimento e auditoria
Atualize a tabela de mensagens do sistema para os códigos alcançados pela nota, preservando sempre o código e a descrição retornada pelo ambiente autorizador. Acrescente instruções internas de diagnóstico: quem verifica o cadastro, quem ajusta a parametrização fiscal, quando reenviar e quando escalar a análise.
Esse mapeamento reduz retrabalho entre suporte, desenvolvimento e contabilidade. Ele também evita que o usuário tente corrigir manualmente o XML sem entender se o problema está em um campo, no modelo do documento, no CRT ou no cadastro centralizado.
Conclusão
A NT 2026.007 v1.11 introduz uma possibilidade específica de emissão de NF-e sem Inscrição Estadual para contribuinte exclusivo de IBS/CBS, mas a mudança está condicionada a verificações cadastrais e não se estende automaticamente à NFC-e. Para a NF-e alcançada, a ausência de emit/IE, a situação do CNPJ e a inexistência de IE habilitada para ICMS na UF formam um conjunto de requisitos; além disso, a autorização é centralizada na SVRS.
A adequação de um ERP não deve parar no XML. Ela inclui roteamento de serviços, composição do grupo IBSCBS, avaliação de CFOPs na tabela oficial, validações preventivas de cadastro, tratamento das rejeições e cenários de homologação que considerem o uso da LCC-RFB de produção.
Para desenvolvedores Delphi e profissionais contábeis, a decisão mais segura é trabalhar com uma matriz compartilhada de regras e testes. A tecnologia implementa os comportamentos previstos; a área fiscal valida o enquadramento e os parâmetros. Essa divisão, apoiada na versão oficial da nota, reduz o risco de interpretar uma permissão condicionada como uma flexibilização geral da emissão.
Referências
BRASIL. Receita Federal do Brasil; Subsecretaria de Fiscalização; Comitê Gestor do Imposto sobre Bens e Serviços. Ato Técnico Conjunto RFB/SUFIS/CGIBS/Diretoria-Executiva nº 10, de 28 de outubro de 2026. Diário Oficial da União: Brasília, DF, 29 out. 2026. Disponível em: https://www.in.gov.br/web/dou/-/ato-tecnico-conjunto-rfb/sufis/cgibs/diretoria-executiva-n-10-de-28-de-outubro-de-2026-741177669. Acesso em: 4 nov. 2026.
PROJETO NF-E. Nota Técnica 2026.007: emissão por contribuinte exclusivo do IBS/CBS: versão 1.11. Brasília, DF: Portal Nacional da NF-e, out. 2026. Disponível em: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?AspxAutoDetectCookieSupport=1&conteudo=HXzgTeht%2B5Q%3D. Acesso em: 4 nov. 2026.
0 comentário(s)