Voltar para o blog

NF-e e NFC-e

Rejeição 1007: confira o CST antes de retirar a redução do IBS municipal

Quando a venda fica parada com a rejeição 1007, o problema está na combinação entre o CST do IBS/CBS e o grupo de redução da alíquota municipal enviado em um item. O sistema informou uma redução que aquele CST não permite. A correção depende de descobrir se o enquadramento tributário está errado ou se o emissor…

Blog ALRA
Capa ilustrada da ALRA: Rejeição 1007: confira o CST antes de retirar a redução do IBS municipal.

Quando a venda fica parada com a rejeição 1007, o problema está na combinação entre o CST do IBS/CBS e o grupo de redução da alíquota municipal enviado em um item. O sistema informou uma redução que aquele CST não permite. A correção depende de descobrir se o enquadramento tributário está errado ou se o emissor acrescentou um grupo indevido ao XML. Trocar o CST por outro que aceite redução, apenas para concluir a emissão, pode transformar um erro de preenchimento em erro fiscal.

A mensagem deste contexto é: “Rejeição: CST do IBS/CBS informado não permite informação de redução de alíquota municipal [nItem: 999]”. O número após nItem identifica o item apontado no retorno; 999 é a indicação de posição usada na documentação, não um produto específico da empresa.

Qual documento e qual regra estão envolvidos

A NT 2025.002-RTC v1.52 relaciona a mensagem à regra UB45-10, na autorização da NF-e modelo 55 e da NFC-e modelo 65. Ela verifica a presença de gIBSMun/gRed quando o CST possui ind_gRed=0, indicador que veda a redução de alíquota. O endereço completo fica dentro do imposto do item: imposto/IBSCBS/gIBSCBS/gIBSMun/gRed. O grupo estadual gIBSUF/gRed e o grupo da CBS gCBS/gRed têm verificações próprias. [1]

Isso não é uma avaliação do desconto comercial concedido ao cliente. Desconto no preço e redução tributária de alíquota são informações diferentes. A rejeição também não informa, sozinha, que a empresa perdeu um benefício fiscal: primeiro é necessário confrontar a operação, o CST, a classificação tributária e o conteúdo realmente transmitido.

Confirme o modelo, o serviço de autorização, a UF, o autorizador, o ambiente e o texto completo. Este artigo não interpreta códigos homônimos de outros documentos fiscais nem mensagens internas do programa apenas pelo número.

A exceção que impede uma correção automática

A UB45-10 registra uma exceção precisa: há percentual de redução em compra governamental informado em gCompraGov/pRedutor e gIBSMun/gRed/pRedAliq é igual a zero. Nessas condições documentais, o grupo municipal pode permanecer mesmo com ind_gRed=0. Zerar pRedAliq, isoladamente, não atende à exceção. [1]

Também não basta o destinatário ser um órgão público. O responsável fiscal precisa confirmar que a operação se enquadra no tratamento de compra governamental e que seus campos descrevem o negócio real. Não inclua gCompraGov artificialmente para evitar a rejeição. Na NFC-e, a presença desse grupo é vedada pela BB01-10, código 1006; portanto, a exceção da redução não torna uma NFC-e de compra governamental admissível.

Antes de retirar gRed, confira ainda as regras vizinhas. A UB45-20, código 1074, verifica a falta do grupo municipal nas condições que o exigem; a UB46-10 e a UB47-10 tratam do percentual e da alíquota efetiva. Eliminar um grupo exigido pode apenas substituir uma rejeição por outra.

O que guardar e comparar

Preserve o retorno da Sefaz e o XML enviado, com horário e ambiente. Peça ao suporte uma comparação do item indicado, observando:

  • CST e cClassTrib do IBS/CBS efetivamente gravados;

  • indicador de redução do CST na tabela oficial consultada;

  • presença de gIBSMun/gRed e valores de pRedAliq e pAliqEfet;

  • grupo de compra governamental, se existir;

  • configuração fiscal que gerou esses dados.

