Rejeição 930: CST com benefício fiscal e não informado o código de benefício fiscal

A rejeição 930 indica que um item foi enviado com uma situação tributária para a qual a validação exige o código de benefício fiscal, mas esse código não foi informado. O campo envolvido é cBenef, dentro do grupo de produtos do item no XML. A correção exige conferir o enquadramento da operação e a tabela da unidade federada, além de verificar se o cadastro efetivamente alimentou o arquivo transmitido.

Preencher qualquer sequência apenas para eliminar a mensagem não resolve a obrigação fiscal. Também não é adequado trocar o CST por outro que dispense o campo quando a tributação real permanece a mesma. O objetivo é representar corretamente a operação e gerar um XML coerente com essa definição.

Quando a regra se aplica

Na NT 2019.001 v1.70, a regra N12-85 está identificada para NF-e, modelo 55, e NFC-e, modelo 65, com aplicação facultativa. A decisão de implementar a validação cabe à UF, por modelo e por CST. Portanto, o mesmo preenchimento pode receber tratamentos diferentes conforme a combinação aplicável à emissão.

O teste verifica se existe algum código de benefício fiscal associado ao CST na tabela estadual e, sendo exigido o preenchimento, se o item está sem cBenef. Nessa etapa, não se confere a compatibilidade entre um código específico e o CST. Esse confronto pertence à rejeição 931. A existência e a vigência do código informado também têm validação própria, associada à rejeição 946.

A antiga N12-84 aparece riscada no documento. Sua lista fixa de CST e sua exceção não devem ser reaproveitadas como descrição nacional atual da 930. A N12-85 deve ser lida com as condições e a tabela estadual que lhe correspondem. Ela também não se restringe a operações com substituição tributária.

Exceções e situação publicada pela UF

A regra prevê uma exceção geral para nota de devolução em operação interestadual ou com o exterior. Há outras exceções cuja adoção fica a critério da UF: devolução, nota de ajuste e operação de entrada. Essas hipóteses precisam ser verificadas no contexto correto; uma entrada não está automaticamente dispensada em todo o país.

A NT 2021.002 v1.12 acrescenta a exceção para emissão pelo regime Nota Fiscal Fácil, tpEmis=3. Isso se refere ao fluxo legítimo desse regime, no qual o tratamento do benefício ocorre no Portal NFF. Não autoriza mudar o tipo de emissão de uma nota comum para contornar a rejeição, nem comprova que determinado contribuinte esteja habilitado ao regime.

Existe uma divergência documental relevante em São Paulo. O quadro D10 da NT 2019.001 registra homologação em 12/01/2026 e produção em 06/04/2026. Entretanto, a página paulista de regras facultativas, capturada em 16/10/2026, lista N12-85/930 como “Inativa”, sem detalhar ambiente ou data nessa linha. Esses registros não permitem certificar a ativação individual. Diante de um retorno efetivo, preserve as evidências e peça esclarecimento ao autorizador; a divergência não dispensa informar corretamente um benefício exigido pela legislação.

Como localizar a causa

Comece pelo XML rejeitado e pela resposta completa da SEFAZ. Identifique o item indicado, o modelo, a UF, o ambiente, o CST, a finalidade e o tipo de operação. Confira se prod/cBenef está ausente e compare o conteúdo transmitido com o cadastro usado na emissão.

Se o cadastro já apresenta um código, pode haver falha no vínculo entre produto, operação, UF e configuração fiscal, ou no transporte dessa informação para o XML. Um campo visível no sistema não prova que o arquivo enviado o contém. Preserve a versão rejeitada para comparar com a nova geração.

Com a contabilidade, confirme se o CST representa a operação e qual benefício realmente a fundamenta. Consulte a tabela oficial da UF e suas condições, inclusive vigência e correspondência com o CST. Não copie o código de uma nota de outra empresa, de outro estado ou de um exemplo de tutorial.

Como corrigir com segurança

Quando o benefício é aplicável e seu código foi omitido, informe o código correto no cadastro ou na configuração responsável pelo item. Gere novamente o XML e confira o resultado antes de retransmitir. Se o problema estiver na integração, ajuste o mapeamento que perdeu a informação, preservando a definição fiscal validada.

Se a análise mostrar que o CST está incorreto, a alteração deve refletir o enquadramento real, incluindo os demais campos tributários afetados. Não use a troca de CST como solução automática. Da mesma forma, a ausência de benefício real exige apuração da tributação e da exigência estadual, em vez de inventar um código.

Em São Paulo, a página oficial e a tabela versão 20260901 informam que “SEM CBENEF” deixou de ser permitido em 01/07/2026. Por isso, orientações antigas que sugerem esse conteúdo não podem ser aplicadas indistintamente. Zeros e códigos fictícios também não substituem o identificador fiscal correto.

O schema admite cBenef como campo estruturalmente opcional, mas a regra de negócio pode exigir sua presença. Além disso, cBenefRBC e cCredPresumido pertencem a estruturas diferentes: preencher um deles não equivale a preencher prod/cBenef. A aceitação de um formato pelo schema também não comprova que o código exista ou seja permitido pela UF.

Exemplo e conferência final

Imagine uma NF-e cujo primeiro item possua um benefício confirmado pela contabilidade e um código válido cadastrado para a operação. Uma integração deixa de levar esse código ao XML, e a SEFAZ retorna 930 para o item. A correção consiste em restabelecer o mapeamento, gerar o arquivo e verificar a presença do código efetivamente aplicável. Não é necessário mudar a tributação apenas porque a informação foi perdida.

Antes do novo envio, confira todos os itens afetados, os valores tributários e a correspondência entre cadastro e XML. Uma correção pode revelar outra inconsistência; eliminar a condição da 930 não garante autorização. Se o retorno persistir, encaminhe ao suporte o XML rejeitado, a resposta completa, a identificação do item e a tabela utilizada, com os dados pessoais protegidos no compartilhamento.

Este roteiro não depende de um menu específico do ALRA nem pressupõe consulta autenticada ou teste de transmissão. A configuração disponível deve ser conferida na instalação utilizada, preservando a orientação fiscal da operação e as particularidades do autorizador.

Fontes e limites da consulta

Conferência documental em 16/10/2026: NT 2019.001 v1.70, páginas 16–19 e 21–22, com inspeção de imagens documentais já existentes das páginas 16, 17 e 21; NT 2021.002 v1.12, páginas 12–13; declarações de campos do schema 010f. PDFs e schema foram reutilizados com seus hashes e datas de captura identificados, sem atribuir nova coleta aos arquivos antigos.

Foram conferidas as regras facultativas de São Paulo, a página estadual de cBenef e a primeira página da tabela versão 20260901. A tabela não foi lida integralmente nem utilizada para prescrever um benefício individual.

Três corpos práticos específicos foram lidos: Omie, atualizado em 01/08/2026; Mainô, de 26/08/2026; e IOB, de 12/08/2024. A restrição à substituição tributária encontrada na Mainô foi descartada. Sugestões antigas de preenchimento e procedimentos de exclusão de itens ou notas da IOB não foram transpostos ao ALRA. Esses guias não comprovam ativação por UF, CST ou ambiente.