Rejeição 1132: confira o CST e a geração do grupo de transferência de crédito

Quando a emissão retorna 1132, o sistema enviou uma classificação que exige informações de transferência de crédito, mas esse grupo não aparece no item transmitido. Antes de acrescentar valores, confirme se a operação realmente corresponde ao enquadramento escolhido. A ausência pode estar na geração do XML; também pode revelar um CST selecionado incorretamente.

A mensagem documentada na v1.52 salva é “Rejeição: Grupo de transferência de crédito não informado [nItem: 999]”. O item apontado na resposta ajuda a localizar a divergência; 999 é o marcador usado na documentação, não um produto fixo a procurar. Esse crédito é tributário, relacionado ao IBS e à CBS. Não se trata de pagamento a prazo, saldo do cliente, desconto concedido ou crédito de uma devolução comercial.

O que aciona a regra

A UB13-45, página 41 da NT 2025.002-RTC v1.52, pertence à autorização de NF-e modelo 55 e NFC-e modelo 65. Ela combina o CST em IBSCBS/CST, com indicador ind_gTransfCred=1, e a ausência do grupo imposto/IBSCBS/gTransfCred, identificado como UB106. O indicador significa que esse grupo é exigido para o CST utilizado. [1]

A verificação depende da tabela oficial de indicadores do CST do IBS e da CBS. Não procure a solução somente no cadastro de CST do ICMS nem use o mesmo número de outro tributo como equivalente. Também confira IBSCBS/cClassTrib: a classificação precisa ser compatível com o CST e permitida para o modelo de documento, segundo as regras próprias da mesma página.

A presença da UB13-45 na coluna 55/65 não é permissão geral de transferência por NFC-e. Se um modelo 65 apresenta esse retorno, verifique especialmente o enquadramento e os indicadores de permissão do documento. Não adapte a NFC-e para uma finalidade de NF-e de débito apenas para preencher o grupo.

O que precisa ser gerado quando o enquadramento está correto

O leiaute da página 27 descreve gTransfCred com vIBS, valor do IBS a transferir, e vCBS, valor da CBS a transferir. São campos do grupo de transferência; não basta que valores semelhantes estejam em outra parte do XML ou apenas na tela do sistema.

Para a NF-e 55 com gTransfCred informado, a página 65 acrescenta controles próprios: finalidade finNFe=6, nota de débito, na UB106-30, retorno 1133; tipo de débito 01, transferência para cooperativas, ou 05, transferência de crédito de sucessão, na UB106-31, retorno 1168; e pelo menos um valor de IBS ou CBS maior que zero, na UB106-40, retorno 1129. Não é exigência de ambos positivos. Esses controles não são a ausência do grupo na 1132 nem devem ser estendidos à NFC-e 65.

Nenhuma dessas condições permite inventar valor ou trocar a finalidade de uma operação comum. A documentação explica o formato e as validações; a existência e a legitimidade do crédito precisam ser demonstradas pelo responsável fiscal.

Diagnóstico em cinco passos

1. Preserve o XML enviado, a resposta integral, o horário, a UF, o autorizador e o ambiente. Confirme que o retorno veio da autorização da NF-e ou NFC-e, e não de outro serviço fiscal.

2. Identifique o item apontado e compare CST e cClassTrib da tela com os valores do arquivo efetivamente transmitido.

3. Peça à contabilidade a confirmação do enquadramento e do fundamento da transferência. Uma descrição parecida no cadastro não basta.

4. Confira na tabela oficial o indicador relacionado ao CST e a permissão da classificação para o modelo. Registre qual versão ou captura sustentou a análise do caso.

5. Se o enquadramento foi confirmado, peça ao suporte que localize por que gTransfCred não foi gerado: configuração da operação, documento antigo, importação ou transformação da integração são hipóteses a testar.

Evite acrescentar o grupo antes dessas verificações. Se o CST estiver errado, preencher gTransfCred pode apenas deslocar o erro para outra validação e registrar uma transferência que não existiu. A 1131 é outra combinação: indicador ind_gTransfCred=0 com o grupo presente. A 1132 combina indicador 1 com grupo ausente. Não alterne preenchimento e exclusão por tentativa.

Como corrigir conforme a causa

Transferência correta, grupo ausente no XML

