Rejeição 866: ausência de troco quando os pagamentos superam o total da nota

A rejeição 866 indica que a soma dos pagamentos informados é maior que o total da nota, mas o XML não contém o valor do troco. A correção depende de conferir o que realmente aconteceu: pode faltar o registro de um troco efetivo, ou algum pagamento pode ter sido duplicado ou digitado incorretamente. Não reduza um recebimento verdadeiro nem invente troco apenas para superar a validação.

Comece pelo XML transmitido e pela resposta completa do autorizador. Registre a chave, o modelo, a UF, o ambiente e a data da tentativa. Se houve apenas falha de comunicação, sem resultado conhecido, consulte a situação da nota antes de tentar outra emissão. Este guia trata do retorno expresso 866.

O que a regra compara

A regra YA03-20 considera duas condições simultâneas: a soma dos campos pag/detPag/vPag supera total/ICMSTot/vNF, e falta a informação de pag/vTroco. O valor total da nota não deve ser confundido com a soma isolada dos produtos, pois sua composição fiscal pode incluir outros componentes.

Some todos os detalhamentos de pagamento presentes no arquivo. Uma venda pode usar mais de um meio, e conferir apenas a primeira linha da tela deixa parte da informação de fora. Também verifique se uma linha foi repetida ao converter o pedido ou combinar registros financeiros.

O campo vTroco pertence ao grupo pag, no mesmo nível dos detalhamentos detPag. Não é um campo de cada produto nem uma parcela da fatura. Sua presença opcional no schema não significa dispensa quando uma regra de negócio exige a informação.

Modelos e aplicação documentada

A NT 2025.001 v1.03 corrigida apresenta a YA03-20 para NF-e, modelo 55, e NFC-e, modelo 65, com aplicação obrigatória. A indicação antiga de aplicação facultativa está riscada. A ressalva de implementação futura para o modelo 55 aparece na regra anterior, YA03-10, da rejeição 865, e não deve ser transferida para a 866.

Há, contudo, uma divergência que precisa ser preservada: a tabela pública de regras da SEFAZ de São Paulo, capturada em 16/10/2026, apresenta YA03-20/866 como “Inativa”. Essa linha não informa, por si só, uma data específica de ativação nem identifica o ambiente da sua tentativa. O registro estadual e a indicação nacional não permitem certificar aqui como cada autorizador está operando.

Se a resposta recebida divergir da documentação consultada, encaminhe o XML e o retorno ao suporte para conferência da versão e do ambiente. Não use a divergência como autorização para transmitir pagamentos ou troco incorretos. Também não conclua que a situação encontrada em São Paulo vale para todas as UFs.

Quando existe troco e quando existe erro de pagamento

Imagine uma nota de R$ 147,50, com R$ 100,00 em um meio de pagamento e R$ 50,00 em dinheiro. Se esses valores foram efetivamente recebidos e R$ 2,50 foram devolvidos ao cliente, a soma é R$ 150,00 e o troco corresponde à diferença de R$ 2,50. A ausência dessa informação caracteriza o problema examinado pela 866.

Em outro cenário, a segunda linha deveria conter R$ 47,50, mas foi digitada como R$ 50,00. Nesse caso, não houve recebimento excedente nem devolução ao cliente. A correção é ajustar o pagamento errado na origem, mantendo a operação verdadeira. Preencher R$ 2,50 como troco inventado apenas esconderia a divergência.

Não altere preços, descontos, frete ou total fiscal só para encaixar os pagamentos. Confira esses componentes quando houver indício de erro real e corrija o documento de origem que estiver incorreto. A nota e os registros financeiros precisam contar a mesma operação.

Não confunda ausência com valor incorreto

A rejeição 866 verifica a falta de troco no cenário descrito. A rejeição 869 trata de outro problema: o valor informado não corresponde à diferença entre os pagamentos e o total da nota. Portanto, colocar zero ou um valor qualquer no campo não é solução quando existe diferença positiva.

A rejeição 865, por sua vez, examina pagamentos inferiores ao total e possui suas próprias exceções. Não transfira para a 866 as exceções de finalidade ou meio de pagamento da regra anterior. Alterar o meio para “Sem pagamento”, mudar a finalidade ou excluir um recebimento verdadeiro não substitui o diagnóstico.

Também não trate a soma das duplicatas de cobrança como se fosse a soma dos pagamentos. O XML distingue parcelas da fatura e detalhamentos de pagamento; uma tela financeira pode agrupar essas informações, mas o campo transmitido precisa ser conferido individualmente.

Como corrigir com segurança

1. Abra o XML rejeitado e localize vNF, todos os vPag e a eventual presença de vTroco.

2. Some os pagamentos com precisão decimal e compare o resultado com o total fiscal.

3. Confronte a diferença com os registros da venda: recebimentos efetivos, duplicidades, erros de digitação e troco devolvido.

4. Corrija a origem no emissor ou na integração. Quando o troco existir, confirme seu mapeamento para o grupo correto do XML.

5. Gere novamente o documento e confira os valores antes de retransmitir. Evite editar diretamente um XML já assinado.

6. Examine a resposta individual da nota. Corrigir a ausência de troco não garante que todas as demais validações serão atendidas.

Se o sistema não disponibilizar um campo necessário, peça ao suporte a orientação para representar a operação corretamente. A limitação descrita no manual de outro produto não demonstra que o ALRA tenha a mesma tela ou comportamento.

Informações úteis para o suporte

Envie o XML rejeitado, o retorno completo, a memória da soma, o valor real do troco e os dados do ambiente. Se a tela mostra o troco, mas o XML não, destaque essa diferença para investigar a geração do arquivo.

As mudanças preparatórias de vinculação de pagamentos da NT 2026.006 não substituem o grupo YA nem oferecem um atalho para essa correção. A própria nota técnica afasta o preenchimento obrigatório de seus campos de split payment em produção em 2026. A revisão deve permanecer ligada aos pagamentos, ao troco e à 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 com a atualização; schema do grupo pag; tabela pública de regras de São Paulo; e NT 2026.006, páginas 2–4 e 7. Capturas oficiais compartilhadas, análise vetorial e limites de leitura estão discriminados no manifesto. Não houve teste individual de autorização.

Foram lidos três corpos específicos, em novas capturas: Treeunfe, NFeLink e InvoiSys. Foram filtrados o código 865 indevido no exemplo da InvoiSys, a classificação facultativa antiga e as soluções dependentes de telas externas. Ajustar valores só é adequado quando corrige informação efetivamente errada.