Rejeição 1035 — Valor da Alíquota Efetiva do IBS da UF calculado incorretamente

Resumo Rápido

A Rejeição 1035 ocorre quando a NF-e ou NFC-e informa a alíquota efetiva do IBS da UF, no campo <pAliqEfet>, com valor diferente do cálculo esperado pela regra de validação da SEFAZ.

Essa rejeição está relacionada ao grupo de redução de alíquota estadual do IBS, normalmente informado em <gIBSUF><gRed>. Quando esse grupo é preenchido, a SEFAZ valida se a alíquota efetiva foi calculada corretamente a partir da alíquota do IBS da UF e do percentual de redução de alíquota.

Em operações com compra governamental, o cálculo também pode considerar o redutor próprio do grupo <gCompraGov>.

Solução rápida

Verifique se o item possui o grupo <gIBSUF><gRed>.
Confira a alíquota informada em <pIBSUF>.
Confira o percentual de redução informado em <pRedAliq>.
Recalcule o campo <pAliqEfet>.
Se houver compra governamental, aplique também o redutor <pRedutor>.
Arredonde a alíquota efetiva com 4 casas decimais.
Gere novamente o XML e retransmita a NF-e.

Dados rápidos

Diagnóstico Rápido

O item possui grupo de redução de alíquota do IBS da UF?
O campo `<pIBSUF>` está correto?
O campo `<pRedAliq>` está correto para o `cClassTrib` utilizado?
O campo `<pAliqEfet>` foi calculado pela fórmula correta?
O ERP tratou percentuais como percentual, e não como fator decimal?
O cálculo foi arredondado com 4 casas decimais?
Existe grupo de compra governamental na operação?
Se houver compra governamental, o redutor `<pRedutor>` foi aplicado?
A operação utiliza CST e cClassTrib que permitem redução de alíquota estadual?
O XML foi gerado por integração externa ou customização fiscal?

Mensagem da Rejeição

1035 - Valor da Alíquota Efetiva do IBS da UF calculado incorretamente [nItem: 999]

O que significa essa rejeição?

A Rejeição 1035 significa que a SEFAZ recalculou a alíquota efetiva do IBS da UF e encontrou valor diferente daquele informado no XML.

A alíquota efetiva é o resultado da aplicação da redução de alíquota sobre a alíquota cheia do IBS da UF.

Na prática, quando o XML informa redução de alíquota estadual, não basta preencher o percentual de redução. O sistema também precisa informar o resultado final da alíquota após a redução.

Esse resultado é informado no campo:

<pAliqEfet>...</pAliqEfet>

Se o valor informado nesse campo não bater com a fórmula esperada, a NF-e ou NFC-e é rejeitada.

O que é a Alíquota Efetiva do IBS da UF?

A Alíquota Efetiva do IBS da UF representa a alíquota realmente aplicada após a redução prevista para determinada classificação tributária.

Ela é diferente da alíquota cheia.

Por exemplo:

Alíquota do IBS da UF: 0,1000%
Redução de alíquota: 60,0000%
Alíquota efetiva: 0,0400%

Nesse caso, a operação não usa a alíquota cheia de 0.1000, mas sim a alíquota reduzida de 0.0400.

Campos XML envolvidos

Os campos mais importantes são:

`<pIBSUF>`

Alíquota cheia do IBS da UF.

`<pRedAliq>`

Percentual de redução da alíquota.

`<pAliqEfet>`

Alíquota efetiva após a aplicação da redução.

`<gCompraGov>`

Grupo de compra governamental, quando aplicável.

`<pRedutor>`

Percentual redutor aplicado em operações de compra governamental, quando informado.

Fórmula de cálculo

Sem compra governamental

Quando não houver grupo <gCompraGov>, a fórmula esperada é:

pAliqEfet = pIBSUF × (1 - pRedAliq / 100)

Com compra governamental

Quando houver grupo <gCompraGov>, a fórmula passa a considerar também o redutor da compra governamental:

pAliqEfet = pIBSUF × (1 - pRedAliq / 100) × (1 - pRedutor / 100)

