dPag na NF-e: data do pagamento e rejeição 657

dPag, em /nfeProc/NFe/infNFe/pag/detPag/dPag, é a data do pagamento no respectivo detalhe. Ela não é a data de vencimento de uma parcela nem uma previsão de quando o cliente pagará. O campo é opcional na estrutura e usa data no formato AAAA-MM-DD.

Qual data deve ser conferida

Obtenha a data do registro documentado do pagamento correspondente à venda e ao detPag, conforme o contrato da integração. Uma cobrança emitida, um pedido aprovado ou uma data futura acordada não demonstram que houve pagamento nessa data. A data de repasse da adquirente pode representar outro movimento financeiro; confirme o significado do retorno usado antes de mapear para dPag.

ide/dhEmi informa a emissão da nota, com hora/fuso. cobr/dup/dVenc informa o vencimento da parcela, sem hora. dPag informa o pagamento. As datas podem ser diferentes porque respondem a eventos diferentes. Não copie emissão ou vencimento como pagamento por ausência de informação.

Formato, posição e regra de data futura

A NT 2023.004 acrescentou dPag com ocorrência 0..1 por detPag. Ele aparece depois de vPag e antes do par opcional CNPJPag/UFPag e de card. Não inclua um horário no elemento nem use formato brasileiro com barras.

A YA03a-10, modelos 55/65, verifica se a data de pagamento informada é posterior à data de recebimento do XML pela autorizadora, com rejeição 657. A comparação descrita é com o recebimento do XML, não uma regra de igualdade universal com a emissão. Uma data anterior à emissão não é proibida por esse enunciado isolado; sua pertinência deve ser comprovada pela transação real.

Exemplo e diferença para uma previsão

Suponha um pagamento documentado em 26/09/2026 e recebimento do XML em 26/09/2026. Fragmento parcial e sintético, sem outras informações da NF-e/NFC-e e sem aptidão para transmissão:

<detPag xmlns="http://www.portalfiscal.inf.br/nfe">
  <tPag>01</tPag>
  <vPag>100.00</vPag>
  <dPag>2026-09-26</dPag>
</detPag>

Se dPag fosse 27/09/2026 nesse envio, representaria uma data posterior à recebida na hipótese e atenderia a condição de 657. Se 27/09 é apenas uma previsão comercial de pagamento, o problema é também de significado: uma previsão não deve ser declarada como data de pagamento realizado.

A tabela atual inclui 91-Pagamento Posterior, com observação para pagamento integral ou parcial posterior à emissão/fato gerador. Esse código não transforma uma data futura em dPag válida nem significa 90-Sem Pagamento.

Como investigar 657 e pagamento ocorrido depois

Confira o valor serializado, o calendário, o registro de pagamento e a data de recebimento do XML, considerando o retorno da autorizadora. Verifique conversão indevida de fuso/hora para data, trocas de dia/mês e herança de vencimento. Corrija o dado ou mapeamento do rascunho a partir do registro real e revalide, não apenas substitua por “hoje”.

Se o pagamento ocorreu depois de uma nota já autorizada, não edite o XML assinado para inserir dPag. A NT 2024.002 descreve o ECONF, evento facultativo para vincular recursos recebidos à nota, inclusive distantes da emissão; seu leiaute e sua validação são próprios. A existência do evento não é autorização para transmiti-lo sem confirmar empresa, documento, ambiente e aplicabilidade.

O grupo YC e evento 110300 da NT 2026.006 têm finalidade distinta de vinculação preparatória para split payment, sem exigência de uso em produção em 2026, e não substituem YA/YB/ECONF. O recebimento posterior e seus efeitos fiscais/contábeis dependem dos documentos da operação; a data não decide esses efeitos. Veja dVenc e vencimento e tPag e pagamento posterior.

Fontes oficiais

• NT 2023.004 — Informações de Pagamentos e Outros, 1.20; p. 3–6, 11–12, 14–15.
• Tabela de meios de pagamento, Publicada SVRS 04/03/2026; Plan1!A2:E26.
• NT 2024.002 — Evento de Conciliação Financeira ECONF, 1.00; seções 1–3.
• NT 2026.006 — Vinculação da transação de pagamento, 1.00; p. 3 e 7.