Rejeição 865 — Total dos pagamentos menor que o total da nota

Resumo Rápido

A Rejeição 865 ocorre quando o somatório dos valores de pagamento informados na NF-e ou NFC-e é menor que o valor total do documento fiscal.

Durante a validação, a SEFAZ compara o valor total da nota, informado em <vNF>, com a soma dos valores de pagamento informados nos grupos <detPag>, campo <vPag>.

Quando a soma dos pagamentos é inferior ao total da nota, o documento é rejeitado.

Solução rápida

Verifique o valor total da nota em <vNF>.
Some todos os valores informados em <vPag>.
Confirme se a soma dos pagamentos é igual ou superior ao total da nota.
Revise descontos, parcelas, meios de pagamento e arredondamentos.
Caso não haja pagamento, avalie se o meio de pagamento deve ser informado como 90 - Sem pagamento.
Gere novamente o XML e retransmita a NF-e ou NFC-e.

Diagnóstico Rápido

O valor total da nota em `<vNF>` está correto?
A soma dos campos `<vPag>` é menor que `<vNF>`?
Existe mais de uma forma de pagamento?
Houve desconto financeiro, desconto em duplicata ou abatimento?
O ERP confundiu dados de cobrança com dados de pagamento?
Existem arredondamentos ou diferença de centavos?
A nota é de ajuste ou devolução?
O meio de pagamento deveria ser `90 - Sem pagamento`?

Mensagem da Rejeição

865 - Total dos pagamentos menor que o total da nota

O que significa essa rejeição?

Essa rejeição significa que o XML da NF-e ou NFC-e informa um valor total de documento maior do que o valor total declarado no grupo de pagamentos.

Na prática, a SEFAZ encontra uma inconsistência matemática entre:

<total>
   <ICMSTot>
      <vNF>...</vNF>
   </ICMSTot>
</total>

<pag>
   <detPag>
      <vPag>...</vPag>
   </detPag>
</pag>

O valor da nota precisa estar compatível com os pagamentos informados.

Se a nota tem total de R$ 1.000,00, mas o grupo de pagamento informa apenas R$ 900,00, a SEFAZ entende que há diferença não justificada e rejeita o documento.

Sintomas Comuns

NF-e ou NFC-e rejeitada no momento da autorização.
Diferença entre valor total da nota e valor pago.
Rejeição após alteração de parcelas no financeiro.
Problema em vendas com múltiplas formas de pagamento.
Erro após desconto financeiro aplicado fora do cálculo fiscal.
Divergência entre duplicatas e grupo de pagamento.
Falha em integrações de pedidos, caixa ou e-commerce.
Rejeição em NFC-e no fechamento da venda.

Por que essa rejeição acontece?

Pagamento menor que o total da nota

A causa direta é a soma dos campos <vPag> ser menor que o campo <vNF>.

Desconto financeiro tratado incorretamente

O ERP pode reduzir o valor cobrado do cliente, mas manter o valor total da NF-e sem refletir corretamente a operação no grupo de pagamento.

Confusão entre cobrança e pagamento

O grupo <cobr> e as duplicatas indicam cobrança ou vencimentos.

O grupo <pag> indica o pagamento da operação.

Um não substitui o outro.

Integração com caixa ou e-commerce

Sistemas externos podem enviar o valor pago menor que o valor total do pedido ou da nota.

Múltiplas formas de pagamento

Quando há dinheiro, cartão, Pix, boleto ou crédito em loja, algum meio de pagamento pode não ser enviado ao XML.

Arredondamento

Diferenças de centavos podem ocorrer por cálculo de parcelas, rateios ou conversões de casas decimais.

Meio de pagamento incorreto

Algumas operações sem pagamento financeiro podem exigir o meio de pagamento 90 - Sem pagamento, em vez de informar um valor menor ou zerado indevidamente.

Causa Raiz

A Rejeição 865 normalmente não está no cálculo de impostos, mas na consistência financeira do XML.

As causas mais frequentes incluem:

Soma incorreta dos pagamentos.
Valor de <vPag> menor que <vNF>.
Duplicatas geradas corretamente, mas pagamento informado incorretamente.
Desconto financeiro aplicado fora da composição da nota.
Integração de caixa enviando valor parcial.
Parametrização incorreta do meio de pagamento.
Arredondamento entre parcelas.
Atualização incompleta do XML após alteração do pedido.

Como Resolver

Passo 1

Localize o valor total da nota no XML.

<ICMSTot>
   <vNF>...</vNF>
</ICMSTot>

Passo 2

Localize todos os grupos de pagamento.

<pag>
   <detPag>
      <tPag>...</tPag>
      <vPag>...</vPag>
   </detPag>
</pag>

Passo 3

Some todos os valores informados em <vPag>.

