NF-e e NFC-e
Rejeição 629: corrija a multiplicação comercial de cada item
A rejeição 629 aponta uma diferença entre o valor bruto do item e o resultado da quantidade comercial multiplicada pelo valor unitário comercial. O caminho mais rápido é localizar o nItem indicado na resposta e conferir três campos do XML enviado: qCom, vUnCom e vProd. Alterar somente o total da nota não corrige uma…
A rejeição 629 aponta uma diferença entre o valor bruto do item e o resultado da quantidade comercial multiplicada pelo valor unitário comercial. O caminho mais rápido é localizar o nItem indicado na resposta e conferir três campos do XML enviado: qCom, vUnCom e vProd. Alterar somente o total da nota não corrige uma divergência que está dentro do produto.
A regra I11-10 do MOC abrange NF-e modelo 55 e NFC-e modelo 65 com finalidade normal, finNFe=1. Sua aplicação é facultativa por UF. As páginas oficiais de São Paulo, consultadas em 10/10/2026, a apresentam como ativa nos dois modelos; Minas Gerais também informa aplicação na lista versão 2.00. Isso confirma exemplos de adoção, sem certificar o comportamento de todos os autorizadores. Regra nacional e campos relacionados.
A conta que precisa fechar
Para cada item, o sistema deve confrontar:
qCom × vUnCom, arredondado a duas casas decimais, com vProd.
Aqui, vProd é o campo de det/prod, não o vProd do grupo de totais. Também não é vNF, que representa o total da nota e considera sua composição fiscal. Um documento pode ter a soma final aparentemente correta e ainda conter um item cuja quantidade ou preço exportado está errado.
A nota (*4) do MOC manda arredondar o resultado da multiplicação a duas casas e considerar tolerância de R$ 0,01 para mais ou para menos na validação. Essa tolerância pertence a essa comparação. Ela não é um desconto, uma verba para distribuir entre produtos ou uma permissão para escolher qualquer total conveniente.
Por exemplo, 8 unidades a R$ 17,35 resultam em R$ 138,80. Se o XML trouxer vProd=138.82, a diferença de R$ 0,02 excede a tolerância descrita. O procedimento correto é descobrir qual campo divergiu da venda real, e não trocar um número aleatoriamente até a nota passar.
Por que a calculadora pode concordar e o XML não
A tela comercial pode mostrar um preço com duas casas enquanto a integração usa mais casas internamente, ou pode fazer o inverso: calcular com alta precisão e depois cortar o preço unitário ao exportar o arquivo.
O leiaute admite até quatro casas decimais para qCom e até dez para vUnCom; vProd tem duas casas. Portanto, não imponha duas casas ao preço unitário só porque o valor final do item é expresso em centavos. A validação deve usar os números realmente transmitidos, com cálculo decimal adequado, sem perdas de precisão no meio do caminho.
Considere um exemplo fictício com qCom=125.0000 e vUnCom=0.3333333333. A multiplicação resulta em 41.6666666625 e seu arredondamento em 41.67. Se o emissor mantiver vProd=41.67, mas exportar vUnCom=0.33, a conta do XML passa a ser 41.25. A diferença de R$ 0,42 não é um problema resolvido pela tolerância de um centavo.
Nesse caso, se o preço com mais casas representa corretamente o acordo comercial, o ajuste é preservar sua precisão na integração. Se houve erro no preço ou na quantidade de origem, corrija o dado real. Não fabrique um preço derivado apenas para ocultar um cadastro incorreto.
Desconto e unidade de venda merecem uma conferência separada
O vProd é bruto. Em um exemplo simples de 100 unidades a R$ 2,50, com desconto de R$ 25,00, os campos do item podem representar vProd=250.00 e vDesc=25.00. Informar vProd=225.00, mantendo qCom=100 e vUnCom=2.50, mistura valor líquido com bruto e quebra a multiplicação. Confira também se o desconto já estava embutido no preço para evitar descontá-lo novamente.
Verifique a unidade comercial. Se a venda foi de quatro caixas, mas qCom passou a representar as unidades dentro delas, o preço unitário precisa corresponder à unidade usada naquele grupo. Não misture quantidade em peças com preço por caixa.
O grupo tributável é uma conferência adicional: qTrib e vUnTrib podem ser diferentes dos campos comerciais quando existe conversão legítima. Eles precisam representar o mesmo valor bruto do item e são objeto da rejeição 630. Corrigir a 629 não garante que a conversão tributável também esteja certa.
Sequência prática para corrigir
Guarde o XML transmitido e a resposta completa, incluindo nItem, ambiente e horário
Localize o item pelo número no XML, evitando confundi-lo com a posição atual na tela ou com o código do produto
Confira qCom, vUnCom e vProd contra pedido, unidade de venda e condições comerciais
Multiplique com precisão decimal, arredonde o resultado do item e compare a diferença com a tolerância da regra
Corrija a origem do erro e regenere o XML; depois confira os campos tributáveis e os totalizadores afetados
Reenvie o documento corrigido e leia a resposta individual de autorização
Alguns sistemas mantêm campos comerciais em abas diferentes ou recalculam o produto quando ele é salvo novamente. Essa rotina pode ajudar, mas precisa ser conferida no novo XML. Se o ERP já lançou estoque ou financeiro, siga seu procedimento de correção para evitar duplicidade; não estorne movimentações sem verificar seu vínculo com a operação.
Finalidade, regime e novas versões
I11-10 está condicionada a finNFe=1. Não mude uma venda normal para complemento, ajuste ou devolução apenas para escapar dessa condição. Essas finalidades têm requisitos próprios. Também não presuma dispensa por ser Simples Nacional ou MEI: a regra consultada não estabelece uma exceção automática por CRT. As exceções específicas da Nota Fiscal Fácil em outras validações não podem ser transportadas para esta multiplicação.
Os novos campos de valor líquido previstos na NT 2026.008 têm tratamento separado. Na data desta consulta, o aviso oficial adiou a implantação dessa versão para 26/10/2026 em homologação e 16/11/2026 em produção, respeitadas as ressalvas particulares das regras. vProdLiq não deve ser colocado no lugar de vProd para corrigir a 629. Aviso oficial de implantação.
A solução fica comprovada quando o XML regenerado representa a operação, a multiplicação é consistente e a autorização individual é obtida. Se a 629 persistir, encaminhe ao suporte os três valores exatos, a memória de cálculo e a versão do emissor. Um comprovante de lote recebido, sozinho, não encerra a emissão.
Fontes consultadas
Consulta documental: 10/10/2026.