Rejeição 561: mês da chave diferente do registro da Sefaz

Ao receber o código 561, confira primeiro se o sistema estava consultando a situação da nota. No Web Service NfeConsultaProtocolo, essa rejeição significa que o mês informado na chave consultada diverge do mês existente no banco da Sefaz. A medida segura é recuperar a chave correta e esclarecer a situação fiscal do documento antes de tentar emitir qualquer outra nota.

Essa distinção evita um erro caro: interpretar uma consulta rejeitada como prova de que a nota nunca foi autorizada. Uma tela do ERP pode reunir transmissão, consulta e atualização de status em um único botão. O momento em que a mensagem aparece não basta para identificar qual serviço a devolveu.

O que a regra oficial realmente compara

A regra J05 da Tabela 5-16 do MOC 7.0, Visão Geral, página 84 compara o campo MM da chave de acesso com o dado existente no banco. Ela consta como obrigatória no serviço de consulta da situação, que contempla NF-e modelo 55 e NFC-e modelo 65.

A solicitação desse serviço utiliza consSitNFe, com a chave em chNFe. Não é um pedido de autorização contendo todos os itens da venda. Antes de J05, o fluxo verifica a estrutura da chave e procura registros por identificação do emitente, modelo, série e número. Há também tratamento de EPEC no processo de busca.

Por isso, a conclusão correta é que a consulta precisa ser reconciliada com o registro fiscal existente. O código 561, isoladamente, não informa que a venda está autorizada, cancelada ou pendente, nem permite liberar novamente sua numeração.

Onde fica o mês na chave

A chave possui 44 posições. As posições 3 a 6 representam ano e mês, no formato AAMM; as posições 5 e 6 são o mês. Esse trecho deve representar a emissão do documento, não o mês em que alguém resolveu consultar sua situação.

Em um exemplo exclusivamente parcial e hipotético, o registro original corresponde a setembro, com MM igual a 09. Uma chave montada localmente para outubro teria MM igual a 10. Os dois meses são números permitidos, mas não representam o mesmo registro. A conferência deve recuperar a chave original inteira, sem construir tentativas com meses diferentes.

Há uma rejeição distinta para mês fora da faixa de 01 a 12: 616, no mesmo serviço. A 561 trata da divergência em relação ao banco, não simplesmente de um mês inexistente no calendário. Ano inválido, DV incorreto e consulta em ambiente errado também têm controles próprios.

Por que o XML local pode parecer correto

É possível que o XML guardado no computador tenha uma data e uma chave coerentes entre si, mas não seja o arquivo que corresponde ao registro da Sefaz. Uma restauração de backup, uma integração incompleta ou uma tentativa reconstruída depois da virada do mês são hipóteses a verificar.

Outra possibilidade é que o programa consulte uma chave armazenada em um campo separado da nota. Nesse caso, olhar somente dhEmi no XML local não revela qual chNFe foi efetivamente enviado na consulta. O suporte precisa comparar a mensagem de consulta com os arquivos e protocolos preservados.

Os guias da TecnoSpeed, da Dynamicca e da Webmania chamam atenção para a coerência entre chave e data. Essa verificação é útil, mas a regra J05 exige acrescentar a comparação com o banco da Sefaz; não basta editar a data local e retransmitir.

Um roteiro seguro de recuperação

1. Guarde o retorno completo, o horário e o nome do serviço chamado. Solicite ao suporte a requisição consSitNFe e a resposta correspondente, se o ERP não as exibir.

2. Confirme produção ou homologação, UF, autorizador e modelo. O ambiente não está codificado na chave; deve estar correto na solicitação e no endereço do serviço.

3. Localize os XMLs e protocolos da emissão original. Confira a chave do documento e, quando houver, a chave registrada em seu protocolo de autorização.

4. Compare essas fontes com chNFe da consulta recusada. Se a consulta utilizou um valor desatualizado, corrija a associação no sistema com base no documento verdadeiro.

5. Consulte novamente usando a chave íntegra e leia a situação devolvida. Só então decida o tratamento operacional, com apoio fiscal se o histórico permanecer inconclusivo.

Se o documento já estiver autorizado, recupere e sincronize esse registro. Não faça uma segunda venda fiscal para resolver a falha de consulta. Se ainda faltar informação suficiente, mantenha o caso pendente de esclarecimento, preservando a numeração até definir seu estado real.

O que não fazer na virada do mês

Não substitua a data de emissão pela data atual só para coincidir com uma chave criada depois. Não tente sequências de meses, não recalcule o DV isoladamente e não sorteie um novo código numérico. Essas medidas fabricam outras chaves, mas não recuperam o documento existente.

Também não conclua que é preciso cancelar ou inutilizar a nota por causa da 561. Esses procedimentos têm finalidades e requisitos próprios. Uma mensagem de consulta não autoriza alterar o estado fiscal do documento.

Para prevenir recorrências, preserve a chave e o XML efetivamente enviados, com os respectivos retornos, e use essa mesma identificação nas consultas posteriores. Registre separadamente data de emissão, transmissão, autorização e consulta para que um processamento posterior não sobrescreva os dados originais.

Atenção às versões atuais

A chave continua com 44 posições, mas pode conter letras legítimas no trecho de CNPJ, conforme a NT 2026.004 v1.01. Isso não muda a posição do mês. Remover letras ou tratar a chave como número inteiro pode corromper a identificação consultada.

Conferência documental: 9 de outubro de 2026. A orientação se refere a J05 de NfeConsultaProtocolo, não a uma regra universal de autorização nem à consulta pública por QR Code. Se o retorno vier de outro serviço, seu contexto precisa ser confirmado antes de aplicar o procedimento.