O resultado deve ser informado com 4 casas decimais.

Sintomas Comuns

Rejeição apenas em itens com redução de alíquota.
Erro após implantação das regras de IBS/CBS.
Divergência entre cálculo do ERP e cálculo da SEFAZ.
Campo <pAliqEfet> calculado com 2 casas decimais.
Percentual tratado como fator decimal.
Redutor de compra governamental ignorado.
Rejeição apenas em determinados cClassTrib.
Erro em operações parametrizadas por integração fiscal.
XML aparentemente correto, mas com arredondamento incorreto.

Por que essa rejeição acontece?

Fórmula incorreta

O ERP calcula a alíquota efetiva usando uma lógica diferente da esperada pela SEFAZ.

Percentual tratado como fator decimal

O sistema pode tratar 60% como 0.60 em um ponto do cálculo e como 60.0000 em outro, gerando inconsistência.

Arredondamento incorreto

O campo <pAliqEfet> deve considerar 4 casas decimais. Arredondar com 2 casas ou truncar o valor pode gerar rejeição.

Redutor de compra governamental não aplicado

Quando houver <gCompraGov>, o redutor da compra governamental também deve ser considerado no cálculo.

Redução incompatível com o `cClassTrib`

A classificação tributária pode possuir percentual de redução específico. Se o ERP aplicar percentual diferente, a alíquota efetiva ficará incorreta.

Parametrização fiscal incorreta

A regra fiscal pode estar associando CST, cClassTrib, redução e alíquota de forma inconsistente.

Customização ou integração externa

Integrações podem enviar o valor do campo <pAliqEfet> já calculado, mas usando regra diferente da rotina oficial do ERP.

Causa Raiz

A causa raiz da Rejeição 1035 é a inconsistência matemática entre a alíquota cheia do IBS da UF, o percentual de redução e a alíquota efetiva informada no XML.

Em sistemas ERP, o problema normalmente está em uma destas origens:

Cadastro fiscal do cClassTrib.
Regra de redução de alíquota.
Fórmula de cálculo do IBS da UF.
Tratamento incorreto de percentuais.
Arredondamento com quantidade errada de casas decimais.
Falta de tratamento para compra governamental.
Integração fiscal enviando valor calculado manualmente.
Customização antiga reaproveitada para IBS/CBS.

Como Resolver

Passo 1

Identifique o item indicado na rejeição.

A mensagem geralmente apresenta:

[nItem: 999]

Esse número indica o item da NF-e ou NFC-e que contém o erro.

Passo 2

Localize no XML o grupo do IBS/CBS do item.

Procure pelo grupo relacionado ao IBS da UF:

<gIBSUF>
   ...
</gIBSUF>

Passo 3

Verifique se existe grupo de redução de alíquota.

<gRed>
   <pRedAliq>...</pRedAliq>
   <pAliqEfet>...</pAliqEfet>
</gRed>

Passo 4

Confira a alíquota cheia do IBS da UF.

<pIBSUF>...</pIBSUF>

Passo 5

Confira o percentual de redução.

<pRedAliq>...</pRedAliq>

Passo 6

Recalcule a alíquota efetiva.

Sem compra governamental:

pAliqEfet = pIBSUF × (1 - pRedAliq / 100)

Com compra governamental:

pAliqEfet = pIBSUF × (1 - pRedAliq / 100) × (1 - pRedutor / 100)

Passo 7

Arredonde o resultado com 4 casas decimais.

Passo 8

Corrija a parametrização no ERP.

Evite ajustar apenas o XML manualmente.

Passo 9

Gere novamente o XML.

Passo 10

Transmita novamente a NF-e ou NFC-e.

Exemplo Prático

Uma empresa emite uma NF-e com IBS da UF e redução de alíquota.

Dados do item:

pIBSUF = 0,1000
pRedAliq = 60,0000

Cálculo correto:

pAliqEfet = 0,1000 × (1 - 60,0000 / 100)
pAliqEfet = 0,1000 × 0,4000
pAliqEfet = 0,0400

Entretanto, o ERP informou:

pAliqEfet = 0,0300