Com a classificação e os valores confirmados, ajuste a configuração que controla a geração. O objetivo é incluir gTransfCred no item devido, com vIBS e vCBS nos campos previstos. Confira também finalidade e tipo de débito quando se tratar de NF-e 55.

Regere o documento pelo emissor e compare o novo arquivo com a evidência fiscal. Não edite manualmente XML assinado. A alteração precisa passar pelo fluxo de geração e assinatura do sistema e ficar vinculada ao documento rejeitado correto.

CST selecionado para outra operação

Se não existe transferência, a contabilidade deve definir a classificação que representa o fato real. Corrija a origem da escolha equivocada: digitação, cadastro, cópia de documento ou regra de integração. Atualize o documento rejeitado e confira os grupos exigidos pelo enquadramento validado.

Não retire apenas o indicador da tabela local nem escolha um CST que dispense o grupo por tentativa. Isso modifica a regra usada pelo emissor sem resolver a realidade tributária da operação.

Cadastro atualizado, documento antigo

Compare cadastro, dados gravados e XML: documentos preparados antes de uma atualização podem conservar configurações antigas. Atualize pelo emissor com o suporte, preservando os registros anteriores.

Regere a nota; reenviar o arquivo anterior conserva a omissão, mesmo com cadastro corrigido.

Exemplo hipotético

Em um teste fictício, uma empresa prepara uma NF-e modelo 55 de transferência de crédito de sucessão. A contabilidade confirmou a operação, a classificação e valores de IBS e CBS. O documento registra finNFe=6 e o tipo de débito correspondente, mas a integração não serializa gTransfCred no item 1. O retorno é 1132.

O suporte confronta o cadastro com o XML, corrige a transformação e regenera o documento com o grupo e seus valores. A equipe verifica ainda as demais condições da transferência e lê a nova resposta. Se a análise inicial mostrasse uma venda comum classificada por engano como transferência, a correção seria rever o enquadramento, e não incluir crédito fictício.

Calendário, resultado e escalonamento

A pesquisa compartilhada de 10/10/2026 registrou a v1.52 publicada em 01/10. Nesta revisão de 12/10 houve leitura local e inspeção dos PNGs documentais já salvos, sem nova consulta ao portal. A UB13-45 não apresenta observação própria de implementação futura na página 41; a ressalva da UB13-40 pertence à monofasia e não deve ser transferida à 1132. Ausência de rejeição não demonstra dispensa legal. [1]

O aviso ENCAT de 05/10 adiou para 26/10 em homologação e 16/11/2026 em produção as NTs com homologação inicialmente em 05/10, incluindo mudanças da v1.52. Esse aviso não comprova suspensão automática das regras herdadas. Confirme a aplicação concreta com o autorizador e o ambiente envolvidos; não houve teste operacional por UF nesta revisão. [2]

Depois da correção, confira o retorno integral e a situação da chave. A eliminação da 1132 pode revelar outra inconsistência. Só registre autorização com resposta válida, XML correspondente e protocolo preservado. Encaminhe ao suporte divergências de geração; à contabilidade, dúvidas sobre direito ao crédito e classificação; e à SEFAZ, eventual aplicação incompatível com a documentação, acompanhada dos arquivos e das verificações já feitas.

Fontes

Revisão técnica/editorial por IA: 12/10/2026. Base: documentação e capturas compartilhadas de 10/10, com releitura local e inspeção atual dos PNGs documentais existentes. Não houve novo HTTP, renderização, emissão de teste ou validação XSD. Atos individuais antigos não foram reconstituídos; nenhum CST numérico foi escolhido.

1. NT 2025.002-RTC v1.52, páginas 6, 7, 27, 41 e 65.

2. SVRS, lista de documentos e aviso ENCAT de 05/10.

3. Tabela oficial de classificação tributária: o registro compartilhado relata página dinâmica sem versão ou linhas completas recuperadas; não valida um CST individual aqui.

4. Capturas locais de TecnoSpeed, grupos e classificações RTC e Tax360, panorama das versões: apoios adjacentes. Não são três tutoriais específicos da 1132, não comprovam direito ao crédito ou funcionalidades do ALRA. Proveniência, consultas históricas, hashes e limites estão em fontes.v2.json.