Pular para o conteúdo
FiscalAPI
965 Pagamento

Rejeição 965 — Valor do troco acima do permitido

Motivo da rejeição

Valor do troco acima do permitido

3 min de leitura

O que é esta rejeição?#

A Rejeição 965 é retornada pela SEFAZ durante a validação da NF-e quando há uma inconsistência relacionada a informação do documento fiscal, valor total da nota fiscal. Isso significa que a nota fiscal não foi autorizada e precisa ser corrigida antes de ser retransmitida.

Os campos afetados estão na seção de tributação (ICMS) do XML.

Campos XML relacionados#

Esta rejeição está associada aos seguintes campos do XML da NF-e. Verifique cada um deles ao diagnosticar o problema:

CampoXPath no XMLDescrição
tPagNFe/infNFe/pag/detPag/tPagTipo/forma de pagamento
vPagNFe/infNFe/pag/detPag/vPagValor do pagamento
vNFNFe/infNFe/total/ICMSTot/vNFValor total da NF-e

Causas comuns#

  • O valor do troco informado está incorreto ou acima do limite permitido
  • O troco não corresponde à diferença entre o valor pago e o valor da NF-e

Como resolver#

  1. O troco (vTroco) deve ser igual à soma dos pagamentos (vPag) menos o valor da NF-e (vNF)
  2. Verifique se o valor do troco não excede o limite permitido pela SEFAZ do estado
  3. Revise os valores de cada forma de pagamento informada

💡
Dica: Para identificar a causa desta rejeição, comece verificando os campos tPag, vPag, vNF no XML da NF-e. Compare os valores informados com os dados cadastrais atualizados na SEFAZ e na Receita Federal.

Verificações analíticas#

  • Se a soma de todos os valores vPag informados nos elementos detPag for menor ou igual ao valor vNF em ICMSTot, então o campo vTroco foi preenchido com valor positivo indevido, pois não há excedente de pagamento que justifique troco: remova o campo vTroco ou corrija os valores de vPag para que a soma supere vNF.
  • Se existir mais de um elemento detPag e a soma de seus respectivos vPag menos vNF resultar em valor diferente do informado em vTroco com tolerância de R$ 0,01, então há inconsistência aritmética entre os campos de pagamento e o troco declarado: recalcule vTroco como exatamente (ΣvPag − vNF) e atualize o XML antes de retransmitir.
  • Se o campo tPag de algum detPag contiver código correspondente a pagamento eletrônico não presencial (ex.: tPag=17 Pix, tPag=15 boleto, tPag=16 depósito) e simultaneamente vTroco for maior que zero, então o troco não é operacionalmente admissível para essa modalidade de pagamento, pois meios eletrônicos não geram troco físico: zere vTroco e ajuste vPag para igualar exatamente vNF ou redistribua os valores entre as formas de pagamento.
  • Se o campo indPag estiver preenchido com valor '1' (pagamento a prazo) em qualquer detPag e o campo vTroco for maior que zero, então há contradição semântica, pois pagamentos a prazo não geram saldo imediato passível de troco: corrija indPag para '0' (à vista) nos registros que efetivamente correspondem ao pagamento imediato ou elimine o vTroco caso a operação seja integralmente parcelada.
  • Se o valor de vNF em ICMSTot não coincidir com a soma de vProd mais vFrete mais vSeg mais vOutro mais vII mais vIPI mais vIPIDevol mais vPIS mais vCOFINS menos vDesc menos vICMSDeson, então o próprio vNF está incorreto e qualquer vTroco calculado sobre ele também estará errado: recalcule vNF a partir dos totalizadores dos itens e só então apure vTroco como ΣvPag − vNF recalculado.
Compartilhar: WhatsApp LinkedIn Twitter

Consulte IEs e CNPJs antes de emitir NF-e

Muitas rejeições acontecem por dados cadastrais desatualizados. Com a FiscalAPI, consulte Inscrições Estaduais e CNPJs em tempo real direto da SEFAZ e Receita Federal.

Criar conta →