Rejeição 616: confira o mês da chave de acesso enviada

A rejeição 616, “Chave de Acesso inválida (Mês menor que 1 ou Mês maior que 12)”, indica que o mês embutido na chave enviada não está na faixa permitida. A solução começa pela recuperação da chave completa do documento original. Escolher um mês válido ao acaso pode produzir outra identificação sem corrigir a solicitação.

Antes de alterar qualquer data, descubra se o retorno veio de consulta de situação, distribuição de documento ou evento. A chave pode pertencer a uma nota já autorizada, cuja emissão deve permanecer preservada.

O mês ocupa as posições 5 e 6

A composição documentada no MOC 7.0, Visão Geral, página 19, começa com dois caracteres de UF, dois de ano e dois de mês. Contando a primeira posição como 1, o mês está nas posições 5 e 6. Isso evita o erro de procurar esse componente nas posições 4 e 5.

A faixa é de 01 a 12. Valores como 00 e 13 são inválidos. O mês analisado é o da emissão do documento identificado pela chave, não o da entrega da mercadoria, da importação no ERP ou do evento que está sendo registrado.

Um mês dentro da faixa não prova que a chave pertence à nota certa. Novembro é um mês válido mesmo quando a operação procurada ocorreu em março. Nesse caso, a investigação é de correspondência com o documento e, eventualmente, com a base da SEFAZ, não apenas de faixa numérica.

Serviços em que a regra aparece

Na consulta de situação NfeConsultaProtocolo, J02d retorna 616. O MOC, página 83, documenta esse contrato para chaves dos modelos 55 e 65. Na distribuição de NF-e, H10 com nota de rodapé 2 restringe a verificação a consChNFe, a consulta pela chave; não se aplica indistintamente às consultas por NSU.

Nos eventos, P12-22 examina chNFe, a chave à qual o evento se vincula. A documentação inclui EPEC da NF-e, manifestação, comprovante e insucesso de entrega, ECONF e outros contratos. Prorrogação de industrialização usa P11 para a mesma faixa do mês.

O evento Ator Interessado tem uma condição importante: na NT 2020.007 v1.40, a regra marcada com a nota correspondente aplica-se a tpAutor=1, empresa emitente. As regras de outros autores não devem ser deduzidas por analogia.

Há ainda contratos próprios de NFC-e, como EPEC e cancelamento por substituição. Eles não tornam todo evento disponível em qualquer UF, ambiente ou perfil de emitente. O suporte deve identificar o contrato antes de reaproveitar uma correção feita para NF-e modelo 55.

Como localizar a origem do erro

Comece pelo XML da solicitação que recebeu o retorno. Se a empresa só dispõe da mensagem resumida na tela, solicite o arquivo transmitido e a resposta completa ao fornecedor do sistema. A data mostrada no painel pode estar correta enquanto a chave enviada foi montada com outro valor.

Depois compare com o XML original e seu protocolo. Confira emitente, modelo, série e número. Se a chave veio de imagem, planilha ou digitação, observe o comprimento total e a posição dos componentes. Uma perda de caractere pode deslocar a leitura do mês.

Não trate a chave como número para fazer essa comparação. Ela é uma identificação de 44 posições. Integrações devem preservar zeros e caracteres, inclusive os previstos na adaptação ao CNPJ alfanumérico, sem aplicar filtros que modifiquem a sequência.

Passos para a correção segura

1. Guarde o retorno com cStat, xMotivo, horário, ambiente e serviço. Se for evento, registre tipo, autor e chave vinculada.

2. Localize o documento correto e preserve seu XML, protocolo e histórico de tentativas. Se houve falta de resposta, confira o que já foi processado antes de retransmitir.

3. Compare a chave integral do documento com a da solicitação. Confirme especificamente o mês nas posições 5 e 6.

4. Repare o campo ou vínculo da solicitação rejeitada com a chave autêntica. Não substitua apenas 00 por 01 ou 13 por 12.

5. Deixe o emissor gerar a nova mensagem e a assinatura pertinente. Em consulta, refaça a chamada correta; em evento, confira também se continua cabível registrá-lo.

6. Leia a resposta final e guarde o resultado. O processamento de um lote não equivale à aceitação de todos os eventos que ele contém.

Se a inconsistência estiver numa nota ainda não autorizada, o sistema pode precisar corrigir a data real da emissão e gerar novamente o documento. Essa conclusão exige confirmar o estado anterior. Não é a mesma operação que editar o XML de uma nota já autorizada para acomodar uma consulta.

Exemplo: mês convertido na integração

Uma empresa recebe uma nota emitida em março. O arquivo original contém mês 03, mas uma rotina local passa à consulta uma chave com mês 30, depois de interpretar um campo de data de maneira inadequada. A SEFAZ responde 616.

O responsável recupera a chave completa do arquivo original e encaminha a diferença ao suporte. A consulta deve usar aquela sequência autêntica; a correção permanente está na rotina que produziu a inversão. Alterar a data do recebimento da mercadoria para março não repara o parâmetro enviado.

Se o erro atingir várias notas importadas pela mesma rotina, separe os registros afetados e valide a correção antes de liberá-los novamente. Isso reduz a chance de repetir o problema em consultas e eventos posteriores.

Rejeições próximas não são equivalentes

A 615 verifica o ano. A 524 trata de ano e mês em campos de documentos referenciados durante autorização. A 526 trata de antiguidade da consulta. Nenhuma delas autoriza “atualizar” uma chave de documento antigo.

A 561 compara o mês informado na chave consultada com o mês existente na base de dados. Portanto, mês fora de 01–12 e mês válido que diverge do registro são situações distintas. Já 502 e 572 examinam composições de identificadores em seus respectivos contratos.

No cancelamento por substituição, a NT 2018.004 separa chNFe, a chave do documento do evento, de chNFeRef, a substituta. A primeira possui P12-22/616; o mês inválido da substituta está no conjunto P31/910. Preserve a identificação correta de cada documento.

Os QR Codes públicos de NF-e e NFC-e têm tabelas próprias. Uma mensagem exibida ao consumidor deve ser diagnosticada nesse contrato, sem presumir 616. Da mesma forma, não recrie cabeçalho SOAP antigo nem mude cOrgao para corrigir um mês dentro de chNFe.

Fontes e escopo

Base oficial preservada: MOC 7.0; NT 2014.002 v1.40; contratos específicos de eventos; NT 2026.004 v1.01. Revisão documental em 10/10/2026, sem certificação de ativação universal.

Apoio lido: Oobj e Omie, específicos de 616; Berga, contexto de composição e recuperação da chave. A indicação prática de posições 4 e 5 foi descartada após confronto com a composição oficial.