Pular para o conteúdo
Fiscal ProBiblioteca
NF-e e NFC-e · Produtos e serviços

cBenef na NF-e: código de benefício por UF e CST

<cBenef>det › prod › cBenef

Revisã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