Rejeição 691: chave da NF-e diferente da chave do EPEC

A rejeição 691 ocorre na autorização da NF-e quando sua chave de acesso difere da chave do EPEC encontrado para a identificação consultada. Recupere o evento registrado e o arquivo da nota que lhe deu origem antes de regenerar qualquer informação. Criar outra chave aleatória pode manter a divergência e dificultar a conciliação.

A mensagem pode apresentar a chave do EPEC entre colchetes. Guarde a resposta completa, o XML enviado e os protocolos anteriores. O retorno rejeita aquela tentativa de autorização; ele não permite concluir que inexista outro documento autorizado, que a numeração esteja disponível ou que um EPEC anterior tenha sido cancelado.

O que a regra compara

A regra 2AB08-20 consta como obrigatória para o modelo 55 na NT 2014.001 versão 1.41, página 16, e no MOC 7.0, Anexo I, página 135. Ela integra a consulta à base de eventos EPEC, considerando modelo, UF, CNPJ ou CPF do emitente, série e número. Encontrado o EPEC, a chave da NF-e deve corresponder à chave registrada.

Essa conferência é diferente da rejeição 692, que verifica EPEC existente e tipo de emissão da nota diferente de 4. Também difere da 467, relativa a divergências de dados da nota e do evento. Resolver somente a igualdade das chaves não garante que valores, identificação do destinatário e outras informações estejam corretos.

Não classifique automaticamente a 691 como erro de dígito verificador ou de estrutura do XML. Uma chave pode ter formato válido e ainda identificar algo diferente do EPEC. O diagnóstico precisa confrontar os dois arquivos, em vez de recalcular o dígito sem recuperar os dados originalmente registrados.

Onde costuma surgir a diferença

A chave é formada por informações como UF, ano e mês da emissão, identificação do emitente, modelo, série, número, tipo de emissão e código numérico, além do dígito verificador. Se o emissor recompuser dados de uma nota já preparada, poderá gerar uma chave diferente daquela enviada no EPEC.

Uma hipótese é a integração sortear novamente o código numérico cNF ao reprocessar a nota. Outra é substituir a data de emissão pela data do reenvio. Também pode haver recuperação do arquivo errado ou alteração do tipo de emissão quando o sistema retorna à operação normal. Essas hipóteses precisam de evidência; não são causas comprovadas apenas pelo código 691.

Como conferir e corrigir

1. Identifique a tentativa rejeitada. Confira cStat, xMotivo, modelo, UF, ambiente e serviço. Separe a chave apresentada na resposta daquela utilizada na nota transmitida. Produção e homologação possuem contextos distintos; um protocolo de teste não comprova registro no ambiente de produção.

2. Recupere o EPEC e a nota original. Localize o evento registrado, sua chave e protocolo, além do XML da NF-e preparado para a contingência. Use o histórico do emissor e a consulta oficial pertinente. Falha de comunicação ou consulta indisponível não demonstram ausência de registro.

3. Compare os componentes das chaves. Verifique os dados da NF-e e a identificação contida em infEvento/chNFe do EPEC. Localize exatamente o que mudou: data, tipo de emissão, código numérico ou associação do arquivo, por exemplo. Não copie apenas a chave para um campo ignorando os demais dados e identificadores do documento.

4. Corrija a origem da divergência. Quando o evento representar corretamente a operação e o arquivo original estiver íntegro, recupere o documento correspondente para o fluxo de autorização. Se uma integração alterou os dados, o suporte deve corrigir sua geração com base nos registros verdadeiros. A orientação é manter a correspondência exigida, não inventar valores para coincidir com uma chave.

5. Confira a situação fiscal antes de transmitir. Verifique se houve autorização, cancelamento, outra tentativa pendente ou conflito de registros. Não modifique uma NF-e já autorizada nem edite manualmente um XML assinado. Depois da correção cabível, o emissor deve produzir o arquivo consistente e assinado, e a equipe deve conferir o retorno efetivo da autorização.

Exemplo de investigação

Uma empresa registra um EPEC a partir de uma NF-e preparada em contingência. Ao enviar a nota completa, a integração recria o cNF, embora mantenha emitente, série e número. A chave resultante muda e a autorização retorna 691. Os arquivos demonstram que o evento corresponde à operação e que o código numérico foi alterado no reprocessamento.

A equipe recupera os dados do documento que originou o EPEC e corrige a rotina que gerava outro código. Ela não sorteia um terceiro valor, não muda a numeração para ocultar o vínculo e não altera a emissão para a data atual. O exemplo não contém uma chave pronta para copiar; a solução depende dos arquivos e da situação real da nota.

Limites de uso e pendências

As duas fontes primárias conferidas em 16/10/2026 indicam modelo 55 para esta regra. As marcações 55/65 de linhas vizinhas do MOC não ampliam seu alcance. Para NFC-e ou outros documentos, confirme a documentação própria e o serviço que devolveu a mensagem. A emissão offline e o DANFE Simplificado Tipo 2 não substituem a relação com um EPEC já registrado.

A versão 1.41 também contém restrições para novos EPECs de contribuintes do Paraná e da Paraíba e para séries de PAA. As condições de UF, ambiente e período devem ser observadas. As datas históricas de desativação do DPEC aparecem em outra verificação, a 468; não são uma dispensa geral da comparação exigida pela 691.

EPEC registrado não equivale à autorização da NF-e completa. A NT descreve o retorno 136 para o evento e a necessidade de autorização e conciliação posteriores; não prevê cancelamento direto de EPEC autorizado. Trocar a série ou emitir outra nota não elimina automaticamente o evento pendente.

Se o documento original não puder ser recuperado ou houver registros incompatíveis, encaminhe as duas chaves, os XMLs, protocolos, ambiente e cronologia ao suporte e ao responsável fiscal. A NT contempla situações excepcionais de sincronização que dependem de análise da SEFAZ. Não transforme essa possibilidade em promessa de liberação, nem trate uma nova emissão como solução automática para a pendência anterior.

Fontes

Conferência em 16/10/2026: NT 2014.001 v1.41, especialmente páginas 5–8 e 11–18; MOC 7.0 — Anexo I, página 135, recapturado nesta pesquisa; e MOC 7.0 — Visão Geral, página 19, para a composição da chave. A NT 2026.002 v1.11, página 7, foi confrontada para distinguir modalidades.

Três textos específicos foram lidos: Berga, FiscalAPI e FideFlow. Foram descartadas geração de novo código aleatório como solução, troca automática de numeração e garantias de funcionamento. Não houve consulta de documento real, transmissão, validação de XML ou teste no ALRA.