Rejeição 659: ano e mês da emissão diferentes da chave no EPEC

A rejeição 659 exige conferir duas informações do evento EPEC: a data de emissão indicada em detEvento/dhEmi e o ano e mês contidos na chave enviada em infEvento/chNFe. Quando esses dados divergem, a regra P23-40 rejeita o evento. Comece pelo XML efetivamente transmitido e pelo retorno individual, preservando os arquivos para localizar a origem da diferença.

A mensagem é “Ano-Mês da Data de Emissão diverge do Ano-Mês da Chave de Acesso”. A NT 2014.001 v1.41, página 11, documenta a regra como obrigatória para NF-e, modelo 55, no serviço do Evento Prévio de Emissão em Contingência, código 110140. Esse contexto importa: receber esse retorno não equivale, por si só, a conhecer a situação de autorização da NF-e correspondente.

Localize o documento e o serviço envolvidos

Confirme o código e a mensagem completos, o modelo, o ambiente e a tentativa que produziu a resposta. Identifique o evento dentro do lote, a chave e o emitente. Uma mensagem resumida na tela pode omitir informações necessárias para distinguir problemas diferentes.

O EPEC contém dados reduzidos da NF-e e é encaminhado ao Ambiente Nacional. A documentação exige correspondência com a NF-e que lhe deu origem. A autorização do evento e a autorização de uso da nota são etapas distintas, com respostas e controles próprios.

Este diagnóstico não deve ser aplicado automaticamente à NFC-e, ao CT-e ou ao MDF-e. O mesmo número de status pode ter outro significado em outro documento. Também não confunda a 659 com a rejeição 561, relativa à comparação do mês no contexto da autorização da NF-e.

Compare a data de emissão com o trecho AAMM

Na estrutura da chave descrita no MOC, os dois primeiros caracteres identificam a UF e os quatro seguintes representam o ano e o mês da emissão, no formato AAMM. Assim, esse trecho ocupa as posições 3 a 6. Ele não representa a data de transmissão ou o momento em que o retorno chegou.

No evento, dhEmi informa a data e hora de emissão da NF-e. Já dhEvento informa a data e hora do evento. Confira os nomes completos dos campos: substituir a data de emissão pela data do evento pode introduzir a divergência, especialmente quando o processamento atravessa uma mudança de mês ou ano.

Preserve o formato e o indicador de fuso previstos no leiaute. Uma rotina que converta horários, reaproveite uma data antiga ou escolha a data atual precisa ser examinada pelo responsável técnico. Não ajuste o relógio ou o fuso por tentativa, nem invente uma conversão de mês para obter aceitação.

Se a data enviada estiver incorreta

Compare a informação transmitida com o documento preparado e com os registros que comprovam a emissão. Investigue se a integração utilizou a data de importação, de reprocessamento ou de envio em lugar da data de emissão correspondente.

Uma correção no cadastro ou na tela não demonstra que o evento pendente foi atualizado. Confira o arquivo gerado depois do ajuste. No ALRA, peça ao suporte a identificação da origem e do mapeamento desse campo, sem presumir menus ou atualização automática de arquivos já preparados.

Corrija somente o dado comprovadamente errado, respeitando a situação do documento e o procedimento aplicável. Trocar a emissão pela data de hoje apenas para combinar com a chave pode falsear o fato fiscal e ainda provocar outras rejeições de data.

Se a chave estiver ligada a outra informação

Verifique se o evento recebeu a chave da NF-e correta. Integrações podem associar arquivos de tentativas diferentes ou recuperar uma referência que não corresponde ao documento analisado. Essa é uma hipótese de diagnóstico, não uma causa comprovada pelo código isolado.

Confira a relação entre a chave, a emissão e os dados originais. A chave e os identificadores associados devem ser produzidos pelo emissor conforme o leiaute aplicável. Não substitua manualmente os quatro caracteres do AAMM dentro do XML: a chave participa de outros campos e controles, e o evento possui assinatura digital.

Antes de gerar outro arquivo, consulte a situação das tentativas anteriores pelo fluxo autorizado. Um evento rejeitado não comprova que inexista uma NF-e autorizada ou outro EPEC registrado. Por isso, a 659 não autoriza concluir que a numeração está livre para uso em qualquer circunstância.

Exemplo de investigação

Considere um evento fictício cuja chave contenha o trecho 2610, correspondente a outubro de 2026. O campo dhEmi, entretanto, indica uma emissão em setembro de 2026. Há diferença entre os meses representados, que deve ser investigada na origem dos dados.

Se os registros demonstrarem que o evento recebeu indevidamente a data de importação, a equipe corrige esse mapeamento. Se a chave pertencer a outro documento, apura a associação incorreta. O exemplo não determina qual valor deve prevalecer: isso depende da emissão verdadeira e da situação fiscal já existente.

Depois da correção comprovada, o emissor deve gerar e assinar o arquivo correspondente. Não edite um XML assinado, não altere um EPEC já registrado e não modifique uma NF-e autorizada para fazer os dados coincidirem.

Leia o retorno e respeite as outras validações

O status 128 informa que o lote foi processado; ele não comprova sucesso de cada evento. Leia retEvento/infEvento, o código, o motivo e o protocolo pertinente. Para o EPEC, a NT descreve o sucesso como 136 — evento registrado, mas não vinculado à NF-e; não trate esse protocolo como autorização de uso da nota.

As verificações de emissão futura, emissão atrasada e emissão posterior ao evento são distintas da P23-40. A tolerância de cinco minutos documentada para a primeira não constitui tolerância para ano e mês divergentes na 659.

A pesquisa de 16/10/2026 confirmou a v1.41 e suas restrições específicas de EPEC, inclusive para contribuintes do Paraná e da Paraíba. Corrigir a comparação de datas não libera uma modalidade vedada. Confirme a possibilidade de uso conforme UF, ambiente e período, e acompanhe separadamente a autorização da NF-e e a conciliação do EPEC. A ausência da 659 não garante aprovação nas demais regras.

Fontes

• NT 2014.001 v1.41: captura oficial de 16/10/2026; páginas 1, 3–8 e 11–15 lidas para este artigo. Página 11 também conferida em imagem documental existente.

• MOC 7.0 — Visão Geral: captura de 15/10/2026 reutilizada; páginas 19–20 e 114–117 lidas, com conferência visual prévia da página 115 nesta pesquisa.

• Berga, Webmania e Buscador NCM: dois guias e uma ficha específica lidos em 16/10/2026. Generalizações sobre NFC-e, autorização, reaproveitamento de numeração e geração com a data atual foram filtradas pelas fontes primárias.

• Rastro e limitações em fontes.v1.json. Sem transmissão de evento, consulta individual, teste no ALRA, nova imagem ou publicação.