Rejeição 641: XML do emitente ou data do evento de prorrogação

A rejeição 641 exige identificar o serviço que respondeu. No NFeDistribuicaoDFe, significa que a NF-e está indisponível para o próprio emitente. Nos eventos de prorrogação da suspensão do ICMS, indica data anterior à autorizada para aquele evento. As causas e providências são diferentes, embora o número seja igual.

Confira cStat, xMotivo, serviço, ambiente e operação executada. A mensagem apresentada pelo ERP pode resumir o retorno ou usar uma descrição antiga. Um diagnóstico confiável começa pelo XML efetivamente recebido. Os ramos tratados aqui pertencem à NF-e modelo 55, sem extensão automática à NFC-e.

Quando o emitente tenta baixar sua própria NF-e

A H17 da NT 2014.002 v1.40 determina que a NF-e não seja disponibilizada ao emitente e verifica se o CNPJ do interessado é o emissor. Sua mensagem é “NF-e indisponível para o emitente”. A nota de rodapé 2 limita essa validação ao consChNFe, a consulta pontual pela chave.

Na tabela, o “2” sobrescrito não integra o nome da regra: o identificador é H17, não H172. O serviço está recusando essa recuperação do arquivo. O retorno não informa que a nota foi cancelada, que falta autorização de uso ou que a empresa precisa emitir outro documento. NT, página 11.

É comum o problema surgir após troca de ERP, perda de arquivos ou implantação de um capturador. A empresa encontra a chave de uma venda antiga e espera recuperar sua própria emissão da mesma maneira que recupera documentos recebidos. O serviço de distribuição não deve ser tratado como backup irrestrito do emissor.

Onde procurar o XML que foi emitido

Busque primeiro no sistema emissor, na integração que transmitiu a NF-e e nos backups da empresa. Confira também o acervo enviado à contabilidade e outras cópias legitimamente guardadas. Pesquise pela chave completa, pois número e série isolados podem localizar documentos de outro estabelecimento.

Ao recuperar o arquivo, verifique a correspondência da chave, do emitente e da operação. Preserve o XML autorizado, seu protocolo e os eventos pertinentes. Se o material encontrado for apenas um DANFE em PDF, registre que o arquivo eletrônico ainda precisa ser recuperado; não reconstrua assinatura e protocolo a partir da representação impressa.

Adicionar o próprio emitente a uma lista local de autorizados, trocar o CNPJ consultado ou utilizar certificado alheio não corrige a limitação. Também não cabe registrar uma manifestação artificial para tentar liberar uma nota emitida pela própria empresa. Manifestação do destinatário e disponibilidade ao emitente são controles distintos.

Se a empresa afirma estar consultando uma compra, confira qual CNPJ saiu na requisição e quem efetivamente consta como emitente. Uma seleção errada pode ter colocado a consulta no papel equivocado. Corrigir a configuração significa representar a operação verdadeira, sem mudar os participantes do documento já autorizado.

O emitente continua recebendo certos eventos

A restrição ao XML da própria NF-e não exclui o emitente de todo o serviço de distribuição. A matriz da página 5 prevê, por exemplo, respostas do Fisco aos pedidos de prorrogação para o emitente. Esses eventos podem ser distribuídos independentemente da manifestação do destinatário, inclusive quando emitente e destinatário são iguais.

Por isso, desativar toda a captura de DF-e depois de uma 641 pode prejudicar o acompanhamento de respostas fiscais. O sistema deve separar recuperação da própria nota e recebimento dos eventos a que o ator tem acesso. Isso não torna distNSU ou consNSU atalhos para baixar o XML recusado ao emitente. NT, página 5.

O limite temporal é outra questão: no consChNFe, a H15 considera 90 dias desde o recebimento da NF-e no Ambiente Nacional e gera 632. Essa janela não concede ao emitente um direito de download que a H17 exclui.

Quando a 641 trata da data do evento

Na NT 2015.001 v1.30, a regra P12 impede data anterior à data de autorização para o respectivo evento. Ela aparece em três grupos:

• Pedido de prorrogação, tipos 111500 e 111501, página 37

• Cancelamento de pedido, tipos 111502 e 111503, página 46

• Resposta do Fisco, tipos 411500 a 411503, página 54

A redação se refere à autorização para o tipo de evento. Não deve ser substituída automaticamente pela data do protocolo de autorização da NF-e: a comparação com a autorização da nota possui regra distinta, associada à 579. A emissão da NF-e e o horário de processamento também têm verificações próprias, 577 e 578. NT, páginas 37, 46 e 54.

Como tratar a data sem inventar um marco

Peça ao suporte que identifique o tipo de evento, dhEvento, fuso horário, UF e ambiente. Verifique se houve reutilização de um arquivo antigo, data fixa de teste ou conversão incorreta de horário. A referência aplicável à autorização para aquele evento deve ser confirmada com o serviço estadual; a tabela não fornece uma data universal para todos os casos.

Não copie a data de autorização da NF-e para dhEvento por tentativa, nem acrescente minutos até a rejeição desaparecer. Se existe erro de geração, a correção precisa refletir a data real do evento e as condições permitidas. A tolerância de cinco minutos descrita para outra comparação temporal não deve ser transferida automaticamente para a 641.

Se o evento é uma resposta fiscal, o contribuinte não é seu emissor autorizado. Encaminhe a inconsistência ao responsável pela integração ou ao atendimento da Fazenda. Não produza uma resposta 4115xx com o certificado da empresa para consertar a data.

Na prorrogação, também é necessário conferir o fluxo da UF. Minas Gerais exige pedidos completos e um evento por vez. Desde 01/12/2025, novos primeiros pedidos e suas segundas prorrogações seguem o evento eletrônico; se a primeira foi autorizada pela Delegacia antes desse marco, a segunda permanece no Portal de Serviços. Essa transição administrativa não define, por si só, a data técnica comparada em P12.

Quando considerar o problema esclarecido

No ramo de distribuição, encerre a investigação quando a origem do XML estiver identificada ou a limitação de recuperação estiver documentada e encaminhada. No ramo temporal, preserve a evidência da configuração corrigida e o retorno individual do evento. Registro aceito não equivale ao deferimento tributário da prorrogação.

O mesmo código em outro contrato

Há ainda um uso de 641 no NFeRecepcaoRFB, relacionado à verificação da UF do protocolo no compartilhamento entre órgãos públicos. O Manual v2.08, de junho/2024, consultado em 10/10/2026, descreve outro contrato. Esse homônimo não muda o diagnóstico dos dois cenários deste guia nem orienta alterações no ERP. Manual de compartilhamento, páginas 26 e 49.

Fontes práticas e limites

Foram lidos iLoveXML, seção 641, FlexDocs, documentos disponíveis por ator e TOTVS, orientação WinThor 641, além do contexto de eventos TOTVS. A receita WinThor de nova manifestação não foi generalizada para a H17. SEF-MG consultada em 10/10/2026; corpus nacional preservado em 09/10/2026 e relido nesta data.