Rejeição 629 — Valor do Produto difere do produto Valor Unitário de Comercialização e Quantidade Comercial

Resumo Rápido

A Rejeição 629 ocorre quando o valor total do produto informado no item da NF-e ou NFC-e é diferente do resultado da multiplicação entre a quantidade comercial e o valor unitário de comercialização.

Na prática, a SEFAZ valida se o campo <vProd> do item corresponde ao cálculo:

vProd = qCom × vUnCom

Quando o valor informado em <vProd> ultrapassa a tolerância aceita em relação ao resultado da multiplicação, a nota é rejeitada.

Solução rápida

1. Identifique o item indicado na rejeição.
2. Verifique a quantidade comercial informada em <qCom>.
3. Verifique o valor unitário de comercialização informado em <vUnCom>.
4. Recalcule o valor do produto.
5. Corrija o campo <vProd>.
6. Gere novamente o XML.
7. Transmita a NF-e ou NFC-e novamente.

Dados rápidos

Diagnóstico Rápido

• O valor total do produto foi calculado corretamente?
• A quantidade comercial está correta?
• O valor unitário de comercialização está correto?
• Existem muitas casas decimais no preço unitário?
• Houve arredondamento antes da geração do XML?
• O item possui unidade comercial diferente da unidade tributável?
• O ERP recalcula o total do item automaticamente?
• O XML foi alterado manualmente?
• A integração enviou quantidade, preço ou total divergente?
• A nota é normal, com `finNFe = 1`?

Mensagem da Rejeição

629 - Valor do Produto difere do produto Valor Unitário de Comercialização e Quantidade Comercial [nItem: 999]

O que significa essa rejeição?

Essa rejeição significa que o valor total do produto informado no item da NF-e ou NFC-e não confere com o cálculo feito a partir da quantidade comercial e do valor unitário de comercialização.

A SEFAZ não valida apenas os totais da nota. Ela também confere a consistência matemática de cada item.

No caso da Rejeição 629, a conferência é feita entre:

<qCom>...</qCom>
<vUnCom>...</vUnCom>
<vProd>...</vProd>

O campo <vProd> precisa representar corretamente o resultado de:

Quantidade comercial × Valor unitário de comercialização

Se houver diferença acima da tolerância aceita pela regra, a autorização é bloqueada.

Campos envolvidos

<qCom>

Quantidade comercial do item.

É a quantidade utilizada para fins comerciais, ou seja, a quantidade vendida, faturada ou negociada com o cliente.

Exemplo:

<qCom>2.0000</qCom>

<vUnCom>

Valor unitário de comercialização.

É o preço unitário utilizado na operação comercial.

Exemplo:

<vUnCom>9.9900</vUnCom>

<vProd>

Valor total bruto do produto no item.

Deve corresponder ao resultado da multiplicação entre <qCom> e <vUnCom>.

Exemplo:

<vProd>19.98</vProd>

Fórmula de validação

A fórmula básica é:

vProd = qCom × vUnCom

Exemplo:

qCom = 2,0000
vUnCom = 9,9900
 
vProd = 2,0000 × 9,9900
vProd = 19,98

O valor correto a ser informado em <vProd> é:

<vProd>19.98</vProd>

Relação com a finalidade da NF-e

A regra é aplicada para NF-e ou NFC-e normal, normalmente quando:

<finNFe>1</finNFe>

Ou seja:

1 = NF-e normal

Em notas complementares, de ajuste, devolução ou outras finalidades específicas, o comportamento pode variar conforme a regra de validação aplicada pela SEFAZ e a forma como o documento foi montado.

Sintomas Comuns

• Rejeição em apenas um item da nota.
• Diferença de poucos centavos.
• Erro após alteração de casas decimais no preço unitário.
• Problema em notas com quantidade fracionada.
• Divergência em itens vendidos por peso, metro, litro ou volume.
• Erro após importação de pedido de venda.
• Diferença entre o pedido e o XML gerado.
• Falha em integração entre e-commerce, pedido e faturamento.
• Valor total do item digitado manualmente.
• Arredondamento feito antes da multiplicação.

Por que essa rejeição acontece?

Quantidade comercial incorreta

A quantidade informada em <qCom> não corresponde à quantidade utilizada para calcular o valor total do produto.

Exemplo:

Quantidade usada no cálculo: 10
Quantidade enviada no XML: 9,9999

Mesmo uma pequena diferença pode gerar divergência no resultado final.

Valor unitário comercial incorreto

O valor informado em <vUnCom> não corresponde ao preço utilizado para calcular o total do item.

