Rejeição 1021: retire o grupo gIBSCBS somente depois de confirmar o CST

Sua nota foi rejeitada porque um item levou o grupo de cálculo do IBS e da CBS, embora o CST informado não permita esse preenchimento. Antes de apagar valores ou mudar a tributação, confira se o enquadramento do item está correto e se o emissor gerou o XML de acordo com ele. A correção precisa preservar a operação real.

O retorno documentado é “Rejeição: Grupo gIBSCBS informado indevidamente [nItem: 999]”. O número mostrado em nItem identifica o item a investigar; 999 é a representação usada na documentação. Uma nota com vários produtos pode ter somente um item com essa divergência.

O que a SEFAZ está comparando

A regra UB13-20 da NT 2025.002-RTC v1.52, página 40, se aplica à autorização da NF-e, modelo 55, e da NFC-e, modelo 65. Ela compara o CST do IBS/CBS, em det/imposto/IBSCBS/CST, com o indicador ind_gIBSCBS da tabela oficial. Quando esse indicador é zero, o subgrupo imposto/IBSCBS/gIBSCBS não pode ser informado. NT 2025.002 v1.52, p.40.

IBSCBS e gIBSCBS são nomes parecidos, mas representam níveis diferentes. O primeiro reúne a identificação tributária do item; o segundo contém os dados de cálculo. Retirar um subgrupo indevido não significa apagar automaticamente CST, cClassTrib ou toda a informação da reforma tributária.

Mesmo que os valores internos estejam zerados, o grupo continua presente no arquivo. Portanto, trocar uma base por zero não elimina a incompatibilidade estrutural apontada pela 1021. É necessário verificar a presença do grupo e a regra que o gerou.

Onde procurar a causa

Comece pelo XML efetivamente enviado, não apenas pela tela de cadastro. Guarde também a resposta completa, a chave, a data de emissão, o modelo, o ambiente e a UF/autorizador. Localize o item indicado e compare seu produto e sua quantidade com a venda ou movimentação que está sendo documentada.

Em seguida, peça ao responsável fiscal para conferir o CST e o cClassTrib escolhidos. O CST aqui é o do IBS/CBS. Ele não deve ser confundido com o CST do ICMS, do PIS ou da Cofins. Um campo chamado simplesmente “CST” na integração pode estar recebendo informação de outro tributo.

Consulte a tabela oficial vigente e seu indicador de exigência de tributação. Confira ainda a classificação e seus limites de uso. Uma configuração copiada de outro produto pode produzir um código existente, mas inadequado para a operação atual. A existência do código não comprova que ele foi corretamente escolhido.

Como corrigir por cenário

O enquadramento está correto, mas o emissor acrescenta o cálculo

Se a análise fiscal confirmar um CST que não permite gIBSCBS, ajuste a parametrização que inclui o subgrupo. Ele e seus campos filhos devem deixar de ser gerados naquele cenário. Faça isso no cadastro, na regra fiscal ou na integração responsável, conforme o recurso do emissor.

Uma causa possível é um modelo de XML que cria o cálculo para todos os itens, sem consultar os indicadores. Outra é uma regra padrão que permaneceu ativa após a mudança de classificação. O suporte deve corrigir a origem do preenchimento; apagar o grupo de um arquivo isolado não previne a repetição em notas futuras.

O CST selecionado não corresponde à operação

Nesse caso, a solução começa pela definição fiscal. O contador ou responsável tributário deve indicar o enquadramento verdadeiro. Depois disso, atualize os códigos e gere os grupos exigidos por essa classificação. Não escolha um CST tributado apenas para manter os valores que o sistema já calculou, nem um CST sem incidência para eliminar a rejeição.

Confira o alcance da alteração. Uma regra usada por vários produtos ou estabelecimentos pode afetar documentos que não têm o mesmo tratamento. Valide os cenários atingidos antes de aplicar uma mudança ampla.

O cadastro já foi corrigido, mas a nota continua com dados antigos

Verifique se o documento rejeitado conserva uma fotografia anterior da parametrização. Pode ser necessário recalcular ou regenerar a nota pelo fluxo do sistema. Compare o novo XML com o anterior e confirme que ele usa o cadastro atualizado. Se o arquivo muda, a assinatura precisa ser produzida novamente pelo emissor.

Também investigue versões distintas entre estação, servidor e integração. A tela pode mostrar a regra nova enquanto o componente que transmite continua usando uma estrutura antiga. Registre a versão responsável pela geração, sem presumir que uma atualização na estação resolveu toda a cadeia.

Exemplo para entender a diferença

Uma distribuidora fictícia prepara uma NF-e com quatro itens. No terceiro, a contabilidade já havia definido um tratamento sem geração do grupo de cálculo. A integração, porém, acrescenta gIBSCBS com base e tributos zerados, porque reutiliza a mesma estrutura para todos os produtos.

A empresa recebe 1021 para o item 3. O suporte compara a regra fiscal, o indicador oficial e o XML. Confirmado o enquadramento, corrige a geração condicional do subgrupo e recompõe o documento. Os outros itens continuam com os cálculos que suas classificações exigem. A mudança resolve a incoerência identificada, sem transformar a natureza dos produtos ou da operação.

Cronograma e limites da orientação

A versão 1.52 era a mais recente listada no portal SVRS em 10/10/2026. Seu histórico coloca alterações da UB13-20 na versão 1.51, com previsão de produção em 05/10/2026. O aviso ENCAT de 05/10 posterga a implantação da atualização 1.52 para 26/10 em homologação e 16/11 em produção. Isso não comprova suspensão geral das validações anteriores. Confira a versão efetivamente adotada pelo autorizador. SVRS, documentos, aviso ENCAT.

Não estenda este diagnóstico ao grupo monofásico gIBSCBSMono: a documentação atual lhe atribui regra própria, UB13-39, com retorno 1151. Materiais antigos podem reunir esses grupos sob o mesmo texto. Confirme sempre a mensagem completa e a versão.

Como verificar o resultado e quando escalar

Regenere a nota rejeitada, confira o item corrigido e acompanhe a resposta da transmissão. A ausência da 1021 não equivale, sozinha, à autorização: outra validação pode apontar um problema seguinte. Confirme o resultado final, a chave correspondente e o protocolo, quando houver autorização.

Acione o responsável fiscal se houver dúvida sobre o enquadramento. Encaminhe ao suporte o XML, o retorno, a versão do emissor e a tabela consultada quando os dados corretos não forem gerados. Se a estrutura e o indicador oficial coincidirem e a rejeição persistir, reúna essas evidências para análise do autorizador da UF. Não repita envios iguais indefinidamente.

Fontes e revisão

Consulta documental e revisão por IA: 10/10/2026. Sem teste de emissão por UF ou ambiente e sem certificação fiscal humana.

• NT 2025.002-RTC v1.52, p.6, 7, 40 e 41.

• Tabela oficial de classificação tributária, SVRS, indicadores e classificações consultados em 10/10/2026.

• Conferência prática: Migrate/InvoiCy, CIGAM e TOTVS/Datasul. Os passos de cada produto não representam funções verificadas do ALRA.