Rejeição 615: confira o ano da chave sem mudar a data da nota original

A rejeição 615 informa que o ano contido na chave de acesso está abaixo do limite documentado ou acima do ano corrente. Para resolver, encontre a chave autêntica do documento e confira como ela foi enviada na consulta ou no evento. Uma nota antiga não deve receber um ano novo para passar na validação.

Essa distinção é importante para o empresário: o retorno pode vir de uma solicitação posterior à emissão. Ele não demonstra, sozinho, que a operação precisa ser faturada novamente ou que o XML autorizado esteja errado.

Qual ano está sendo analisado?

Na chave de 44 posições, os caracteres 3 e 4 representam o ano com dois algarismos. Os caracteres 5 e 6 representam o mês. Esse bloco AAMM corresponde à emissão do documento identificado pela chave, não ao dia em que alguém tenta consultá-lo.

A regra documenta ano menor que 06 ou maior que o ano corrente. Em uma consulta feita em 2026, por exemplo, 05 fica abaixo do piso e 27 fica acima do ano corrente. Já 24 não é inválido apenas por representar uma emissão de 2024. Outras regras podem afetar a consulta, mas isso não transforma 24 em erro 615.

O diagnóstico precisa considerar a chave inteira. Se uma planilha perdeu um caractere, o sistema pode estar interpretando como ano um trecho que originalmente pertencia a outro componente. Trocar apenas dois algarismos não repara essa perda.

Consulta, distribuição e eventos

O MOC 7.0, Visão Geral, página 83, apresenta J02c para NfeConsultaProtocolo, com modelos 55 e 65 no contrato. A solicitação consulta a situação pela chave; ela não modifica a emissão.

Na distribuição de NF-e, H09 com nota de rodapé 2 aplica a validação ao pedido consChNFe. Esse recorte está no MOC, página 96, e na NT 2014.002 v1.40, página 11. Não confunda o ano da chave com NSU, prazo de download ou data de importação no ERP.

Nos eventos, P12-18 verifica o ano da chave vinculada. Há documentação em EPEC, manifestação do destinatário, entrega, insucesso de entrega, ECONF e outros contratos. A prorrogação de industrialização usa P11. O modelo permitido, o autor e o ambiente dependem do evento concreto.

No Ator Interessado, a NT 2020.007 v1.40 condiciona essa regra, marcada com a nota correspondente, a tpAutor=1. EPEC NFC-e e cancelamento por substituição têm contextos de modelo 65; sua documentação não estabelece disponibilidade irrestrita por UF ou perfil de emitente.

Um roteiro que preserva a operação real

1. Identifique a etapa que falhou. Guarde cStat e xMotivo, serviço, ambiente, horário, chave enviada e versão do sistema. Para evento, registre também seu tipo e autor.

2. Recupere XML e protocolo do documento de origem. Compare estabelecimento, modelo, série, número e data, para não usar uma nota parecida.

3. Confira as posições do ano e o comprimento total. Verifique digitação, leitura de imagem, perda de zeros e importação de planilha. Preserve a chave como texto.

4. Compare o valor transmitido com o mostrado na tela. Uma integração pode reutilizar um campo antigo mesmo quando o cadastro parece correto.

5. Corrija o vínculo da solicitação rejeitada usando a chave original. Deixe a aplicação regenerar e assinar o evento quando houver alteração no seu conteúdo.

6. Verifique o resultado da nova tentativa. O fim de 615 não significa, por si só, documento autorizado, evento aceito ou arquivo disponibilizado.

Se o documento ainda estiver em preparação e nunca tiver sido autorizado, uma data incorreta na origem pode exigir correção dos fatos de emissão no sistema. Antes disso, confirme a ausência de autorização anterior. Essa situação é diferente de trocar a data de uma nota já existente para atender a uma consulta.

Exemplo: nota antiga importada hoje

Uma empresa importa em outubro de 2026 os arquivos fiscais de 2024. A integração recebe uma chave cujo ano aparece como 27, embora o XML original pertença a 2024. A equipe identifica que a rotina recompôs o identificador com uma data inadequada.

A correção é recuperar a chave integral do XML correto e reparar a rotina de importação. A nota não passa a ser de 2026 porque entrou no ERP naquele ano. Também não se deve produzir um XML novo, com outro ano e os mesmos dados comerciais, para substituir o arquivo original.

Se a chave autêntica tiver ano válido e a consulta falhar por antiguidade, analise a mensagem efetivamente recebida. Esse caso tem tratamento diferente e pode continuar existindo depois que a importação foi corrigida.

Não misture ano inválido com antiguidade

A rejeição 526 trata de chave consultada muito antiga, sob condições próprias do autorizador. Ela não estabelece que todo ano anterior ao corrente seja proibido. Tampouco autoriza deslocar a operação no tempo.

A 524 examina ano e mês de documentos referenciados durante autorização. A 616 verifica a faixa do mês da chave em outros contratos. Já a data do próprio evento tem validações específicas: corrigir dhEvento não altera o ano embutido em chNFe.

Também existe diferença entre formato de data inválido no XML e ano inválido na chave. Uma data impossível pode ser recusada antes por validação de estrutura. Por isso, um exemplo genérico que manda editar dhEmi não substitui a identificação do campo e do serviço que realmente retornaram 615.

Particularidades que o suporte deve conferir

No cancelamento por substituição da NFC-e, chNFe identifica o documento do evento, enquanto chNFeRef identifica a substituta. A NT 2018.004 vincula a validação do ano da primeira ao 615 e a da substituta ao 910. São referências distintas.

Um catálogo antigo da NT 2015.001 v1.30 ainda apresenta “Ano < 05”, mas suas regras operacionais P11 usam “Ano < 06”. O valor 05 do catálogo não deve ser tratado como nova faixa permitida. Documentação histórica precisa ser confrontada com o corpo aplicável.

Consultas públicas por QR Code também têm mensagens próprias. Os manuais da NFC-e e do DANFE Simplificado Tipo 2 não transferem automaticamente 615 para a página aberta pelo consumidor. A adaptação ao CNPJ alfanumérico mantém 44 posições na chave; ela não muda a finalidade do bloco AAMM.

Fontes e escopo

Base oficial preservada: MOC 7.0; NT 2014.002 v1.40; NT 2015.001 v1.30; contratos de eventos, com revisão em 10/10/2026. Não houve teste de todos os autorizadores.

Apoio lido: Oobj e Berga, dedicados ao ano; Omie, contexto de diagnóstico técnico do bloco de data, não artigo específico de 615. Instruções de alteração automática da data não foram generalizadas.