Isso pode ocorrer quando o ERP exibe o preço arredondado na tela, mas grava outro valor no banco ou no XML.

Valor total do produto calculado manualmente

Alguns sistemas permitem informar diretamente o total do item.

Quando o usuário altera o total, mas o ERP não recalcula corretamente o preço unitário ou a quantidade, os campos deixam de fechar.

Arredondamento indevido

A rejeição é muito comum quando o ERP arredonda o valor unitário cedo demais.

Exemplo:

Preço real usado no pedido: 3,333333
Preço enviado no XML: 3,33
Quantidade: 3

Se o sistema calcula o total com o valor cheio, mas envia o unitário arredondado, o resultado pode não fechar.

Integração entre sistemas

Pedidos vindos de e-commerce, força de vendas, aplicativos, APIs ou outros ERPs podem enviar:

• Quantidade com casas decimais diferentes.
• Preço unitário arredondado.
• Valor total já calculado.
• Descontos embutidos no preço.
• Total do item divergente.

Quando o faturamento gera o XML sem recalcular ou normalizar esses valores, a rejeição pode ocorrer.

Diferença entre unidade comercial e unidade tributável

A unidade comercial é usada nos campos:

<uCom>
<qCom>
<vUnCom>

A unidade tributável é usada nos campos:

<uTrib>
<qTrib>
<vUnTrib>

A Rejeição 629 valida a unidade comercial.

Não confundir com a rejeição relacionada à unidade tributável.

Causa Raiz

A causa raiz da Rejeição 629 é uma inconsistência aritmética no item da NF-e ou NFC-e.

O ERP informa um valor total do produto que não corresponde ao resultado da multiplicação entre quantidade comercial e valor unitário comercial.

As causas mais frequentes são:

• Arredondamento incorreto.
• Preço unitário com casas decimais insuficientes.
• Quantidade fracionada.
• Valor total informado manualmente.
• Integração enviando valores inconsistentes.
• Conversão incorreta de unidade de medida.
• Regra de desconto aplicada de forma errada.
• Alteração manual do XML.
• Parametrização inadequada de casas decimais no ERP.

Como Resolver

Passo 1

Localize o item informado na rejeição.

A mensagem normalmente traz:

[nItem: 999]

Esse número indica o item da NF-e ou NFC-e onde a divergência foi encontrada.

Passo 2

No XML, localize o grupo do item:

<det nItem="1">
   <prod>
      ...
   </prod>
</det>

Passo 3

Verifique a quantidade comercial:

<qCom>...</qCom>

Passo 4

Verifique o valor unitário de comercialização:

<vUnCom>...</vUnCom>

Passo 5

Recalcule o valor total do produto:

vProd = qCom × vUnCom

Passo 6

Compare o resultado calculado com o valor informado em:

<vProd>...</vProd>

Passo 7

Corrija a origem da divergência.

A correção pode envolver:

• Ajustar a quantidade.
• Ajustar o valor unitário.
• Ajustar o valor total do produto.
• Aumentar casas decimais internas no ERP.
• Revisar arredondamento.
• Corrigir a integração.
• Recalcular o item no faturamento.

Passo 8

Gere novamente o XML.

Passo 9

Transmita a NF-e ou NFC-e novamente.

Exemplo Prático

Uma NFC-e possui um item com os seguintes valores:

Quantidade comercial: 2,0000
Valor unitário comercial: 9,9900
Valor total do produto informado: 20,00

Cálculo correto:

2,0000 × 9,9900 = 19,98

Mas o XML informou:

vProd = 20,00

Resultado:

Rejeição 629

O valor total do produto deve ser corrigido para:

19,98

Exemplo XML

XML com erro

<det nItem="1">
   <prod>
      <cProd>001</cProd>
      <xProd>Produto Exemplo</xProd>
      <NCM>01012100</NCM>
      <CFOP>5102</CFOP>
      <uCom>UN</uCom>
      <qCom>2.0000</qCom>
      <vUnCom>9.9900</vUnCom>
      <vProd>20.00</vProd>
      <uTrib>UN</uTrib>
      <qTrib>2.0000</qTrib>
      <vUnTrib>9.9900</vUnTrib>
      <indTot>1</indTot>
   </prod>
</det>

Por que está errado?

O cálculo correto é:

2,0000 × 9,9900 = 19,98

Mas o XML informou:

<vProd>20.00</vProd>

XML corrigido

<det nItem="1">
   <prod>
      <cProd>001</cProd>
      <xProd>Produto Exemplo</xProd>
      <NCM>01012100</NCM>
      <CFOP>5102</CFOP>
      <uCom>UN</uCom>
      <qCom>2.0000</qCom>
      <vUnCom>9.9900</vUnCom>
      <vProd>19.98</vProd>
      <uTrib>UN</uTrib>
      <qTrib>2.0000</qTrib>
      <vUnTrib>9.9900</vUnTrib>
      <indTot>1</indTot>
   </prod>