Se houver mais de um <detPag>, todos devem ser considerados.

Passo 4

Compare o resultado com <vNF>.

A soma dos pagamentos não pode ser menor que o total da nota.

Passo 5

Revise a origem da divergência.

Verifique:

Parcelas.
Duplicatas.
Descontos.
Troco.
Meios de pagamento.
Integração com caixa.
Integração com e-commerce.
Regras financeiras do ERP.

Passo 6

Corrija o grupo de pagamento.

Ajuste o valor dos pagamentos para refletir corretamente a operação.

Passo 7

Gere novamente o XML.

Após a correção, transmita novamente a NF-e ou NFC-e.

Exemplo Prático

Uma NF-e possui valor total de R$ 1.000,00.

Valor total da nota = 1.000,00

Entretanto, o grupo de pagamento informa apenas:

Pagamento = 950,00

Somatório dos pagamentos:

950,00

Resultado:

Rejeição 865

A SEFAZ rejeita o documento porque o total pago informado é menor que o total da nota.

Exemplo XML

XML com erro

<total>
   <ICMSTot>
      <vNF>1000.00</vNF>
   </ICMSTot>
</total>
 
<pag>
   <detPag>
      <tPag>01</tPag>
      <vPag>950.00</vPag>
   </detPag>
</pag>

XML corrigido

<total>
   <ICMSTot>
      <vNF>1000.00</vNF>
   </ICMSTot>
</total>
 
<pag>
   <detPag>
      <tPag>01</tPag>
      <vPag>1000.00</vPag>
   </detPag>
</pag>

O que mudou?

O valor informado no pagamento passou a corresponder ao valor total da nota.

Exemplo com múltiplas formas de pagamento

XML com erro

<total>
   <ICMSTot>
      <vNF>500.00</vNF>
   </ICMSTot>
</total>
 
<pag>
   <detPag>
      <tPag>01</tPag>
      <vPag>200.00</vPag>
   </detPag>
   <detPag>
      <tPag>03</tPag>
      <vPag>250.00</vPag>
   </detPag>
</pag>

Somatório dos pagamentos:

200,00 + 250,00 = 450,00

Valor total da nota:

500,00

Resultado:

Rejeição 865

XML corrigido

<total>
   <ICMSTot>
      <vNF>500.00</vNF>
   </ICMSTot>
</total>
 
<pag>
   <detPag>
      <tPag>01</tPag>
      <vPag>200.00</vPag>
   </detPag>
   <detPag>
      <tPag>03</tPag>
      <vPag>300.00</vPag>
   </detPag>
</pag>

Observações Importantes

Pagamento maior que a nota

Quando o valor pago é maior que o valor total da nota, pode ser necessário informar o troco em <vTroco>.

Esse cenário está mais relacionado a outras validações, como ausência ou cálculo incorreto do troco.

Operações sem pagamento

Quando a operação realmente não possui pagamento, pode ser necessário utilizar:

<tPag>90</tPag>

Esse código representa Sem pagamento.

Nota de ajuste e devolução

A regra da Rejeição 865 possui exceções para algumas finalidades, como nota de ajuste e nota de devolução.

Mesmo assim, o ERP deve tratar essas situações com cuidado, pois a aplicação prática pode depender da regra vigente e da validação da UF autorizadora.

Tolerância de centavos

Algumas validações admitem tolerância de centavos em situações específicas de arredondamento.

Apesar disso, não é recomendável depender dessa tolerância como solução sistêmica.

O ideal é gerar o XML com os totais consistentes.

Como Identificar o Problema no ERP

Onde verificar

Pedido de venda.
Tela de faturamento.
Condição de pagamento.
Parcelas financeiras.
Grupo de pagamentos da NF-e.
XML autorizado ou rejeitado.
Integração com caixa.
Integração com e-commerce.
Parametrização de meios de pagamento.
Rotinas de desconto financeiro.

O que procurar

Soma de pagamentos menor que o total da nota.
Valor de duplicata diferente do valor de pagamento.
Desconto financeiro aplicado apenas no financeiro.
Parcela não enviada ao XML.
Meio de pagamento faltando.
Valor pago zerado indevidamente.
Diferença de centavos.
Alteração manual no XML.
Integração enviando pagamento parcial.

Impactos para a Empresa

Faturamento

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

Financeiro

As parcelas, cobranças e registros de pagamento podem ficar inconsistentes.

Caixa

Em NFC-e, a rejeição pode impedir a conclusão da venda no ponto de venda.

Estoque

A expedição ou baixa do estoque pode ser atrasada.

Atendimento

O cliente pode ficar aguardando a emissão do documento fiscal.

Integrações

Pedidos de e-commerce, TEF, cartão, Pix ou boletos podem exigir revisão.

