Rejeição 657: confira a data de pagamento na nota ou no ECONF

A rejeição 657 pode indicar uma data de pagamento posterior à data aceita pelo serviço fiscal. A correção começa pela identificação do documento enviado: o XML de autorização da NF-e/NFC-e e o evento de Conciliação Financeira, ECONF, possuem regras próprias. Embora usem o mesmo código e uma mensagem semelhante, não comparam a data com o mesmo marco de processamento.

Antes de alterar qualquer campo, obtenha o cStat, o xMotivo completo e o arquivo efetivamente transmitido. Há também uma descrição antiga de 657 ligada ao código do órgão autorizador. Se essa for a mensagem recebida, o procedimento de pagamento abaixo não basta para diagnosticar o caso.

Quando o erro está na autorização da nota

Na NT 2023.004 v1.20, regra YA03a-10, o código 657 se aplica à NF-e modelo 55 e à NFC-e modelo 65 quando a data de pagamento informada em dPag é posterior à data de recebimento do XML. A validação é obrigatória no contrato documental quando o campo está preenchido.

O leiaute apresenta dPag dentro do detalhamento do pagamento, com ocorrência opcional. Isso não significa que apagar o campo seja uma solução automática: é necessário verificar se o dado corresponde à operação e se há obrigação aplicável ao caso. A correção deve representar os fatos, não simplesmente fazer a mensagem desaparecer.

Observe a comparação exata: a referência é o recebimento do XML, não necessariamente a emissão da nota. Não crie uma regra interna que rejeite todo pagamento posterior à emissão. Uma nota transmitida posteriormente pode ter uma cronologia diferente, e o diagnóstico precisa considerar o arquivo e a resposta efetivos.

O complemento nOcor indica a ocorrência a conferir no grupo repetido. Não confunda esse marcador com o número de um produto. Em uma venda com mais de uma forma de pagamento, o suporte precisa localizar qual detalhamento contém a data incompatível antes de corrigir o cadastro ou a integração de origem.

Quando o erro está no ECONF

A NT 2024.002 v1.00, regra P26-10 rejeita a data de pagamento maior que a data de processamento do evento. O ramo se refere ao evento 110750, Conciliação Financeira, vinculado a NF-e ou NFC-e. Não é a autorização original da nota nem o evento de cancelamento do ECONF.

Nesse leiaute, dPag é obrigatório em cada detalhamento de pagamento, no formato AAAA-MM-DD. Para um pagamento agendado, a descrição do campo determina a data de efetivação. O vencimento de uma cobrança ou a previsão de recebimento não comprovam que o recurso foi efetivamente pago naquela data.

O uso do ECONF é facultativo segundo essa nota técnica. Ele relaciona transações financeiras à operação documentada, inclusive quando o recebimento ocorre distante da emissão. Por isso, uma data posterior à emissão da nota não é, isoladamente, causa de 657 no evento. O problema focal é uma data posterior ao processamento.

Também separe dPag de dhEvento. O primeiro registra a data do pagamento; o segundo identifica data e hora do evento. A tolerância de cinco minutos prevista em outra validação, para dhEvento, não deve ser transportada para P26-10. Alterar o relógio ou a data do evento não corrige um pagamento informado incorretamente.

Uma conferência em cinco passos

1. Identifique o serviço: autorização ou RecepcaoEvento. Anote modelo, ambiente, versão do sistema e, no evento, tpEvento

2. Localize a ocorrência indicada e compare o dPag transmitido com o documento financeiro que sustenta a informação

3. Verifique se o sistema copiou vencimento, agendamento, data de importação ou outro campo no lugar da data de pagamento

4. Corrija a origem e gere novamente o arquivo pelo sistema responsável, preservando a versão rejeitada para rastreabilidade

5. Retransmita de forma controlada e confira o resultado individual da nota ou do evento, guardando o protocolo quando houver

Considere um exemplo fictício: um evento é processado em 10 de outubro, mas informa como realizado um pagamento agendado para 12 de outubro. A solução não é substituir a data por 10 de outubro sem comprovação. Deve-se verificar a efetivação real e o momento adequado de informar a transação.

Em outro cenário, o comprovante registra pagamento em 9 de outubro, mas uma integração enviou 9 de novembro. A equipe deve corrigir a conversão da data e verificar outros lançamentos afetados. O acerto isolado na tela não resolve uma rotina que continuará produzindo o mesmo erro.

O que conferir na configuração

Para ECONF de NF-e 55, a NT descreve atendimento pela SVRS para contribuintes de todas as UFs. Para NFC-e 65, determina o serviço de eventos da UF, na mesma URL utilizada para cancelamento, respeitando a configuração aplicável. Modelo, ambiente e órgão receptor devem estar coerentes, mas uma mensagem de data inválida não autoriza trocar o destino indiscriminadamente.

Confira a compatibilidade do ERP, do componente transmissor e dos schemas com o evento. Documentações de fornecedores mostram que a adequação pode envolver mais de um módulo e atualização de endereços. A data de liberação de uma versão comercial não comprova que a instalação da empresa já esteja atualizada.

O cronograma da NT 2023.004 distinguiu entrada de schemas e regras; a versão 1.11 indicou 01/07/2024 para as regras em geral, mas previu 01/10/2024 especificamente para YA09-20, relativa ao troco. A NT 2024.002 previu produção em 02/09/2024. São referências documentais: este artigo não certifica disponibilidade operacional universal em cada UF e ambiente.

Se a mensagem mencionar o órgão autorizador

A tabela do MOC 7.0, Anexo I, página 149 conserva para 657 a descrição “Código do Órgão diverge do órgão autorizador”. Esse registro histórico não deve ser apagado nem confundido com as regras posteriores de pagamento.

A pesquisa não identificou, para esse rótulo isolado, uma regra operacional atual suficientemente delimitada por serviço, modelo e UF. Esse ramo permanece pendente de confirmação. Diante desse retorno, preserve endpoint, XML e mensagem e solicite análise do contrato específico ao fornecedor, sem alterar a data de pagamento por tentativa.

O objetivo final é retomar o envio com informações verdadeiras e resultado verificável. Uma nota já autorizada não deve ser editada como se ainda fosse um rascunho; a rejeição de um ECONF exige tratar o evento correspondente, preservando a integridade do documento fiscal original.

Base consultada

MOC 7.0, NT 2023.004 v1.20 e NT 2024.002 v1.00, em cópias oficiais preservadas em 09/10/2026 e relidas em 10/10/2026. O arquivo da NT 2023.004 não foi recapturado pela rede.

Três leituras práticas contextuais, sem substituir a regra oficial de 657: TecnoSpeed, estrutura do ECONF, TOTVS, adequação do Protheus e TSS e Senior, liberação do ECONF no ERP XT.