Rejeição 561 — Mês de Emissão informado na Chave de Acesso difere do Mês de Emissão da NF-e
Motivo da rejeição
Mês de Emissão informado na Chave de Acesso difere do Mês de Emissão da NF-e
O que é esta rejeição?#
A Rejeição 561 é 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: Mês de Emissão informado na Chave de Acesso difere do Mês de Emissão d.
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:
| Campo | XPath no XML | Descrição |
|---|---|---|
| chNFe | protNFe/infProt/chNFe | Chave de acesso da NF-e (44 dígitos) |
| cDV | NFe/infNFe/ide/cDV | Dígito verificador da chave de acesso |
| cNF | NFe/infNFe/ide/cNF | Código numérico da NF-e |
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#
- Recalcule o dígito verificador usando o algoritmo módulo 11 conforme especificação da SEFAZ
- Verifique se todos os componentes da chave de acesso correspondem aos dados informados na NF-e
- Confirme que a chave tem exatamente 44 dígitos numéricos, sem espaços ou caracteres especiais
- Regenere a chave de acesso completa no seu sistema emissor e retransmita
Verificações analíticas#
- Se o mês e ano extraídos da posição 3-6 da chave de acesso (cAcesso[2..5]) não corresponderem ao mês e ano de dhEmi no formato AAMM, então há divergência entre a data de emissão codificada na chave e a data declarada no XML: reconstrua a chave de acesso extraindo AAMM diretamente de dhEmi e recalcule o dígito verificador pelo módulo 11.
- Se o cUF posicionado nos dois primeiros dígitos da chave de acesso não corresponder ao código IBGE da UF informada em emit/enderEmit/UF, então a UF do emitente está inconsistente com a chave de acesso: corrija o cUF na chave para o código IBGE correto da UF do emitente antes de recalcular o dígito verificador.
- Se o CNPJ do emitente (emit/CNPJ, 14 dígitos) posicionado nas posições 7-20 da chave de acesso não coincidir numericamente com emit/CNPJ declarado no XML, então o CNPJ codificado na chave pertence a um emitente diferente do informado na NF-e: substitua o bloco CNPJ na chave pelo valor correto de emit/CNPJ e regenere o dígito verificador.
- Se nNF (número da NF-e) formatado com 9 dígitos e posicionado nas posições 27-35 da chave de acesso divergir do valor declarado em ide/nNF, então o número da nota fiscal está inconsistente entre a chave e o corpo do XML: alinhe nNF na chave ao valor de ide/nNF, preservando o cNF original, e recalcule o dígito verificador pelo algoritmo módulo 11 com pesos 2-9 ciclados da direita para a esquerda.
- Se dhEmi contiver um mês válido (01-12) mas o sistema emissor tiver gerado a chave em momento anterior à virada de mês e mantido o cAcesso sem atualização (evidenciado por dhEmi com mês M e chave codificando mês M-1), então a chave foi pré-gerada em mês diferente do mês de emissão efetivo: descarte a chave antiga, gere um novo cNF aleatório de 8 dígitos, construa a chave completa usando o AAMM de dhEmi e recalcule o dígito verificador.
Consulte IEs e CNPJs antes de emitir NF-e
Muitas rejeições acontecem por dados cadastrais desatualizados. Com a FiscalAPI, consulte Inscrições Estaduais e CNPJs em tempo real direto da SEFAZ e Receita Federal.
Criar conta →