Rejeição 857: corrija o meio de pagamento informado na NFC-e

A rejeição 857 — Informado Duplicata Mercantil como Forma de Pagamento ocorre quando a NFC-e, modelo 65, informa 14 no campo tPag. A regra YA02-10 identifica essa combinação. Para corrigir, confira como o cliente realmente pagou ou contratou o pagamento e ajuste o vínculo entre a condição comercial cadastrada e o código enviado no XML.

O nome exibido na venda pode esconder a causa: uma opção chamada “parcelado”, por exemplo, pode estar configurada para transmitir duplicata mercantil. Alterar apenas esse nome não resolve se o arquivo continuar levando tPag=14. A conferência deve alcançar o XML efetivamente transmitido e a origem do seu preenchimento.

O que precisa ser distinguido

O meio de pagamento fica em pag/detPag/tPag. Já indPag, quando informado, distingue pagamento à vista e a prazo. Parcelamento, vencimentos e títulos a receber são informações relacionadas à operação, mas não tornam toda venda a prazo uma duplicata mercantil. Uma compra parcelada no cartão continua exigindo a identificação correta do cartão utilizado.

Também há diferença entre pagamento e o grupo de cobrança cobr. A presença de fatura ou duplicata na NFC-e está sujeita à rejeição 760. Acrescentar esse grupo para “justificar” o código 14 não corrige a 857. A rejeição 852, por sua vez, trata do número da parcela na regra Y08-10, aplicável ao modelo 55. Não se resolve o problema atual renumerando parcelas.

O MOC apresenta a YA02-10 como obrigatória para o modelo 65, sem exceção própria expressa nessa linha. Isso delimita o diagnóstico documental; não certifica o comportamento de cada instalação. Se o retorno vier associado a um XML modelo 55, confirme a mensagem completa, o documento e o serviço consultado antes de aplicar esta orientação.

O código existe na tabela, mas isso não permite seu uso na NFC-e

A tabela oficial publicada em 4 de março de 2026 mantém o código 14, identificado como duplicata mercantil, sem data final preenchida. Essa presença no domínio geral não elimina a restrição específica da NFC-e. Portanto, não conclua que o emissor está correto apenas porque encontrou o código em uma tabela atualizada.

Da mesma forma, o esquema XML consultado no pacote 010f representa tPag como dois algarismos. Um valor pode respeitar esse formato e, ainda assim, ser recusado por uma regra de negócio. A validação estrutural do arquivo e a autorização fiscal verificam aspectos diferentes.

A tabela atual também distingue modalidades de crediário, crédito decorrente de valor anterior, formas de Pix e pagamento posterior. Essas categorias possuem descrições e condições próprias. Evite copiar listas antigas ou transformar uma delas em substituto automático da duplicata. Quando houver dúvida sobre a classificação da operação real, valide o enquadramento com o responsável fiscal antes de mudar o cadastro.

Como corrigir com segurança

1. Guarde o retorno e o arquivo rejeitado. Registre cStat, xMotivo, data da tentativa, chave, modelo, UF, autorizador e ambiente. Confirme que o XML examinado corresponde à mesma transmissão, especialmente se existem vários documentos semelhantes na fila.

2. Localize todos os detalhes de pagamento. Confira cada ocorrência de detPag, seus códigos e valores. Uma venda pode combinar meios diferentes; corrigir um registro e deixar outro com código 14 mantém a causa identificada pela regra.

3. Confira a operação comercial. Compare pedido, comprovante de pagamento, condição negociada e registros financeiros. Determine se houve cartão, dinheiro, boleto, crediário ou outra modalidade efetivamente aplicável. Não presuma a forma fiscal pelo nome abreviado usado pelo caixa.

4. Ajuste o cadastro ou a integração que produz o código. Se o vínculo estiver incorreto, corrija a configuração responsável e gere novamente o documento. Se a origem for uma importação, examine o valor recebido e sua conversão. Uma edição isolada no arquivo pode desaparecer na próxima geração e não corrige o processo.

5. Confira o novo XML antes de transmitir. Verifique o meio correto, os valores distribuídos entre os pagamentos e as demais informações exigidas para a modalidade utilizada. Preserve o total da operação, o histórico financeiro e os vencimentos reais; a correção fiscal não significa dar baixa em uma dívida nem registrar novo recebimento.

6. Acompanhe a resposta da nova tentativa. Prossiga pelo fluxo de correção do emissor e leia o retorno completo. A ausência da 857 não garante autorização: outra validação pode apontar uma pendência distinta, que deve ser tratada pelo seu próprio motivo.

Exemplo de erro de vínculo

Uma papelaria vende R$ 186,40, pagos no cartão de crédito em duas parcelas. O cadastro “cartão parcelado” foi importado com o código fiscal 14. O XML da NFC-e leva duplicata mercantil, embora o comprovante demonstre uma operação no cartão.

Nesse caso hipotético, a equipe corrige o vínculo para a modalidade real de cartão de crédito, identificada pelo código 03 na tabela consultada. Mantém os R$ 186,40 e os registros do parcelamento, confere as informações aplicáveis ao pagamento com cartão e gera novamente o XML. A decisão decorre do comprovante; não é uma troca universal de 14 por 03.

O que não fazer e quando pedir apoio

Não marque dinheiro, boleto ou “Outros” apenas para liberar a transmissão. Também não escolha “Sem Pagamento” porque o cliente ainda pagará: prazo e inexistência de pagamento são conceitos diferentes, e a NFC-e possui validação específica para o código 90. O código 91, “Pagamento Posterior”, também exige análise da situação e das condições da tabela; não funciona como correção automática.

Não apague contas a receber nem mude o modelo do documento só para contornar a rejeição. Se a negociação realmente envolver duplicata mercantil, peça ao responsável fiscal a definição do documento e do tratamento compatíveis com a operação. O sistema precisa representar o fato comercial corretamente.

Se o código 14 reaparecer após o ajuste, encaminhe ao suporte o XML anterior e o novo, o retorno completo e a condição de pagamento utilizada. Isso permite localizar cadastros antigos, conversões de integração ou regras que sobrescrevem a escolha. No ALRA, confirme o caminho de configuração disponível na versão instalada; menus de outros emissores não comprovam o procedimento local.

Fontes

• MOC 7.0, Anexo I, páginas 62 e 125: campos de pagamento e regra YA02-10.

• Tabela oficial de meios de pagamento, publicada em 04/03/2026 e IT 2024.002 v1.11.

• Portal Nacional: esquemas XML: pacote 010f consultado para a representação dos campos.

Conferência documental em 15/10/2026. A aplicação no caso concreto depende da operação e da versão em uso no respectivo autorizador e ambiente.