Rejeição 692: existe EPEC registrado para esta série e número

A rejeição 692 ocorre quando a autorização encontra um EPEC para a identificação da NF-e e a nota enviada apresenta tipo de emissão diferente de 4. Antes de reenviar, recupere o evento registrado e a nota que o originou. É preciso conferir o vínculo entre eles e a situação fiscal atual, preservando os dados verdadeiros da operação.

A mensagem pode trazer a chave do EPEC entre colchetes. Guarde essa resposta, o XML rejeitado e os protocolos anteriores. O código não significa, por si só, que exista uma NF-e autorizada, que o evento possa ser apagado ou que a numeração esteja disponível para outra operação.

O que a regra verifica

A regra 2AB08-10 aparece 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. Na consulta à base EPEC, a identificação considera modelo, UF, CNPJ ou CPF do emitente, série e número. Encontrado o evento, há rejeição 692 se o campo ide/tpEmis da NF-e for diferente de 4, correspondente à contingência EPEC.

Portanto, transmitir a nota como emissão normal, valor 1, é um caso possível, mas não esgota a condição. A documentação verifica qualquer valor diferente de 4 nesse contexto. A simples existência de EPEC também não basta para explicar a rejeição: o tipo de emissão faz parte do teste.

Isso é diferente da rejeição 691, relacionada à divergência entre as chaves da NF-e e do EPEC, e da 467, referente a divergências de dados. Uma correção do tipo de emissão pode resolver a condição da 692 e ainda revelar outro problema. Nenhuma alteração isolada garante a autorização.

Por que acontece no retorno da contingência

Uma hipótese é o sistema voltar à emissão normal e aplicar essa configuração também às notas anteriormente preparadas em EPEC. Outra é reconstruir uma nota com a mesma série e número, sem recuperar os dados do documento que originou o evento. Essas situações devem ser confirmadas pelos arquivos e registros da integração.

Retomar a emissão normal para novas operações não transforma retroativamente uma nota vinculada ao EPEC em emissão normal. O documento pendente precisa seguir o procedimento correspondente ao evento já registrado. Também não se deve configurar todas as notas como EPEC apenas para tentar eliminar a rejeição.

Como conferir e corrigir

1. Confirme o retorno e seu contexto. Leia cStat e xMotivo completos. Confira modelo, UF, ambiente e serviço. A 692 aqui tratada pertence à autorização da NF-e; não é uma instrução para enviar outro evento EPEC. Protocolos de homologação não demonstram registro em produção.

2. Recupere o evento associado. Localize o XML do EPEC registrado, sua chave e protocolo, além da NF-e preparada originalmente. Confronte emitente, modelo, UF, série e número. Use os registros do emissor e a consulta oficial pertinente; uma consulta indisponível não comprova ausência do evento.

3. Examine o tipo de emissão enviado. Confira ide/tpEmis no XML rejeitado e no documento de origem. Se a integração substituiu o valor da contingência por emissão normal, identifique em que etapa isso aconteceu. A análise deve abranger a geração do arquivo, não apenas a informação exibida na tela.

4. Recupere a nota correspondente ao EPEC. Quando os registros confirmarem que o evento representa corretamente aquela operação, providencie a NF-e consistente com a emissão EPEC e com os dados registrados. O suporte deve preservar a identidade original e corrigir a geração pelo sistema. Não altere manualmente um XML assinado, nem modifique uma nota já autorizada.

5. Verifique a situação fiscal e o resultado. Antes da nova transmissão, confirme se outra tentativa já foi autorizada ou se há conflito de registros. Após o envio cabível, confira o retorno específico da nota e o acompanhamento da conciliação. Se surgir outra rejeição, investigue sua condição própria; repetir o mesmo arquivo não resolve uma divergência persistente.

Exemplo prático

Uma NF-e foi preparada com tipo de emissão 4 e teve seu EPEC registrado. Quando a comunicação com a SEFAZ voltou, uma rotina aplicou tpEmis=1 à nota pendente. A tentativa de autorização encontrou o evento para aquela identificação e retornou 692.

A equipe confronta o EPEC, o arquivo original e o XML transmitido, identificando a mudança indevida. Depois de verificar a situação da nota, corrige a rotina e recupera o documento correspondente à contingência. Também confere chave e demais dados. Não cria outro EPEC, não sorteia um novo código numérico e não presume que o próximo número resolverá a pendência anterior.

Limites e cuidados com o EPEC pendente

As fontes oficiais conferidas em 16/10/2026 apresentam modelo 55 para esta regra. As linhas vizinhas do MOC que abrangem 55/65 não ampliam esse alcance. A emissão offline da NFC-e e o DANFE Simplificado Tipo 2 possuem condições próprias; não devem ser usados como substitutos de um EPEC já registrado para a NF-e.

A versão 1.41 traz restrições para novos EPECs de contribuintes do Paraná e da Paraíba e para séries de PAA. Observe a UF, o ambiente e o período aplicáveis. Essas restrições não autorizam abandonar eventos anteriores. A data histórica de desativação do DPEC pertence à regra 468, sem criar dispensa geral para a 692.

O retorno 136 indica registro do evento sem vínculo com uma NF-e autorizada naquele momento; não equivale à autorização da nota completa. O processamento do lote também precisa ser separado do resultado individual. Preserve as respostas e confirme cada etapa do fluxo.

A NT não prevê cancelamento direto de EPEC autorizado. Se houver desistência da operação ou impossibilidade de recuperar o documento, encaminhe o caso ao responsável fiscal e ao suporte, com os arquivos e a cronologia. A documentação trata procedimentos posteriores e situações excepcionais dependentes da SEFAZ. Trocar a numeração, pedir inutilização ou abandonar o evento não constitui solução automática.

Fontes

Conferência em 16/10/2026: NT 2014.001 v1.41, especialmente páginas 11–18, em captura compartilhada; e MOC 7.0 — Anexo I, página 135, recapturado nesta pesquisa. A NT 2026.002 v1.11, página 7, foi confrontada para distinguir modalidades.

Foram lidos três textos específicos: Berga, Oobj e Omie. Foram descartadas explicações baseadas apenas na existência do EPEC, confusão com divergência de chave ou falha genérica de estrutura, e troca automática de numeração. Não houve consulta individual, transmissão, validação de XML ou teste no ALRA.