</det>

O que mudou?

O campo <vProd> foi corrigido para refletir o resultado da multiplicação entre <qCom> e <vUnCom>.

Exemplo com quantidade fracionada

Imagine uma venda de produto por peso:

qCom = 1,3750
vUnCom = 14,9900

Cálculo:

1,3750 × 14,9900 = 20,61125

Como <vProd> possui duas casas decimais, o valor deve ser arredondado para:

20,61

XML esperado:

<qCom>1.3750</qCom>
<vUnCom>14.9900</vUnCom>
<vProd>20.61</vProd>

Se o ERP informar:

<vProd>20.62</vProd>

pode ocorrer rejeição, dependendo da tolerância e do cálculo aplicado pela SEFAZ.

Diferença entre Rejeição 629 e Rejeição 630

Rejeição 629

Valida o valor do produto com base na unidade comercial:

vProd = qCom × vUnCom

Campos envolvidos:

<qCom>
<vUnCom>
<vProd>

Rejeição 630

Valida o valor do produto com base na unidade tributável:

vProd = qTrib × vUnTrib

Campos envolvidos:

<qTrib>
<vUnTrib>
<vProd>

Em resumo

A Rejeição 629 olha para a quantidade comercial.

A Rejeição 630 olha para a quantidade tributável.

Quando a unidade comercial e a unidade tributável são iguais, normalmente os dois grupos terão os mesmos valores.

Quando são diferentes, como em produtos vendidos em caixa e tributados em unidade, ou vendidos em peça e tributados em quilo, é preciso ter atenção redobrada.

Como Identificar o Problema no ERP

Onde verificar

• Pedido de venda.
• Orçamento.
• Faturamento.
• Cadastro do produto.
• Unidade de medida comercial.
• Tabela de preço.
• Política de casas decimais.
• Integrações externas.
• XML gerado.
• Rotina de arredondamento.

O que procurar

• Diferença entre preço exibido e preço gravado.
• Quantidade truncada.
• Preço unitário truncado.
• Valor total digitado manualmente.
• Desconto embutido no preço unitário.
• Conversão incorreta de unidade.
• Item importado de outro sistema.
• Divergência entre pedido e nota.
• Recalculo parcial no faturamento.
• Alteração manual do XML.

Impactos para a Empresa

Fiscal

A NF-e ou NFC-e não é autorizada.

Faturamento

A venda fica bloqueada até a correção do item.

Operacional

A expedição ou entrega pode atrasar.

Financeiro

A cobrança pode ser postergada, principalmente quando a emissão da nota libera o boleto, PIX, duplicata ou integração financeira.

Suporte

O suporte ERP pode precisar analisar XML, pedido, parametrização de casas decimais e integração.

Cliente

O cliente pode perceber atraso na emissão da nota, principalmente em operação de balcão, e-commerce ou faturamento urgente.

O que NÃO Fazer

• Não alterar apenas o XML manualmente em produção.
• Não corrigir somente o total da nota.
• Não ignorar diferença de centavos.
• Não reduzir casas decimais internas sem analisar impacto.
• Não misturar unidade comercial com unidade tributável.
• Não forçar o envio sem corrigir a origem do cálculo.
• Não assumir que o problema está na SEFAZ.
• Não ajustar o preço de venda sem validar o impacto comercial.
• Não corrigir apenas um item se a origem for uma regra geral do ERP.

Caso Real

Uma empresa vendia produtos por peso, com quatro casas decimais na quantidade e quatro casas decimais no valor unitário.

Na tela do pedido, o ERP exibia o preço unitário com apenas duas casas decimais, mas internamente calculava o total com mais casas.

Ao gerar o XML, o sistema enviava <vUnCom> arredondado, enquanto <vProd> era calculado com o valor interno completo.

O resultado era uma diferença de centavos entre:

qCom × vUnCom

e:

vProd

A SEFAZ rejeitava a nota pela Rejeição 629.

A correção foi padronizar a rotina de cálculo do item e garantir que o mesmo valor unitário enviado no XML fosse usado para calcular o <vProd>.

Como Evitar Essa Rejeição

