Rejeição 853: parcela única com vencimento no dia da emissão

A rejeição 853 apresenta a mensagem “Dados de cobrança não devem ser informados para pagamento à vista”. Para entender o problema, é necessário conferir o conteúdo da cobrança enviado na NF-e. A descrição resumida não significa que qualquer marcação de pagamento à vista, sozinha, seja o teste realizado pela regra.

Na NT 2025.001, versão 1.03 corrigida, a Y09-40 examina a NF-e, modelo 55, com apenas uma ocorrência de dup. Se o vencimento dVenc dessa parcela for igual à data de emissão dhEmi, desconsiderando a hora, a situação corresponde ao predicado da rejeição 853. Esses três elementos orientam a investigação.

Comece pelo XML da nota rejeitada

Localize o grupo de cobrança e conte as ocorrências de parcelas. Depois, compare o vencimento da única parcela com a parte de data da emissão. A hora registrada em dhEmi não permite afastar a igualdade: emissão de manhã e vencimento no mesmo dia continuam coincidindo para essa verificação.

Confira o arquivo que efetivamente foi enviado. Uma tela pode mostrar informações atualizadas enquanto o XML rejeitado ainda contém a versão anterior da cobrança. Também pode existir uma duplicata gerada automaticamente, mesmo quando o operador não lançou parcelas manualmente. O documento transmitido ajuda a identificar essa diferença.

Não use apenas o rótulo “à vista” da tela, o indicador indPag ou o meio tPag como prova de que a Y09-40 foi atendida. Esses campos possuem funções próprias. O critério descrito nessa regra é a presença de uma única parcela com vencimento igual à data de emissão, e a análise deve começar por essa combinação.

Um exemplo da situação

Imagine uma NF-e emitida em 16 de outubro de 2026, às 14 horas, contendo somente a duplicata 001, com vencimento em 16 de outubro de 2026. A diferença entre uma data com horário e outra sem horário não altera o resultado: para a Y09-40, a comparação desconsidera a hora da emissão.

Suponha que o cliente tenha pago a compra no momento da venda, mas o emissor tenha criado essa duplicata por uma configuração automática. A correção deve tratar a representação indevida da cobrança. É preciso preservar os dados verdadeiros do pagamento e conferir como o sistema gera os grupos fiscais antes de transmitir novamente.

Se, por outro lado, o vencimento correto era 30 de outubro e foi digitado como dia 16, existe um erro documental diferente. Corrigir a data para a condição realmente acordada é adequado; escolher um dia posterior sem que haja esse acordo não é uma solução válida para o fato registrado.

Como corrigir sem criar uma cobrança fictícia

Compare a nota com o pedido, a condição comercial e o lançamento financeiro. Identifique se a parcela deveria existir, se o vencimento foi importado incorretamente ou se a rotina de emissão transformou uma venda à vista em uma cobrança no XML. Essa distinção determina qual informação deve ser corrigida.

Quando a parcela foi gerada indevidamente, ajuste a origem do preenchimento e retire a duplicata que não corresponde à operação. Confira também o restante do grupo de cobrança para que não sobrem informações incompatíveis com a representação correta. Isso não autoriza apagar dados reais de pagamento nem cancelar títulos verdadeiros sem análise.

Quando o prazo foi informado de maneira errada, restaure o vencimento comprovado pelos documentos comerciais. Se a cobrança foi renegociada de verdade, mantenha o registro do acordo e avalie seus efeitos com os responsáveis. A necessidade de resolver uma rejeição não substitui a documentação da alteração comercial.

Não crie uma segunda parcela apenas para deixar de ter uma ocorrência única. Também não coloque vencimento no dia seguinte por conveniência, não altere a emissão e não mude o meio de pagamento para uma opção que não representa o ocorrido. Essas medidas podem afastar um teste sem corrigir o conteúdo da nota.

Cobrança e pagamento precisam continuar coerentes

Os grupos de cobrança e de pagamento são relacionados, mas não representam a mesma informação. A retirada de uma duplicata indevida não significa apagar o valor efetivamente pago. Verifique os dados exigidos para a operação e para o leiaute utilizado, mantendo a correspondência entre documento fiscal, venda e financeiro.

Evite aplicar uma regra universal a todas as vendas no cartão apenas com base no nome do meio de pagamento. Prazo comercial, recebimento pela empresa e relação com a instituição financeira precisam ser entendidos no caso concreto. A Y09-40 não fornece, sozinha, um tratamento completo para todas essas situações.

A mensagem 853 também não substitui as outras verificações de fatura e parcelas. Valores, numeração, vencimentos anteriores e campos obrigatórios possuem regras específicas. Para NFC-e, modelo 65, há tratamento próprio para dados de cobrança; não transfira automaticamente a Y09-40 do modelo 55 para esse documento.

Confira o novo resultado

Após ajustar a origem, gere novamente o XML e confirme que a duplicata indevida desapareceu ou que o vencimento verdadeiro foi transmitido. Se o sistema restaurar a informação antiga, investigue a configuração ou integração responsável. Alterar apenas uma visualização ou o DANFE não comprova correção do conteúdo fiscal.

Leia o retorno individual após o novo envio. Uma atualização de sistema pode corrigir uma rotina, mas não garante autorização de qualquer nota. Preserve o XML e a resposta recebida. Havendo dúvida sobre uma tentativa anterior, consulte a situação pelo procedimento apropriado antes de tomar decisões sobre o documento.

No atendimento do ALRA, apresente a mensagem, a quantidade de parcelas, a data de emissão e o vencimento esperado, com os dados sensíveis protegidos. Os nomes de menus usados por outros emissores servem apenas ao produto descrito nesses guias. O caminho no ALRA deve ser confirmado na versão em uso.

Fontes

• Portal Nacional da NF-e: NT 2025.001, versão 1.03 corrigida, página 10, Y09-40; MOC 7.0, Anexo I, página 125, como contexto histórico das demais regras de cobrança.

• Treeunfe: rejeição 853, com generalizações delimitadas pelo predicado oficial.

• NFeLink: rejeição 853, sem transportar seus menus para o ALRA.

• Datacaixa: rejeição 853. Alterar prazo sem fundamento ou prometer autorização não foi adotado.

Documentos oficiais citados: NT 2025.001 v1.03 corrigida, MOC 7.0, Anexo I.