O que NÃO Fazer

Não alterar manualmente apenas o XML sem corrigir a origem no ERP.
Não confundir duplicata com pagamento.
Não informar pagamento menor para representar desconto financeiro.
Não zerar <vPag> sem avaliar se a operação é realmente sem pagamento.
Não usar tPag = 90 apenas para contornar a rejeição.
Não ignorar diferenças de centavos recorrentes.
Não assumir que o erro é da SEFAZ.
Não corrigir somente a tela fiscal deixando o financeiro divergente.

Caso Real

Uma empresa emitia NF-e com boleto bancário.

O valor total da nota era de R$ 8.165,00, mas, devido a um desconto financeiro aplicado na duplicata, o ERP enviava o grupo de pagamento com R$ 8.160,00.

As duplicatas estavam corretas do ponto de vista da cobrança, mas o grupo <pag> ficou menor que o total fiscal da NF-e.

A SEFAZ rejeitou o documento com a Rejeição 865.

A correção foi ajustar a rotina de geração do XML para que o grupo de pagamento representasse corretamente o valor total da operação, sem confundir desconto financeiro com valor fiscal da nota.

Como Evitar Essa Rejeição

Validar a soma dos pagamentos antes de transmitir a NF-e.
Garantir que <vPag> seja compatível com <vNF>.
Revisar integrações com caixa, TEF, e-commerce e gateways de pagamento.
Separar corretamente dados de cobrança e dados de pagamento.
Testar vendas com múltiplas formas de pagamento.
Testar operações com desconto financeiro.
Tratar corretamente operações sem pagamento.
Auditar arredondamentos em parcelas.
Monitorar rejeições após atualizações do ERP.
Evitar alterações manuais no XML.

Fluxograma de Diagnóstico

Recebeu Rejeição 865?
 
├─ Some todos os vPag do grupo pag
│
├─ Soma dos pagamentos < vNF?
│   │
│   ├─ Sim → Corrigir grupo de pagamento
│   │
│   └─ Não
│       │
│       ├─ Existe troco?
│       │   │
│       │   ├─ Sim → Validar vTroco
│       │   └─ Não → Revisar arredondamento e meios de pagamento
│
└─ A operação é sem pagamento?
    │
    ├─ Sim → Avaliar tPag = 90
    │
    └─ Não → Revisar financeiro, caixa ou integração

FAQ

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

Pode, especialmente se a UF autorizadora não aceitar a divergência ou se o arredondamento não estiver conforme a regra esperada.

A Rejeição 865 vale para NF-e e NFC-e?

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

O campo de duplicata substitui o campo de pagamento?

Não. O grupo de cobrança e o grupo de pagamento possuem finalidades diferentes.

Posso corrigir somente o valor de `<vPag>`?

Pode ser suficiente no XML, mas o correto é corrigir a origem no ERP para manter faturamento, financeiro e XML consistentes.

Quando usar `tPag = 90`?

Quando a operação realmente não tiver pagamento financeiro, conforme a natureza da operação e a regra fiscal aplicável.

Se o pagamento for maior que a nota, também gera a Rejeição 865?

Não necessariamente. A 865 trata pagamento menor que o total da nota. Pagamento maior pode exigir informação de troco e envolver outras rejeições.

Desconto financeiro pode causar essa rejeição?

Sim. Principalmente quando o desconto reduz o valor cobrado, mas o XML mantém o valor total fiscal da NF-e.

Essa rejeição é fiscal ou financeira?

Ela é uma validação técnica da NF-e/NFC-e, mas normalmente nasce de uma inconsistência financeira ou operacional no ERP.

Como corrigir em vendas com cartão e dinheiro?

Informe cada meio de pagamento em seu respectivo <detPag>, garantindo que a soma dos <vPag> seja compatível com <vNF>.

A rejeição impede a emissão?

Sim. Enquanto a inconsistência permanecer, a NF-e ou NFC-e não será autorizada.

Base Legal

Projeto NF-e
Manual de Orientação do Contribuinte (MOC)
Nota Técnica 2016.002
Regras de Validação da NF-e/NFC-e
Legislação tributária aplicável aos documentos fiscais eletrônicos

A Rejeição 865 ocorre quando o somatório dos valores de pagamento informados no XML é menor que o valor total da NF-e ou NFC-e. O problema normalmente está relacionado a divergências entre <vNF> e <vPag>, descontos financeiros, múltiplas formas de pagamento, integrações de caixa ou confusão entre cobrança e pagamento. A solução consiste em revisar o grupo <pag>, corrigir os valores de pagamento, tratar corretamente operações sem pagamento e gerar novamente o XML.

Rejeição 865 — Total dos pagamentos menor que o total da nota

Conteúdo relacionado