Rejeição 659: Ano-Mês da Data de Emissão diverge do Ano-Mês da Chave de Acesso

A Rejeição 659 acontece quando o ano e o mês que estão dentro da chave de acesso divergem da data de emissão informada no corpo da nota.

Abrir Notas Fiscais

Por que acontece a Rejeição 659

A chave carrega a data de emissão nos dígitos 3 a 6, no formato AAMM — dois de ano, dois de mês. A SEFAZ compara com o campo da data e cobra coerência.

É parente próxima da rejeição que compara apenas o mês: esta olha os dois campos juntos, e pega também a divergência de ano.

A causa que domina tem data marcada: a virada do ano. A nota é montada em 31 de dezembro à noite e transmitida já em janeiro — a chave fica com o ano antigo e o campo da data com o novo.

As demais causas:

Nota editada depois de montada. A data foi alterada e a chave não foi refeita.

Nota antiga retransmitida. Um arquivo de meses atrás foi reprocessado com data regerada.

Integração com montagem própria. Chave e data geradas em momentos diferentes.

Como resolver a Rejeição 659

1. 1
   Não corrija a chave nem a data isoladamente — os dois nascem juntos.
2. 2
   Gere a nota novamente, com chave e data montadas no mesmo instante.
3. 3
   Sendo XML de integração, a origem precisa usar a mesma data nos dois pontos.
4. 4
   Reenvie.

Como evitar a Rejeição 659

Nunca edite XML depois de gerado.

Na virada do ano, feche a emissão antes da meia-noite e reabra no ano novo. Além desta rejeição, a virada produz erros de data de saída e de numeração.

Se a Rejeição 659 continuar

Existe a rejeição vizinha que compara apenas o mês, e as que validam a chave por outros trechos: dígito verificador, UF, CNPJ, modelo, número e código numérico.

Persistindo, abra um chamado informando a chave de acesso completa e a data de emissão.

Referência: MOC 7.0 — Anexo I, validação da chave de acesso da NF-e.