• Definir padrão de casas decimais para quantidade e preço unitário.
• Usar o mesmo valor unitário no cálculo interno e no XML.
• Evitar truncamento de valores.
• Tratar corretamente quantidades fracionadas.
• Validar XMLs antes da transmissão.
• Testar vendas por peso, volume, metro e outras unidades fracionadas.
• Auditar integrações de pedidos.
• Recalcular o item no faturamento antes da geração do XML.
• Impedir alteração manual inconsistente de total do item.
• Criar validação preventiva no ERP.

Validação preventiva no ERP

Uma validação simples antes da transmissão pode evitar a rejeição.

Exemplo lógico:

valor_calculado = qCom × vUnCom
 
se diferença entre valor_calculado e vProd for maior que a tolerância:
    bloquear geração da NF-e
    exibir item divergente
    solicitar recálculo do item

Também é recomendável exibir no erro:

• Número do item.
• Código do produto.
• Quantidade comercial.
• Valor unitário comercial.
• Valor total informado.
• Valor total calculado.
• Diferença encontrada.

Isso reduz muito o tempo de atendimento do suporte.

Fluxograma de Diagnóstico

Recebeu Rejeição 629?
 
├─ Localizou o nItem informado?
│
├─ Não → Abrir XML e localizar item com divergência
│
└─ Sim
    │
    ├─ qCom está correto?
    │
    ├─ Não → Corrigir quantidade comercial
    │
    └─ Sim
        │
        ├─ vUnCom está correto?
        │
        ├─ Não → Corrigir valor unitário comercial
        │
        └─ Sim
            │
            ├─ vProd = qCom × vUnCom?
            │
            ├─ Não → Corrigir vProd ou rotina de cálculo
            │
            └─ Sim → Revisar arredondamento, casas decimais e integração

FAQ

O que é a Rejeição 629?

É a rejeição que ocorre quando o valor total do produto não confere com a multiplicação entre quantidade comercial e valor unitário comercial.

Qual campo devo corrigir?

Depende da origem do erro.

Você deve verificar:

<qCom>
<vUnCom>
<vProd>

O campo <vProd> deve fechar com o resultado de <qCom> × <vUnCom>.

Diferença de R$ 0,01 pode gerar rejeição?

A regra admite tolerância em algumas situações, mas não é seguro depender disso.

O ideal é gerar o XML com os valores matematicamente consistentes.

A Rejeição 629 é igual à Rejeição 630?

Não.

A 629 valida quantidade e valor unitário de comercialização.

A 630 valida quantidade e valor unitário de tributação.

O campo <indTot> interfere nessa rejeição?

Não diretamente.

O <indTot> indica se o valor do item compõe o total da NF-e, mas a Rejeição 629 valida a consistência do próprio item entre <qCom>, <vUnCom> e <vProd>.

Desconto influencia a Rejeição 629?

Normalmente o desconto é informado em campo próprio, como <vDesc>, e não deve ser usado para “forçar” o <vProd>.

Se o ERP embute desconto no preço unitário ou no total de forma inconsistente, a rejeição pode ocorrer.

Pode corrigir apenas o XML?

Não é recomendado.

A correção deve ser feita na origem: pedido, item da nota, cálculo do ERP ou integração.

Essa rejeição ocorre em NFC-e?

Sim.

A regra pode ser aplicada para NF-e modelo 55 e NFC-e modelo 65.

Essa rejeição aparece por item?

Sim.

A mensagem normalmente informa o item com problema por meio do marcador [nItem: 999].

O que fazer quando o preço possui muitas casas decimais?

O ERP deve manter uma regra consistente de cálculo e arredondamento, garantindo que o valor unitário enviado no XML seja compatível com o valor total informado no item.

Base Legal

• Projeto NF-e
• Manual de Orientação do Contribuinte (MOC)
• MOC 7.0 — Anexo I — Leiaute e Regras de Validação da NF-e e NFC-e
• Nota Técnica 2011.005
• Regra de Validação I11-10
• Regras de Validação da NF-e e NFC-e

Artigos Relacionados

• Rejeição 630
• Rejeição 564
• Rejeição 610
• Rejeição 483
• Rejeição 537
• Valor do Produto
• Unidade Comercial
• Unidade Tributável
• XML da NF-e
• Faturamento
• Arredondamento na NF-e

Resumo

A Rejeição 629 ocorre quando o valor total do produto informado no item da NF-e ou NFC-e é diferente do resultado da multiplicação entre a quantidade comercial e o valor unitário de comercialização. A validação compara os campos <qCom>, <vUnCom> e <vProd>. O problema normalmente está relacionado a arredondamentos, casas decimais, quantidade fracionada, valor unitário incorreto, integrações ou cálculo inconsistente no ERP. A solução consiste em revisar o item indicado, recalcular o valor do produto, corrigir a origem da divergência e transmitir novamente o documento.