Rejeição 1022: confira o cálculo do IBS/CBS que faltou no item

Quando a nota recebe 1022, um item foi enviado com um CST do IBS/CBS que exige o grupo de cálculo, mas esse grupo não apareceu no XML. Ver a classificação preenchida na tela não basta: o sistema precisa gerar também as informações exigidas por ela. Primeiro confirme o tratamento fiscal; depois procure onde o cálculo deixou de ser enviado.

A mensagem documentada é “Rejeição: Grupo gIBSCBS não informado [nItem: 999]”. O nItem do retorno aponta o item afetado. O 999 é a representação do número na nota técnica, não uma orientação para procurar obrigatoriamente o item 999 da venda.

O grupo que está faltando

Na autorização da NF-e, modelo 55, e da NFC-e, modelo 65, a regra UB13-30 verifica o indicador ind_gIBSCBS do CST informado em IBSCBS/CST. Se o indicador é um, exige-se o subgrupo imposto/IBSCBS/gIBSCBS. A ausência dele gera 1022. A regra está na NT 2025.002-RTC v1.52, página 41. Documento oficial, p.41.

O grupo principal IBSCBS pode estar presente com CST e cClassTrib, enquanto o subgrupo de cálculo está ausente. São problemas diferentes. A falta do grupo principal possui regra própria, UB12-10, retorno 1115, com condições e cronograma próprios. Não use uma orientação sobre 1115 para concluir que a 1022 deixou de ser aplicável.

Dentro de gIBSCBS ficam dados como base de cálculo e grupos do IBS estadual, municipal e da CBS. Incluir somente o nome do grupo ou um campo isolado não é uma correção completa. A estrutura, os valores e os subgrupos devem atender ao leiaute e ao enquadramento daquela operação.

O que guardar antes de mexer na nota

Preserve o XML transmitido e a resposta integral. Anote chave, modelo, UF/autorizador, ambiente, data de emissão e versão do emissor. Localize o nItem e identifique o produto correspondente. Isso evita corrigir um cadastro semelhante que não participou da nota rejeitada.

Peça ao suporte uma comparação entre três pontos: o tratamento fiscal aprovado para a operação, os dados calculados pelo sistema e os campos realmente enviados. Se a tela mostra cálculo e o XML não, a investigação passa pela geração ou integração. Se o cálculo já falta na tela, procure a parametrização e os dados usados para calculá-lo.

Confira a tabela oficial de indicadores. O CST do IBS/CBS não deve ser substituído pelo código de outro tributo. Também não deduza a exigência apenas pelo nome comercial do produto ou pelo fato de uma nota anterior ter sido autorizada.

Corrigir conforme a causa

O CST está certo, mas o sistema não calcula os novos tributos

O responsável fiscal deve validar o enquadramento e os dados de cálculo. O suporte deve verificar a regra fiscal, os vínculos do cadastro e a versão que atende ao leiaute. Corrija a causa que deixou o cálculo ausente e regenere o documento pelo emissor.

Não preencha todos os valores com zero apenas para criar o grupo. Um resultado zero pode ser legítimo em determinado campo, mas precisa decorrer da regra aplicável. Presença estrutural e correção tributária devem ser verificadas juntas.

O sistema calcula, mas a integração suprime o grupo

Verifique a etapa que transforma os dados em XML. Uma integração antiga pode transmitir CST e cClassTrib e ignorar o objeto com os cálculos. Outra pode descartar subgrupos por considerar valores zerados como informação vazia. Compare o arquivo gerado antes do envio com os dados recebidos pela integração.

Atualize o componente ou seu mapeamento com apoio do fornecedor. Depois confira cada item atingido: uma correção que cria o grupo para todos os produtos pode causar 1021 naqueles cujo CST o proíbe. A geração precisa obedecer aos indicadores, não a uma configuração indiscriminada.

O CST foi copiado de outro cenário

Se a classificação estiver incorreta, a correção cabe ao responsável fiscal. Ele deve definir o tratamento correspondente à operação verdadeira. Depois, o emissor precisa recalcular e gerar os grupos próprios desse enquadramento.

Não troque o CST por outro que dispense o cálculo só porque o sistema ainda não consegue gerá-lo. Também não replique o código de uma nota de fornecedor sem analisar seu contexto: o tratamento da entrada não decide automaticamente o da saída.

A nota foi preparada antes da atualização

Corrigir o cadastro pode não atualizar um documento já montado. Confira se a nota rejeitada conserva os dados anteriores. Use o fluxo do emissor para reconstruir ou recalcular seu conteúdo e gere novamente a assinatura quando o XML mudar. Preserve os registros anteriores para demonstrar o que foi corrigido.

A exceção de perda em estoque

A UB13-30 não se aplica quando tpNFDebito=07, perda em estoque. Essa é uma exceção explícita da regra; não permite transformar uma venda ou remessa em perda. Confirme com a contabilidade que a finalidade e o tipo de nota descrevem o fato documentado.

Se uma verdadeira nota de perda, corretamente identificada, receber 1022, encaminhe o XML e o retorno ao suporte para conferir o autorizador e a versão aplicada. Não invente cálculo nem altere a finalidade para esconder a divergência.

Exemplo de diagnóstico

Uma loja fictícia prepara uma NFC-e com dois itens. O tratamento aprovado para o segundo exige gIBSCBS. O sistema calcula os tributos, mas o módulo de transmissão envia apenas CST e cClassTrib. A resposta aponta 1022 no item 2.

O suporte localiza a ausência no XML e corrige o mapeamento desse módulo. A loja recompõe a nota e confere que o segundo item passou a transportar os dados calculados, enquanto o primeiro mantém seu tratamento. O exemplo mostra uma falha de geração; ele não define códigos ou alíquotas para outras vendas.

Ambiente, cronograma e confirmação

Em 10/10/2026, o portal SVRS listava a v1.52 como versão mais recente. Seu histórico prevê as alterações da UB13-30 na v1.51 em produção em 05/10/2026. O aviso ENCAT posterior trata da atualização 1.52 e informa 26/10 em homologação e 16/11 em produção; ele não demonstra adiamento geral das regras anteriores. Confira a adoção no autorizador e no ambiente utilizados. Documentos SVRS, aviso de 05/10.

Uma orientação prática consultada sugere trocar homologação por produção. Essa troca não corrige um XML sem grupo exigido e não deve ser usada para evitar a validação. Testes permanecem em homologação; uma operação real deve usar o ambiente adequado com dados consistentes.

Após a correção, confira o XML completo, transmita pelo fluxo regular e leia o novo resultado. Eliminar 1022 não garante autorização. Preserve a chave e o protocolo correspondente se autorizado. Escale dúvidas fiscais à contabilidade; falhas de cálculo, geração ou versão ao suporte; divergência comprovada da regra ao autorizador, com os arquivos e horários do caso.

Fontes e revisão

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

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

• Tabela oficial, SVRS.

• Conferência prática: Migrate/InvoiCy, Projeto ACBr e TOTVS/Datasul.

• Divergência registrada: Alterdata/Shop, relato sobre ambiente de emissão, sem adotar a troca de ambiente como correção fiscal.