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

vUnCom: valor unitário de comercialização na NF-e e NFC-e

<vUnCom>det › prod › vUnCom

Revisão editorial em 26 de set. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.

vUnCom é o valor por unidade comercial do item, na mesma unidade de uCom e quantidade de qCom. É obrigatório em det/prod e admite até dez casas decimais. O preço de uma caixa e o preço de uma unidade individual podem ser diferentes, mesmo para o mesmo produto. A definição está no MOC 7.0, Anexo I, I10a, página 18.

Nesta página: precisão, divisão e multiplicação, desconto, conversão, diagnóstico.

Precisão do unitário e formato no XML

O tipo TDec_1110v admite zero ou valor positivo com até 11 dígitos inteiros e até dez casas decimais. 10, 10.00 e 33.3333333333 são representações possíveis. Não é necessário sempre escrever dez casas. Use ponto decimal, sem separador de milhares, símbolo monetário, sinal negativo ou notação científica. R$ 10,00, 10,00, 01.00 e 1.12345678901 não respeitam o padrão. Confira prod/vUnCom e TDec_1110v no pacote oficial PL_010c.

O extremo lexical também pode incluir fração, como 99999999999.9999999999; não se deve descrever o domínio como limitado ao inteiro 99999999999. Isso é capacidade de representação, não um preço sugerido. Zero aceito pelo tipo também não prova que preço zero corresponda à operação. Preserve um zero explícito quando esse for o dado real aplicável; não transforme preço ausente em zero para preencher a tag.

Por que o MOC menciona vProd dividido por qCom

O MOC trata vUnCom como informativo quanto à precisão escolhida pelo contribuinte e registra que, para efeitos de cálculo, o unitário será obtido por vProd/qCom. Essa observação não torna o campo opcional nem elimina a conferência aritmética do documento.

A regra facultativa I11-10/629, para documento normal (finNFe=1), compara vProd com vUnCom × qCom. A nota (*4) manda arredondar o resultado da multiplicação a duas casas e admite tolerância de R$ 0,01 para mais ou menos na validação. As duas informações tratam de precisão e coerência entre quantidade, unitário e bruto; não exigem igualdade literal entre números com quantidades diferentes de casas. MOC, página 18, regra na página 93 e nota (*4) na página 140.

Exemplo sintético: três unidades têm bruto de R$ 100,00. A divisão 100/3 é uma dízima. Informando vUnCom=33.3333333333, a multiplicação por três é 99.9999999999, que arredondada a duas casas resulta em R$ 100,00. O exemplo mostra por que preservar precisão pode ser necessário; não estabelece que todo produto tenha dez casas.

Se o emissor reduzir o unitário a 33.33, a multiplicação será 99.99, diferença de R$ 0,01 em relação a 100.00, dentro da tolerância citada dessa regra. Com 33.32, o resultado será 99.96, diferença de R$ 0,04, fora da tolerância. A finalidade da tolerância é a comparação numérica documentada; não legitima preço incorreto ou ajuste fictício.

Trecho sintético parcial, sem os demais campos obrigatórios:

<prod xmlns="http://www.portalfiscal.inf.br/nfe">
  <uCom>UN</uCom>
  <qCom>3.0000</qCom>
  <vUnCom>33.3333333333</vUnCom>
  <vProd>100.00</vProd>
</prod>

Com qCom=0, não há resultado definido para vProd/qCom. Não use uma divisão por zero ou um valor fabricado como solução: investigue a natureza da operação e a origem da quantidade.

Preço unitário, bruto, desconto e total da nota

vProd é o bruto do item. vDesc é o desconto informado em seu campo próprio. Se duas unidades custam R$ 50,00 cada, o bruto é R$ 100,00. Assumindo um desconto sintético de R$ 10,00 separado, vUnCom=50.00, qCom=2, vProd=100.00 e vDesc=10.00 preservam essa formação.

Usar vUnCom=45.00 e manter vProd=100.00 mistura um preço líquido com um bruto: 45 × 2 = 90, diferença de R$ 10,00. Antes de corrigir, confira se a negociação já definiu preço unitário líquido ou um desconto separado; a origem comercial precisa ser representada coerentemente, sem registrar o mesmo desconto duas vezes. O total da nota reúne outras parcelas e não deve ser dividido pela quantidade de um item para obter seu unitário. MOC, I10a/I11/I17, páginas 18–19.

vUnCom e vUnTrib em unidades diferentes

vUnTrib é o unitário na unidade tributável. Assumindo duas caixas de seis unidades, vendidas a R$ 60,00 por caixa, e unidade tributável individual já definida: comercialmente, 2 × 60 = 120; tributavelmente, 12 × 10 = 120. Nesse cenário, vUnCom=60.00 e vUnTrib=10.00 são coerentes.

Copiar o preço por caixa para o campo tributável sem converter a quantidade produziria 12 × 60 = 720. A regra I11-20/630 verifica o trio tributável; I11-10/629 verifica o comercial. O fator de conversão deve vir do produto/embalagem e da unidade tributável aplicável, não de uma equivalência presumida. A definição fiscal dessa unidade pode requerer confirmação específica, sem mudar a matemática da conversão depois de definida. MOC, páginas 19 e 93.

Como diagnosticar a rejeição 629

Localize o det indicado no retorno e leia uCom, qCom, vUnCom e vProd do XML enviado. Confirme a finalidade, recalcule a multiplicação com os decimais efetivamente transmitidos, arredonde o resultado a duas casas e compare a diferença com a tolerância própria da regra.

Se o pedido está correto mas o XML diverge, examine preço líquido versus bruto, conversão de unidades, arredondamento antecipado, truncamento de decimais e serialização. A tela mostrar “33,33” não prova que o XML tenha perdido as casas adicionais: confira o arquivo transmitido. Para 630, faça a análise do trio tributável; para falha de schema, examine formato antes de atribuir o erro à conta.

Corrija a origem comprovada e confira o novo XML gerado. Não mude quantidade ou preço real apenas para passar uma validação, nem edite XML assinado. Os cálculos deste artigo não escolhem alíquota, classificação ou base de tributos. Para aprofundar a leitura conjunta, consulte qCom e uCom.

Referência técnica para integração

XPath completo
/nfeProc/NFe/infNFe/det/prod/vUnCom
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_1110v · string
Preenchimento no catálogo
Obrigatório

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\.[0-9]{1,10}|[1-9]{1}[0-9]{0,10}|[1-9]{1}[0-9]{0,10}(\.[0-9]{1,10})?
whiteSpace
preserve