Resultado:

Rejeição 1035

Exemplo XML

XML com erro

<gIBSUF>
   <pIBSUF>0.1000</pIBSUF>
   <gRed>
      <pRedAliq>60.0000</pRedAliq>
      <pAliqEfet>0.0300</pAliqEfet>
   </gRed>
</gIBSUF>

XML corrigido

<gIBSUF>
   <pIBSUF>0.1000</pIBSUF>
   <gRed>
      <pRedAliq>60.0000</pRedAliq>
      <pAliqEfet>0.0400</pAliqEfet>
   </gRed>
</gIBSUF>

O que mudou?

O campo <pAliqEfet> passou a refletir corretamente a alíquota efetiva do IBS da UF após a redução de 60%.

Exemplo com compra governamental

Em uma operação com compra governamental, o cálculo pode exigir a aplicação de mais um redutor.

Dados:

pIBSUF = 0,1000
pRedAliq = 60,0000
pRedutor = 5,0000

Cálculo:

pAliqEfet = 0,1000 × (1 - 60,0000 / 100) × (1 - 5,0000 / 100)
pAliqEfet = 0,1000 × 0,4000 × 0,9500
pAliqEfet = 0,0380

Se o ERP ignorar o redutor de compra governamental e informar 0.0400, poderá ocorrer a Rejeição 1035.

Como Identificar o Problema no ERP

Onde verificar

Cadastro de CST do IBS/CBS.
Cadastro de cClassTrib.
Regra fiscal da operação.
Parametrização de redução de alíquota.
Configuração de compra governamental.
Motor de cálculo tributário.
Rotina de geração do XML.
Integrações fiscais.
Logs de cálculo do item.

O que procurar

Percentual de redução incorreto.
Alíquota cheia divergente.
Alíquota efetiva calculada manualmente.
Arredondamento com 2 casas.
Valor truncado em vez de arredondado.
Campo <pAliqEfet> fixo no cadastro.
Redutor de compra governamental ignorado.
cClassTrib incompatível com redução utilizada.
Diferença entre cálculo exibido na tela e cálculo enviado no XML.

Impactos para a Empresa

Fiscal

A NF-e ou NFC-e não é autorizada enquanto a alíquota efetiva estiver incorreta.

Faturamento

A operação pode ficar bloqueada até a correção da parametrização fiscal.

TI / ERP

Pode exigir revisão do motor de cálculo, atualização de versão ou correção de integração.

Contabilidade

Pode indicar uso incorreto de CST, cClassTrib ou percentual de redução.

Operação

Pode gerar atraso em venda, expedição, entrega ou emissão em caixa.

O que NÃO Fazer

Não alterar apenas o XML manualmente.
Não informar <pAliqEfet> sem recalcular a regra fiscal.
Não tratar percentual como fator decimal sem padronização.
Não arredondar a alíquota efetiva com apenas 2 casas decimais.
Não ignorar o grupo <gCompraGov> quando ele existir.
Não copiar cálculo de ICMS antigo para IBS/CBS sem revisar a fórmula.
Não assumir que a rejeição é erro da SEFAZ.
Não manter valor fixo de alíquota efetiva em tabela sem vínculo com pIBSUF e pRedAliq.

Caso Real

Uma empresa parametrizou o IBS/CBS para testes em homologação e cadastrou corretamente o percentual de redução de alíquota para determinado cClassTrib.

No entanto, o ERP calculava o campo <pAliqEfet> com apenas 2 casas decimais, reaproveitando uma rotina antiga de exibição de percentuais fiscais.

Na tela do sistema, o cálculo parecia correto, mas o XML era gerado com valor truncado.

Ao transmitir a NF-e, a SEFAZ retornou a Rejeição 1035.

A correção foi ajustar a rotina de cálculo para manter 4 casas decimais no campo <pAliqEfet>, respeitando a fórmula da alíquota efetiva do IBS da UF.

Como Evitar Essa Rejeição

