Rejeição 616 — Chave de Acesso inválida (Mês menor que 1 ou Mês maior que 12)

O que é esta rejeição?#

A Rejeição 616 é retornada pela SEFAZ durante a validação da NF-e quando há uma inconsistência relacionada a chave de acesso que identifica unicamente a NF-e, dígito verificador calculado a partir da chave de acesso. Isso significa que a nota fiscal não foi autorizada e precisa ser corrigida antes de ser retransmitida.

Este código indica que rejeição: Chave de Acesso inválida (Mês < 1 ou Mês > 12).

Os campos afetados estão na seção de chave de acesso, identificação da NF-e do XML.

Campos XML relacionados#

Esta rejeição está associada aos seguintes campos do XML da NF-e. Verifique cada um deles ao diagnosticar o problema:

Causas comuns#

• O dígito verificador da chave de acesso está incorreto
• A chave de acesso tem formato inválido (deve ter exatamente 44 dígitos)
• Os componentes da chave (UF, data, CNPJ, modelo, série, número) não correspondem aos dados da NF-e
• O código numérico aleatório (cNF) está ausente ou com formato incorreto

Como resolver#

1. Recalcule o dígito verificador usando o algoritmo módulo 11 conforme especificação da SEFAZ
2. Verifique se todos os componentes da chave de acesso correspondem aos dados informados na NF-e
3. Confirme que a chave tem exatamente 44 dígitos numéricos, sem espaços ou caracteres especiais
4. Regenere a chave de acesso completa no seu sistema emissor e retransmita

Verificações analíticas#

• Se o campo cMunFG extraído da chave de acesso não corresponder ao cMunFG declarado no elemento ide do XML, então o município gerador da obrigação foi codificado incorretamente na chave, distorcendo os dígitos posicionais do mês: recompose a chave de acesso usando os bytes de cMunFG do próprio ide e recalcule o DV módulo 11.
• Se o valor numérico extraído da posição 3-4 da chave de acesso (representando o mês AAMM) divergir do mês contido em dhEmi no elemento ide, então a data de emissão foi serializada na chave em formato incorreto (ex.: dia e mês trocados, ou ano com quatro dígitos em vez de dois): extraia apenas AAMM de dhEmi, posicione-o nos bytes 3-6 da chave e regenere o dígito verificador.
• Se a UF de emissão codificada nos dois primeiros dígitos da chave de acesso não coincidir com o cUF declarado no ide e com o código de UF do endereço do emitente em emit/enderEmit/UF, então houve divergência tripla de origem que invalida toda a sequência posicional da chave: unifique cUF, UF do endereço e o prefixo da chave usando a tabela de códigos IBGE de UF antes de regenerar.
• Se o CNPJ do emitente presente nos bytes 7-20 da chave de acesso não for idêntico ao CNPJ declarado em emit/CNPJ (incluindo zeros à esquerda suprimidos), então o emissor preencheu o campo com CPF ou com CNPJ sem padding, deslocando todos os componentes subsequentes (modelo, série, nNF, cNF) e tornando o cálculo do DV inválido: normalize o CNPJ para 14 dígitos com zeros à esquerda e reconstrua a chave integralmente.
• Se o código numérico aleatório cNF declarado no ide não coincidir com os bytes 36-43 da chave de acesso, e ao mesmo tempo o dígito verificador calculado sobre a chave atual resultar em valor diferente do byte 44, então o cNF foi gerado após a montagem da chave ou foi alterado no XML sem atualizar a chave: regenere cNF antes de compor a chave, recalcule o DV módulo 11 sobre todos os 43 dígitos anteriores e atualize simultaneamente ide/cNF e ide/cDV.