A tela pode mostrar redução zero e ainda assim produzir gRed no arquivo. Uma integração também pode conservar a configuração anterior quando o CST é alterado. O XML transmitido é a evidência dessa diferença; não edite manualmente um arquivo assinado para testar combinações.

Como corrigir cada cenário

O CST está correto, mas a redução foi acrescentada por padrão. Com a operação validada pelo responsável fiscal, ajuste a configuração para não gerar gIBSMun/gRed quando vedado e fora da exceção. Recalcule os campos dependentes pelo emissor. A alteração deve alcançar a regra de geração, evitando que a próxima venda repita o problema.

O item recebeu um enquadramento tributário errado. Confirme o produto, a operação e o fundamento fiscal. Corrija CST e cClassTrib para o enquadramento verdadeiro, depois confira grupos e percentuais permitidos. A existência de um código na tabela não demonstra que ele se aplica à mercadoria vendida.

A compra governamental é real, mas a geração está inconsistente. Analise conjuntamente gCompraGov/pRedutor, o CST e o pRedAliq municipal. Se a exceção estiver demonstrada, o suporte deve preservar a estrutura correspondente e calcular a alíquota efetiva conforme as regras aplicáveis. Não retire automaticamente o grupo de uma operação que o exige.

A configuração e o XML parecem coerentes. Registre a tabela utilizada pelo sistema, sua data de atualização e o autorizador que rejeitou. Uma tabela antiga ou uma implantação divergente precisa de análise técnica; não é motivo para testar CSTs aleatórios.

Um exemplo de investigação

Uma loja fictícia emite uma nota com quatro itens. O retorno aponta o item 3. O responsável fiscal confirma tributação integral para aquele fornecimento, e a tabela oficial consultada mostra CST 000 sem indicador de redução. Entretanto, a integração copiou do item anterior um gRed municipal com percentual de 60%. Não há compra governamental.

O suporte corrige a herança da configuração e gera novamente a nota rejeitada. O CST permanece o confirmado para a operação, e o grupo indevido desaparece do item 3. A equipe confere também os outros itens, porque o retorno pode ter apontado apenas a primeira inconsistência encontrada. O exemplo demonstra uma causa possível; não define o tratamento tributário de todos os produtos de uma loja.

Datas e confirmação do resultado

Consulta documental: 10/10/2026. A v1.52 foi publicada no portal em 01/10/2026; sua capa informa setembro. O cronograma da alteração da UB45-10 na v1.51 indica homologação até 01/09 e produção em 05/10/2026. O aviso ENCAT de 05/10 postergou as mudanças recém-publicadas da v1.52 para 26/10 em homologação e 16/11 em produção. Ele não adia automaticamente a UB45-10 nem comprova sua ativação em toda UF. [1][3]

Depois da correção, regenere e assine pelo fluxo do emissor, transmita uma vez e leia o novo retorno. Confirme eventual autorização, chave e protocolo; o desaparecimento da 1007 sozinho não significa autorização. Se houver nova rejeição, trate sua causa específica. Acione o contador para enquadramento ou benefício e o suporte para tabela, configuração ou XML. Persistindo divergência documental, encaminhe as evidências à administração tributária responsável.

Fontes consultadas

  1. NT 2025.002-RTC v1.52, p. 6, 20, 32 e 46; UB45-10 e regras adjacentes.

  2. Tabela oficial CST/cClassTrib, Conformidade Fácil, consulta de CST e indicadores em 10/10/2026.

  3. Avisos oficiais SVRS/ENCAT, comunicado de 05/10/2026.

  4. Lista oficial de documentos SVRS, captura consultada em 10/10/2026 com a entrada da NT 2025.002-RTC v1.52, publicada em 01/10/2026.

Conferência prática: TOTVS Logix, Sankhya e NS Tecnologia. São procedimentos de produtos próprios; a regra oficial e a situação fiscal real orientam a correção. Revisão documental por IA, sem teste de emissão por UF ou certificação fiscal humana.

Pronto para dar o próximo passo?

Pronto para organizar sua empresa e ganhar mais tempo?

Teste grátis por 15 dias e descubra como a Alra pode transformar a gestão do seu negócio.