Rejeição 629 — Valor do Produto difere do produto Valor Unitário de Comercialização e Quantidade Comercial
Índice do artigo
- Resumo Rápido
- Solução rápida
- Dados rápidos
- Diagnóstico Rápido
- Mensagem da Rejeição
- O que significa essa rejeição?
- Campos envolvidos
- <qCom>
- <vUnCom>
- <vProd>
- Fórmula de validação
- Relação com a finalidade da NF-e
- Sintomas Comuns
- Por que essa rejeição acontece?
- Quantidade comercial incorreta
- Valor unitário comercial incorreto
- Valor total do produto calculado manualmente
- Arredondamento indevido
- Integração entre sistemas
- Diferença entre unidade comercial e unidade tributável
- Causa Raiz
- Como Resolver
- Passo 1
- Passo 2
- Passo 3
- Passo 4
- Passo 5
- Passo 6
- Passo 7
- Passo 8
- Passo 9
- Exemplo Prático
- Exemplo XML
- XML com erro
- Por que está errado?
- XML corrigido
- O que mudou?
- Exemplo com quantidade fracionada
- Diferença entre Rejeição 629 e Rejeição 630
- Rejeição 629
- Rejeição 630
- Em resumo
- Como Identificar o Problema no ERP
- Onde verificar
- O que procurar
- Impactos para a Empresa
- Fiscal
- Faturamento
- Operacional
- Financeiro
- Suporte
- Cliente
- O que NÃO Fazer
- Caso Real
- Como Evitar Essa Rejeição
- Validação preventiva no ERP
- Fluxograma de Diagnóstico
- FAQ
- O que é a Rejeição 629?
- Qual campo devo corrigir?
- Diferença de R$ 0,01 pode gerar rejeição?
- A Rejeição 629 é igual à Rejeição 630?
- O campo <indTot> interfere nessa rejeição?
- Desconto influencia a Rejeição 629?
- Pode corrigir apenas o XML?
- Essa rejeição ocorre em NFC-e?
- Essa rejeição aparece por item?
- O que fazer quando o preço possui muitas casas decimais?
- Base Legal
- Artigos Relacionados
- Resumo

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 × vUnComQuando 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
- Identifique o item indicado na rejeição.
- Verifique a quantidade comercial informada em
<qCom>. - Verifique o valor unitário de comercialização informado em
<vUnCom>. - Recalcule o valor do produto.
- Corrija o campo
<vProd>. - Gere novamente o XML.
- 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çãoSe 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 × vUnComExemplo:
qCom = 2,0000
vUnCom = 9,9900
vProd = 2,0000 × 9,9900
vProd = 19,98O 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 normalEm 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,9999Mesmo 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: 3Se 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 × vUnComPasso 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,00Cálculo correto:
2,0000 × 9,9900 = 19,98Mas o XML informou:
vProd = 20,00Resultado:
Rejeição 629O valor total do produto deve ser corrigido para:
19,98Exemplo 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,98Mas 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,9900Cálculo:
1,3750 × 14,9900 = 20,61125Como <vProd> possui duas casas decimais, o valor deve ser arredondado para:
20,61XML 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 × vUnComCampos envolvidos:
<qCom>
<vUnCom>
<vProd>Rejeição 630
Valida o valor do produto com base na unidade tributável:
vProd = qTrib × vUnTribCampos 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 × vUnCome:
vProdA 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 itemTambé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çãoFAQ
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.