Rejeição 869: confira os pagamentos e o troco enviados na nota

Se o emissor apresentar “Rejeição: Valor do troco incorreto”, compare o total da nota, os pagamentos e o troco no XML enviado. A divergência pode estar em um valor de troco digitado, em um pagamento duplicado ou em um total alterado depois da preparação da venda. Antes de corrigir apenas o número que aparece na tela, descubra qual informação deixou de representar a operação.

Este diagnóstico trata da YA09-10, código 869, documentada no MOC 7.0 para autorização de NF-e, modelo 55, e NFC-e, modelo 65. Na página 126, o predicado considera o campo vTroco quando informado e compara seu valor com a relação entre vPag e vNF. A rejeição não comprova, por si só, erro na taxa da operadora ou no saldo bancário.

Confira a regra e a versão da emissão

A conferência documental de 15/10/2026 utiliza o MOC novamente obtido, a NT 2016.002 v1.61 e declarações do pacote de schemas 010f. Na YA09-10, o troco informado deve corresponder ao pagamento menos o total da nota. A linha é obrigatória para os modelos 55/65, sem tolerância monetária ou exceção estadual própria expressa.

A comparação é documental; não houve emissão de teste nem comprovação da execução em todos os autorizadores. Identifique UF, ambiente e versão do emissor no caso concreto. Não aplique margens de arredondamento de outra validação nem troque os campos de total apenas porque uma especificação posterior acrescentou novas informações.

Identifique os três valores no XML

O MOC localiza vNF, campo W16, na página 59; os detalhes de pagamento detPag e o valor vPag, na página 62; e o troco vTroco, campo YA09, na página 63. No arquivo, procure total/ICMSTot/vNF, cada pag/detPag/vPag e pag/vTroco. A mensagem da rejeição consta também no catálogo da página 152.

Quando houver mais de um pagamento, reúna os valores dos detalhes da mesma nota. A orientação de conferir sua soma decorre do detalhamento múltiplo do leiaute e das regras de pagamento que o acompanham. Para o diagnóstico, compare essa soma menos vNF com o troco informado. Não use o depósito líquido do cartão ou uma dedução de taxa como substituto desses campos.

O troco pertence ao grupo de pagamento da nota. Não o repita como uma dedução independente de cada modalidade. Se os valores não fecharem, essa conta indica onde investigar; ela não autoriza aumentar o troco para compensar um pagamento inexistente. Primeiro, todos os dados precisam corresponder aos comprovantes e ao acordo comercial.

Diferencie troco incorreto de troco ausente

No mesmo MOC, a YA03-20, código 866, trata do somatório dos pagamentos maior que o total da nota sem informação em vTroco. A NT 2025.001 v1.03, página 10, apresenta essa regra para os dois modelos, com aplicação obrigatória para os dois modelos. Já a 869 verifica a divergência de um valor de troco informado. Essa diferença evita aplicar à falta do campo uma solução pensada para um valor errado.

Se os pagamentos forem menores que o total, não crie troco negativo. Verifique se falta uma modalidade ou se algum valor foi lançado incorretamente. Uma operação com preenchimento fiscal próprio precisa ser analisada com o responsável fiscal. Também não apague um troco efetivamente devolvido nem selecione “sem pagamento” para representar uma venda recebida.

Procure a origem da diferença

Guarde o XML rejeitado, a resposta completa e os comprovantes antes de recalcular. Registre chave, número, série, horário, UF, autorizador e ambiente. Confira o arquivo efetivamente enviado, pois uma versão gerada depois da rejeição pode conter dados diferentes. A resposta precisa estar vinculada ao documento que está sendo examinado.

Investigue alterações feitas após a seleção dos pagamentos. Um desconto pode ter reduzido o total sem atualizar o troco. Uma integração pode ter repetido o cartão, ou o campo pode ter preservado o valor de uma venda anterior. Também confira separadores decimais e precisão dos valores, especialmente quando houve importação ou digitação manual.

Se o XML divergir da tela, procure a rotina que gera os campos. Selecionar novamente a mesma forma de pagamento não garante que uma conversão errada será corrigida. O suporte deve identificar o cadastro, cálculo ou integração responsável. Preserve os registros financeiros: corrigir a emissão não significa apagar parcelas, mudar o recebimento real ou fechar a venda artificialmente.

Exemplo com dinheiro e cartão

Uma loja vende R$ 243,70. O cliente entrega R$ 100,00 em dinheiro e paga R$ 150,00 no cartão, totalizando R$ 250,00. O troco efetivamente devolvido é R$ 6,30. Se o XML registrar R$ 5,30, a comparação não fecha. Depois de conferir os comprovantes, a equipe corrige o dado de troco na origem e gera outro XML pelo emissor.

Agora imagine que os R$ 150,00 do cartão tenham sido enviados duas vezes. O XML somaria R$ 400,00. Informar R$ 156,30 de troco fecharia a conta, mas falsearia a venda. A solução seria corrigir a duplicação do pagamento, mantendo o troco real. Assim, a conferência aritmética ajuda a localizar a falha sem substituir a realidade da operação.

Campos novos não substituem o troco por aproximação

A NT 2025.002 v1.52 apresenta totalizações próprias como vItem e vNFTot. Isso não autoriza substituir vNF por um desses valores na fórmula da YA09-10. Da mesma forma, a NT 2026.006 v1.00 trata da vinculação de transações de pagamento, com grupo e evento próprios; sua página 3 preserva as exigências pertinentes dos grupos de pagamento existentes.

Não some previsões de pagamento, identificadores de transação ou valores de outro documento aos detalhes desta nota. Se a atualização do emissor alterou a montagem dos totais, encaminhe o XML e a versão ao suporte para análise específica, preservando os comprovantes reais.

Corrija, verifique e encaminhe quando necessário

Faça a alteração na origem identificada e confira novamente os três valores. Se não houve excesso de pagamento, investigue um troco remanescente no cadastro ou na venda. A decisão entre zero e omissão de um campo opcional deve respeitar a especificação aplicável e o cenário; não use a omissão como atalho para ocultar uma divergência.

Quando a falha for recorrente, peça ao suporte uma conferência do cálculo e da atualização após descontos. Um teste representativo em homologação pode ajudar a observar o comportamento, preservando a separação em relação à produção. Não edite diretamente um XML já assinado como procedimento de emissão, nem altere o total fiscal para acomodar um pagamento errado.

Após retransmitir pelo fluxo do emissor, leia o retorno completo. A ausência da 869 não significa autorização automática: outra rejeição pode aparecer. Confirme a situação e o protocolo no ambiente correto, além da ligação com a venda. Se a resposta se perder, consulte a situação antes de emitir novamente. Persistindo a dúvida, encaminhe ao suporte os arquivos, os valores comparados e os horários por canal protegido; envolva a contabilidade quando o problema for de enquadramento fiscal.

Fontes

Conferência documental em 15/10/2026.

• MOC 7.0, Anexo I: páginas 59, 62–63 e 126, vNF, pagamentos, vTroco e YA09-10/869.

• NT 2016.002 v1.61, página 67. Portal Nacional: schemas XML, pacote 010f.

• NT 2025.001 v1.03, página 10, regra de troco ausente; NT 2025.002 v1.52, páginas 68 e 71, outras totalizações; NT 2026.006 v1.00, página 3, grupos distintos.

• Apoios específicos: Vinco, InvoiSys, Dynamicca. Menus, exemplos e afirmações particulares foram confrontados com as fontes oficiais; não descrevem funções comprovadas do ALRA.