pRedBCEfet no ICMS60: redução da base efetiva e cálculo
<pRedBCEfet>det › imposto › ICMS › ICMS60 › pRedBCEfetRevisão editorial em 14 de out. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.
pRedBCEfet em ICMS60 é o percentual de redução usado para obter a base de cálculo efetiva, considerando a operação própria do substituído como se estivesse no regime comum. Ele informa a parcela percentual retirada da base, e não a alíquota do imposto nem a parcela que permanece.
Caminho desta página: /nfeProc/NFe/infNFe/det/imposto/ICMS/ICMS60/pRedBCEfet. O prefixo nfeProc identifica o XML processado; no XML da NF-e antes do protocolo, o percurso começa em NFe. O campo pertence ao item det, não aos totais.
Neste artigo
- Qual base é reduzida e qual fator usar?
- Como conferir redução e ausência de redução?
- Quando os quatro campos efetivos aparecem?
- Qual formato a redução usa no XML?
- Como diagnosticar base efetiva incorreta?
Qual base é reduzida e qual fator usar?
A descrição N35 do manual indica vProd × (1 − percentual de redução). Como o XML escreve 10 para representar 10%, a forma aritmética explícita é vBCEfet = vProd × (1 − pRedBCEfet ÷100). Redução 10% deixa 90% da base; não deixa 10%.
O valor de partida documentado é prod/vProd, não o total da NF-e, a base histórica de ST nem o ICMS retido. A redução efetiva não equivale à redução de base pRedBCST de outro grupo, nem ao percentual de diferimento pDif. Cada um desses campos altera uma grandeza diferente. Fontes: MOC 7.0, Anexo I, p. 35; NT 2018.005 v 1.52, pp. 14–15.
Como conferir redução e ausência de redução?
Considere apenas um produto fictício com vProd=500.00 e alíquota efetiva fictícia 18%. O parâmetro que varia aqui é a redução:
| Redução assumida | Parcela restante | Base efetiva | Imposto efetivo |
|---|---|---|---|
| 10% | 90% | 500,00×0,90=450,00 | 450,00×0,18=81,00 |
| 30% | 70% | 500,00×0,70=350,00 | 350,00×0,18=63,00 |
| 0% explícito | 100% | 500,00×1,00=500,00 | 500,00×0,18=90,00 |
Redução 30% não gera base 150,00: 150,00 é a parcela retirada, enquanto 350,00 é o restante. No último cenário, pRedBCEfet=0.00 preserva ausência de redução já confirmada; falta de informação não autoriza assumir esse zero. Os percentuais são fictícios e não recomendam benefício. Use precisão decimal e representação monetária com duas casas; o XSD não define sozinho um direito à redução. Fontes: MOC 7.0, Anexo I, p. 35; NT 2018.005 v 1.52, pp. 14–15.
Quando os quatro campos efetivos aparecem?
As informações efetivas representam a operação própria do contribuinte substituído caso ela estivesse submetida ao regime comum de tributação. Não são os valores históricos da retenção. O bloco usa quatro campos: pRedBCEfet, percentual de redução; vBCEfet, base efetiva; pICMSEfet, alíquota efetiva; vICMSEfet, imposto efetivo. O XSD torna a sequência opcional e exige os quatro filhos quando ela é informada.
A N12-82, para modelos 55/65, CST 60 e indFinal=1, prevê a rejeição 906 pela ausência das informações, com implementação opcional a critério da UF. A antiga N33-10 foi removida; não é uma exigência adicional a somar à N12-82. O fato de o grupo ser opcional no XSD não afasta uma exigência da UF. Por outro lado, sua existência no esquema não prova obrigatoriedade em toda operação. Fontes: NT 2018.005 v 1.52, pp. 14–15 e 22; MOC 7.0, Anexo I, pp. 34–35 e 113.
Se o bloco se aplica e a redução confirmada é zero, o campo pode registrar esse zero explicitamente junto da base, alíquota e valor. Omitir apenas pRedBCEfet deixa a sequência incompleta. A informação fiscal que autorizaria usar zero precisa existir; não é fornecida pelo fato de o tipo aceitar sua representação.
Qual formato a redução usa no XML?
O tipo é TDec_0302a04Opc, com até 3 dígitos inteiros e, quando há fração,2 a 4 casas. 10.0000 significa 10%; 0.00 é uma representação de zero aceita pelo padrão literal. O texto da anotação do tipo faz uma descrição geral, mas a condição real exige conferir o padrão e o uso fiscal; não trate Opc como dispensa do filho dentro da sequência.
O tipo não é TDec_0302a04Max100, usado em outro campo. Sua aceitação estrutural não autoriza percentuais arbitrários ou resultado negativo. Uma redução que gere base negativa exige revisar parâmetro e interpretação, sem transformar essa aceitação de literal em validação fiscal.
Trecho parcial de ICMS60, com vProd=500.00 e redução 10% fictícios, sem validade como nota pronta:
<ICMS60 xmlns="http://www.portalfiscal.inf.br/nfe">
<orig>0</orig>
<CST>60</CST>
<vBCSTRet>1000.00</vBCSTRet>
<pST>20.0000</pST>
<vICMSSubstituto>90.00</vICMSSubstituto>
<vICMSSTRet>90.00</vICMSSTRet>
<vBCFCPSTRet>1000.00</vBCFCPSTRet>
<pFCPSTRet>2.0000</pFCPSTRet>
<vFCPSTRet>20.00</vFCPSTRet>
<pRedBCEfet>10.0000</pRedBCEfet>
<vBCEfet>450.00</vBCEfet>
<pICMSEfet>18.0000</pICMSEfet>
<vICMSEfet>81.00</vICMSEfet>
</ICMS60>
O campo é o primeiro do bloco efetivo; depois vêm base, alíquota e valor. Fontes: pacote oficial PL 010f, tipos e ICMS60.
Como diagnosticar base efetiva incorreta?
Compare vProd do item, o percentual confirmado e o fator restante. Com 500,00 e redução 10%, base 50,00 indicaria aplicação da parcela reduzida em vez da parcela restante; base 5,00 pode indicar divisão por 100 repetida. A hipótese precisa ser confirmada na memória de cálculo, não apenas no número final.
Para 906, confira os quatro campos e as condições da N12-82, com implementação opcional pela UF. Não remova o grupo nem altere indFinal para contornar uma exigência aplicável. Se a divergência estiver na redução cadastrada, leve ao responsável contábil produto, data, operação, UF e fundamento do parâmetro. Após confirmação, corrija a fonte e gere outro XML de teste, preservando a versão assinada e os zeros manuais válidos. Fontes: NT 2018.005 v 1.52, p. 22; MOC 7.0, Anexo I, p. 35.
Fontes oficiais
- MOC 7.0 — Anexo I, Leiaute e Regras de Validação NF-e/NFC-e — 7.00, novembro/2020; pp. 33–35 grupo N08; pp. 112–113 N23-10, N27b-10/N27b-20/N27d-10; pp. 120 e 140 totais.
- Nota Técnica 2018.005 — Alteração de leiaute NF-e/NFC-e — 1.52, julho/2025; pp. 4 e 7 histórico; pp. 14–15 grupo ICMS60; p. 22 regras N12-81/N12-82.
- Schemas NF-e/NFC-e — Leiaute NF-e 4.00 — PL_010f_v1.04, catálogo publicado 31/08/2026; ICMS53 linhas 2953–3018; ICMS60 linhas 3019–3111; tipo Torig; sequência e minOccurs.
- Tipos básicos NF-e 4.00 — PL_010f_v1.04; TDec_1104v, TDec_1302, TDec_0302a04, TDec_0302a04Opc, TDec_0302a04Max100.
Leituras relacionadas
- vBCEfet em ICMS60 —
/nfeProc/NFe/infNFe/det/imposto/ICMS/ICMS60/vBCEfet. - pICMSEfet em ICMS60 —
/nfeProc/NFe/infNFe/det/imposto/ICMS/ICMS60/pICMSEfet. - vICMSEfet em ICMS60 —
/nfeProc/NFe/infNFe/det/imposto/ICMS/ICMS60/vICMSEfet. - ICMS60 em ICMS60 —
/nfeProc/NFe/infNFe/det/imposto/ICMS/ICMS60.
Referência técnica para integração
- XPath completo
/nfeProc/NFe/infNFe/det/imposto/ICMS/ICMS60/pRedBCEfet- Namespace
http://www.portalfiscal.inf.br/nfe- Leiaute
- 4.00 · PL_010e_v1.02
- Ocorrências no XSD
- 1–1 no contexto do elemento pai
- Tipo
- TDec_0302a04Opc · 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
0\.[0-9]{2,4}|[1-9]{1}[0-9]{0,2}(\.[0-9]{2,4})?- whiteSpace
preserve