cBenef na NF-e: código de benefício por UF e CST
<cBenef>det › prod › cBenefRevisão editorial em 14 de out. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.
cBenef é o código do benefício fiscal utilizado pela unidade federada e aplicado ao item da NF-e ou NFC-e. Fica em /nfeProc/NFe/infNFe/det/prod/cBenef. Ele representa uma informação já fundamentada na legislação e na operação; sua presença no XML não concede um benefício.
Para conferir o campo, é preciso relacionar UF, código, CST, período de vigência e operação. Um código válido em outro estado ou em uma data anterior não é automaticamente válido na nota atual.
Onde verificar o código
O MOC 7, p.18 orienta usar o código adotado na EFD e nas outras declarações, nas UF que o exigem. A NT 2019.001 v1.70, pp.17–22, descreve validações e diferenças de ativação por estado e modelo.
Consulte a tabela publicada pela administração tributária da UF e sua versão aplicável à data da operação. Confira a descrição, fundamento legal, CST compatível, início e término e eventuais condições. Não selecione um código apenas porque o nome do produto parece corresponder à descrição.
Em São Paulo, a página oficial de cBenef, consultada em 13/10/2026, apresenta a versão 20260901. Ela registra também a desativação de SEM CBENEF a partir de 01/07/2026. No Rio Grande do Sul, a Central de Conteúdo da Receita oferece sua própria tabela, identificada com atualização de 10/09/2026 na consulta. São exemplos de fontes estaduais diferentes, não uma lista de códigos intercambiáveis.
Opcional no XSD e exigido em determinadas operações
No PL 010f v1.04, cBenef é estruturalmente opcional, de 0 a 1 por produto. Seu padrão admite conteúdo com 8 ou 10 caracteres e contempla a literal SEM CBENEF, além de conteúdo vazio. A aceitação sintática não prova que um desses conteúdos seja admitido pela UF ou pelo cenário fiscal.
Não use SEM CBENEF, elemento vazio ou código genérico como substituto automático de informação ausente. A NT admite que algumas UF exijam a literal para certos CST; a orientação paulista acima demonstra por que essa possibilidade não pode ser generalizada.
O grupo de ICMS e seu CST também devem refletir o tratamento confirmado. Uma rejeição por incompatibilidade não autoriza trocar o CST para encaixar um código, nem escolher outro benefício para manter o CST.
O que cada rejeição verifica
| Retorno | Verificação documentada | Evidência a comparar |
|---|---|---|
930 |
Exigência de cBenef não atendida no cenário da regra | CST, UF, modelo e presença do campo |
928 |
Código informado para CST sem benefício na tabela | CST e existência de benefícios para ele na UF |
931 |
Compatibilidade do código com CST na UF, conforme a regra | Código exato, linha da tabela estadual e CST |
946 |
Código inexistente ou fora da vigência na UF | Código exato, UF e período |
934 |
Valor ou motivo de desoneração não informado no cenário correspondente | vICMSDeson, motDesICMS e regra de aplicação |
As N12-85/86 verificam exigência ou impossibilidade para o CST; a N12-94 verifica a compatibilidade específica, e a N12-98 verifica existência/vigência. Na versão 1.70, a expressão de vigência aparece riscada na N12-94 (p.18); a conferência de existência e vigência consta da N12-98/946 (p.19). Não são testes idênticos. Sua aplicação é definida por UF, modelo e, conforme a regra, CST.
As N12-85/86/94/98 preservam exceção para devolução interestadual ou com exterior; outras exceções para devolução, ajuste e entrada dependem da UF. A N12-98 possui ainda exceção quando informado CSOSN. Isso não é uma dispensa geral de informar benefício para todo Simples Nacional: obrigação documental e ativação de uma regra são coisas diferentes. NT 2019.001, pp.17–22.
Cronogramas e diferenças estaduais
O quadro da versão 1.70 registra para São Paulo ativação em 06/04/2026 das regras assinaladas como D10, com modelos específicos. Para Santa Catarina, diferencia 01/09/2025, 03/11/2025 e 06/04/2026 entre grupos de validação. Não aplique a data de uma regra a todos os campos ou a todos os estados.
No Espírito Santo, a existência de obrigação documental não se confunde com a ativação automática de todas essas regras: o quadro da NT marca D* nos controles ali listados. A confirmação do caso concreto exige a fonte estadual, o modelo e a regra específica, não apenas a presença ou ausência de rejeição.
cBenef não substitui outros códigos de benefício
cBenefRBC, no ICMS51, identifica benefício de redução de base acumulada com diferimento; gCred/cCredPresumido identifica crédito presumido no seu grupo. O prod/cBenef estudado aqui tem outro contexto. Não copie um código entre esses elementos por semelhança de nome.
Exemplo de leitura sem recomendar um código
Fragmento sintético parcial, com código deliberadamente fictício de 8 caracteres; atende apenas à forma textual e não demonstra validade em tabela estadual:
<cBenef xmlns="http://www.portalfiscal.inf.br/nfe">ZZ000000</cBenef>
ZZ000000 não é sugestão de parametrização. O exemplo demonstra a separação entre formato e existência: passar pelo XSD não faz o código existir, estar vigente ou ser compatível com um CST.
Como investigar e corrigir a causa
Registre o item, UF do emitente, modelo, ambiente, data, finalidade, CST ou CSOSN, código e retorno completo. Localize a tabela estadual correspondente e sua versão; compare os caracteres exatos e o período. Confira se a integração enviou o valor salvo e se reutilizou parametrização de outra empresa ou UF.
Quando o erro for de transcrição ou mapeamento, corrija a origem comprovada. Quando o fundamento do benefício ou o CST estiverem indefinidos, leve ao responsável contábil a operação, produto, documentos e linha da tabela para confirmar elegibilidade e representação. O artigo permite conferir o XML; não decide se a empresa tem direito ao benefício nem qual código deve adotar.
Referência técnica para integração
- XPath completo
/nfeProc/NFe/infNFe/det/prod/cBenef- Namespace
http://www.portalfiscal.inf.br/nfe- Leiaute
- 4.00 · PL_010e_v1.02
- Ocorrências no XSD
- 0–1 no contexto do elemento pai
- Tipo
- inline:xs:string · string
- Preenchimento no catálogo
- Condicional
A ocorrência vale dentro da estrutura XML: um campo obrigatório em um grupo opcional não torna esse grupo obrigatório. A aplicação fiscal depende da operação e da versão da regra.
- pattern
([!-ÿ]{8}|[!-ÿ]{10}|SEM CBENEF)?- whiteSpace
preserve