Atualizar o ERP conforme as versões da NT 2025.002.
Manter tabela de CST e cClassTrib atualizada.
Validar os percentuais de redução permitidos por classificação tributária.
Calcular <pAliqEfet> sempre a partir de <pIBSUF> e <pRedAliq>.
Aplicar o redutor de compra governamental quando existir.
Trabalhar com 4 casas decimais nos campos percentuais.
Testar XMLs em homologação.
Auditar integrações fiscais.
Revisar customizações no motor tributário.
Comparar o XML gerado com o cálculo esperado pela regra de validação.

Fluxograma de Diagnóstico

Recebeu Rejeição 1035?
 
├─ O item possui gIBSUF/gRed?
│
├─ Não → Revisar regra aplicada ao item
│
└─ Sim
    │
    ├─ pIBSUF está correto?
    │   ├─ Não → Corrigir alíquota do IBS da UF
    │   └─ Sim
    │
    ├─ pRedAliq está correto para o cClassTrib?
    │   ├─ Não → Corrigir percentual de redução
    │   └─ Sim
    │
    ├─ Existe gCompraGov?
    │   ├─ Sim → Aplicar também pRedutor
    │   └─ Não → Calcular sem redutor governamental
    │
    ├─ pAliqEfet bate com a fórmula?
    │   ├─ Não → Corrigir cálculo
    │   └─ Sim
    │
    └─ Revisar arredondamento com 4 casas decimais

FAQ

O que é a Rejeição 1035?

É a rejeição que ocorre quando a alíquota efetiva do IBS da UF foi informada com valor diferente do cálculo esperado pela SEFAZ.

Qual campo causa a Rejeição 1035?

O principal campo é <pAliqEfet>, dentro do grupo de redução de alíquota do IBS da UF.

Qual é a fórmula da alíquota efetiva?

Sem compra governamental:

pAliqEfet = pIBSUF × (1 - pRedAliq / 100)

Com compra governamental:

pAliqEfet = pIBSUF × (1 - pRedAliq / 100) × (1 - pRedutor / 100)

A rejeição pode ocorrer por arredondamento?

Sim. O campo deve ser calculado com 4 casas decimais, respeitando o arredondamento esperado.

Essa rejeição tem relação com o CST e o cClassTrib?

Sim. O CST e o cClassTrib determinam se a operação permite ou exige redução de alíquota e qual percentual deve ser utilizado.

Posso corrigir apenas o campo `<pAliqEfet>` no XML?

Não é recomendado. O correto é corrigir a regra fiscal ou o cálculo no ERP para evitar reincidência.

Compra governamental muda o cálculo?

Sim. Quando o grupo <gCompraGov> estiver informado, o cálculo da alíquota efetiva deve considerar também o redutor de compra governamental.

Essa rejeição ocorre em NF-e e NFC-e?

Sim. A rejeição pode ocorrer em documentos modelo 55 e 65, conforme a regra de validação aplicada.

A alíquota efetiva é o mesmo que a alíquota cheia?

Não. A alíquota cheia é informada em <pIBSUF>. A alíquota efetiva é o resultado após a aplicação da redução de alíquota.

O ERP pode causar essa rejeição?

Sim. Essa rejeição normalmente está ligada a parametrização fiscal, cálculo tributário, arredondamento ou integração.

Base Legal

Projeto NF-e.
Nota Técnica 2025.002 — Reforma Tributária do Consumo.
Manual de Orientação do Contribuinte (MOC).
Regras de Validação da NF-e/NFC-e.
Lei Complementar nº 214/2025.

Resumo

A Rejeição 1035 ocorre quando o valor da alíquota efetiva do IBS da UF, informado no campo <pAliqEfet>, não corresponde ao cálculo esperado pela SEFAZ. Essa validação aparece quando há redução de alíquota estadual no grupo <gIBSUF><gRed>. A solução é revisar a alíquota cheia <pIBSUF>, o percentual de redução <pRedAliq>, o redutor de compra governamental quando aplicável, o arredondamento com 4 casas decimais e a parametrização fiscal do ERP.

Rejeição 1035 — Valor da Alíquota Efetiva do IBS da UF calculado incorretamente

Conteúdo relacionado