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

A rejeição 865 ocorre na comparação entre o total da nota e a soma dos valores informados no grupo de pagamentos. Quando a regra se aplica e essa soma é inferior ao total fiscal, o autorizador aponta a diferença. A solução é descobrir qual informação ficou incompleta ou incorreta, preservando o que realmente foi negociado. Aumentar um pagamento fictício apenas para fechar a conta não é uma correção válida.

Comece pelo XML efetivamente transmitido e pelo retorno completo da SEFAZ. Anote modelo, UF, ambiente e finalidade. Confira se o problema foi uma rejeição expressa ou uma interrupção na comunicação: quando o resultado estiver incerto, consulte a situação da chave antes de realizar outra emissão.

Qual regra está sendo aplicada

A YA03-10 compara a soma de pag/detPag/vPag com total/ICMSTot/vNF. Portanto, devem entrar na conferência todos os detalhamentos de pagamento da nota, e não somente a primeira linha apresentada na tela.

A NT 2025.001 v1.03 corrigida apresenta os modelos 55 e 65 e torna obrigatória a regra, mas mantém uma observação expressa: implementação futura para o modelo 55. Não é correto afirmar, com base somente nessa tabela, que toda NF-e já está sujeita à 865. Para NFC-e, modelo 65, a regra aparece sem essa ressalva de implementação futura.

Se uma NF-e modelo 55 receber esse código, preserve a evidência e peça ao suporte a confirmação da regra e versão adotadas pelo autorizador. A indicação documental de implementação futura não é motivo para ignorar a resposta real nem para manipular valores. O diagnóstico deve considerar a data da tentativa e o ambiente em que ela ocorreu.

Exceções que precisam representar a operação real

A mesma regra exclui notas de ajuste, finNFe=3, e devolução, finNFe=4. Também prevê exceção quando o meio de pagamento é 90 — Sem pagamento ou 91 — Pagamento posterior. Essas condições não permitem transformar uma venda comum em ajuste, devolução ou operação sem pagamento para obter autorização.

O código 91 foi incluído na exceção pela versão 1.03. O cronograma dessa alteração estabeleceu homologação até 20/10/2025 e produção em 03/11/2025. A tabela nacional consultada descreve seu uso para pagamento integral ou parcial em momento posterior à emissão ou ao fato gerador. Assim, um valor ainda não recebido precisa ser tratado conforme a operação, a tabela vigente e a configuração fiscal apropriada, sem ser declarado como dinheiro já recebido.

Há uma validação próxima que não deve ser esquecida: a YA03-30, rejeição 904, exige valor de pagamento igual a zero quando tPag é 90 ou 91. Não coloque o saldo futuro como valor positivo na linha do código 91. Também não confunda tPag, que identifica o meio de pagamento, com indPag, indicador de pagamento à vista ou a prazo.

Pagamento, parcela e total fiscal são informações diferentes

Uma tela financeira pode exibir parcelas, recebimentos e formas de pagamento no mesmo processo, mas o XML separa essas informações. A 865 compara vPag com vNF. A soma de parcelas de cobrança, dup/vDup, possui outra validação, associada ao valor líquido da fatura. Conferir apenas as duplicatas não demonstra que o grupo de pagamentos foi gerado corretamente.

Examine também como o total fiscal foi composto. Um desconto concedido e corretamente documentado pode ter sido informado no pedido, mas não levado à nota. Frete, despesas ou itens podem ter sido acrescentados depois de gerar os pagamentos. São hipóteses a verificar no caso concreto, sem presumir uma causa antes de comparar os arquivos e os documentos da venda.

Não reduza o total da nota para fazê-lo coincidir com o pagamento se esse total representar corretamente a operação. Da mesma forma, não apague parcelas reais nem gere novas cobranças só porque um tutorial de outro sistema utiliza esse procedimento para recalcular a tela.

Exemplo de conferência

Considere uma NFC-e de R$ 500,00, em uma operação sem as exceções mencionadas. Foram registrados R$ 200,00 em dinheiro e R$ 300,00 por outro meio efetivamente utilizado. Se apenas a primeira linha entrou no XML, a soma transmitida será R$ 200,00, deixando uma diferença de R$ 300,00.

Nesse cenário, investigue por que o segundo pagamento não foi enviado e corrija o mapeamento ou o registro de origem. Se o cliente, na realidade, pagou somente R$ 200,00 e combinou o restante para depois, o caso é diferente: não invente um segundo recebimento. Verifique o enquadramento de pagamento posterior e as exigências aplicáveis com a contabilidade.

A 865 usa a comparação “menor que”. Uma soma superior ao total não caracteriza, por si só, essa rejeição, mas pode exigir informação de troco e outras conferências. Por isso, “deixar qualquer valor igual ou maior” também não é uma orientação suficiente para corrigir o documento.

Passos para corrigir e conferir o resultado

1. Identifique o XML rejeitado e some todos os campos vPag existentes em detPag.

2. Compare essa soma com vNF, observando a finalidade, os meios de pagamento e as exceções reais da operação.

3. Confronte os dados com o pedido, os registros de recebimento e a condição negociada. Localize omissões, duplicidades ou valores desatualizados.

4. Corrija a origem da informação no emissor ou na integração. Preserve o vínculo com os pagamentos reais e evite editar diretamente um XML assinado.

5. Gere novamente a nota e confira o novo grupo de pagamentos, o total fiscal e eventual troco antes do envio.

6. Retransmita a nota efetivamente rejeitada e examine a resposta individual. A correção da 865 não garante que todas as outras validações serão atendidas.

Quando pedir apoio

Encaminhe ao suporte o retorno, o XML, a memória da soma, o modelo, a UF, o ambiente e a versão do emissor. Destaque operações com pagamento posterior ou respostas recebidas no modelo 55, cuja ressalva documental exige atenção.

As mudanças preparatórias de vinculação de pagamentos da NT 2026.006 não substituem o grupo YA. A nota esclarece que seus campos de split payment não têm preenchimento obrigatório em produção em 2026. Não use esses campos como atalho para corrigir a 865; a conferência continua dependendo dos dados e da regra efetivamente envolvidos.

Fontes

Pesquisa de 16/10/2026: NT 2025.001 v1.03 corrigida, páginas 3, 7 e 10–11; MOC 7.0, páginas 125–126, cotejado como base anterior; tabela nacional de meios de pagamento, linha 91; e NT 2026.006, páginas 3–4 e 7. Capturas oficiais reutilizadas por hash, leitura pessoal do conteúdo e análise vetorial estão discriminadas no manifesto. Não houve teste individual de autorização.

Três guias específicos foram lidos em novas capturas: InvoiSys, IOB e vhsys. Omissões do código 91, generalização ao modelo 55, igualdade obrigatória em qualquer cenário e menus externos foram filtrados pelas fontes primárias.