Rejeição 661: NF-e já existente para o número do EPEC informado

A rejeição 661 indica que, ao receber um pedido de EPEC, o ambiente encontrou uma NF-e já existente para a identificação consultada. Antes de reenviar ou trocar a numeração, consulte o documento e recupere seu retorno oficial. A mensagem rejeita aquele evento; ela não substitui o protocolo nem confirma, sozinha, a situação atual da nota ou a regularidade da operação.

Este guia trata do Evento Prévio de Emissão em Contingência da NF-e, modelo 55, evento 110140, conforme a NT 2014.001 versão 1.41. O EPEC registra informações reduzidas da nota, enquanto a autorização de uso da NF-e completa segue seu processamento próprio. Confundir essas etapas pode gerar outra emissão para uma venda que já possui documento fiscal.

O que a regra verifica

A regra 4P12-10 é obrigatória e consulta a base de NF-e usando modelo 55, UF do emitente, CNPJ ou CPF do emitente, série e número da nota. Encontrando NF-e existente para essa combinação, retorna 661. Portanto, “número do EPEC” não significa uma sequência livre que possa ser alterada isoladamente: está relacionado à numeração da NF-e identificada no evento.

O problema pode aparecer após perda da resposta de autorização, envio atrasado de uma fila de contingência ou recuperação de configuração antiga de numeração. Essas são hipóteses de investigação. O retorno, por si só, não identifica qual delas aconteceu nem informa que o documento encontrado pertence à mesma operação comercial que você está tentando registrar.

Também existem rejeições próximas com verificações diferentes. A 485 verifica EPEC já existente para a numeração; a 573 trata de duplicidade do evento; a 662 verifica número inutilizado. Na autorização da NF-e, 691 e 692 confrontam a chave ou o tipo de emissão com EPEC anterior. Aplique a orientação correspondente ao código e ao serviço efetivamente recebidos.

Confira o alcance antes de corrigir

Em 16 de outubro de 2026, a versão 1.41 mantém a regra 661 para o modelo 55. Não aplique automaticamente este roteiro à NFC-e: o uso de EPEC nesse modelo depende de documentação e decisão da UF. A NT 2026.002 versão 1.11 também distingue EPEC da emissão offline; DANFE Simplificado Tipo 2 não transforma os dois procedimentos em um único serviço.

Há ainda uma restrição territorial importante. O Ajuste SINIEF 25/26 excluiu Paraíba e Paraná da alternativa EPEC da cláusula décima primeira, inciso II, com efeitos em 1º de outubro de 2026. A NT traz a rejeição 121 para essas UFs, com cronograma técnico de 9 de setembro em homologação e 5 de outubro em produção. Essas datas têm funções distintas; não use a diferença como autorização para operar em modalidade vedada.

Como investigar e corrigir

1. Guarde os arquivos e a resposta recebida. Separe o XML do EPEC, o XML da NF-e que o originou, os retornos e os horários de envio. Identifique produção ou homologação. Um lote processado com código 128 pode conter evento rejeitado: leia o resultado individual em retEvento/infEvento, incluindo cStat e xMotivo.

2. Compare a identificação fiscal completa. Confira modelo, UF, emitente, série e número extraídos da chave enviada no evento e confrontados com a NF-e. Verifique também o ambiente e o serviço utilizados. Não limite a análise ao número visível na tela, porque empresas e séries diferentes podem usar o mesmo número sem representar a mesma nota.

3. Consulte a nota existente e recupere seu protocolo. Utilize a consulta oficial ou o recurso de consulta do emissor, no ambiente correto. Se a chave tentada divergir da original, procure a chave correta nos registros de envio e de autorização. O resultado de uma consulta feita com chave incorreta não comprova que a numeração está livre.

4. Relacione o documento à operação. Se a nota estiver autorizada, corresponder à venda e puder ser utilizada conforme sua situação atual, recupere o XML autorizado e regularize o vínculo interno com pedido, financeiro e estoque. Não gere uma segunda nota apenas para eliminar o aviso. Se houver cancelamento, outra operação ou informações incompatíveis, encaminhe a situação ao responsável fiscal antes de decidir nova emissão.

5. Corrija a origem da repetição. Com os registros preservados, o suporte deve revisar filas, resposta perdida, restauração de backup e controle compartilhado da sequência. Uma nova operação que realmente exija documento deve receber numeração disponível, verificada contra notas, inutilizações e eventos já registrados. Alterar apenas o contador não resolve automaticamente a pendência anterior.

Exemplo prático

Uma empresa envia a NF-e de número 4.210, série 1, em emissão normal. A resposta não chega ao emissor. Depois, uma tentativa indevida de EPEC usa a mesma identificação e recebe 661. A consulta recupera a NF-e autorizada, com seu protocolo, e confirma que ela corresponde à mesma venda. O tratamento é recuperar esse documento e corrigir a tentativa indevida, mantendo o histórico.

Esse exemplo não autoriza reaproveitar em contingência o número transmitido em emissão normal: o Ajuste SINIEF 7/05, cláusula décima primeira, § 14, veda esse reaproveitamento. Se a nota encontrada corresponder a outra venda, será necessário resolver a colisão e verificar a necessidade fiscal da nova emissão. A numeração seguinte não pode ser presumida livre apenas porque não aparece na tela local.

O que evitar e quando pedir suporte

Não altere data, emitente, série, código numérico ou tipo de emissão apenas para escapar da comparação. Não inutilize número já utilizado, nem tente cancelar diretamente um EPEC autorizado: a NT distingue sua conciliação dos procedimentos relativos à NF-e. Se já houver EPEC autorizado, preserve a relação com a nota correspondente e encaminhe eventuais inconsistências para tratamento específico.

Quando a consulta não explicar a rejeição, envie ao suporte os XMLs, chave, série, número, UF, ambiente, resposta completa e cronologia. A NT reconhece sincronização entre ambientes; isso justifica conferir os registros, sem prometer que esperar resolverá o caso. O diagnóstico termina com a identificação do documento e do estado fiscal real, além da correção da causa da repetição. Nenhum menu específico ou automatismo do ALRA foi presumido neste guia.

Fontes

Conferência em 16/10/2026: NT 2014.001 v1.41, especialmente páginas 4–8 e 10–17, regra da página 12; MOC 7.0 — Visão Geral, página 116; Ajuste SINIEF 7/05, cláusula décima primeira; e Ajuste SINIEF 25/26. A NT 2026.002 v1.11, página 7, foi usada somente para distinguir modalidades.

Foram confrontados três textos específicos: NS7, Berga e FiscalAPI. Foram descartadas conclusões automáticas sobre autorização, cancelamento direto de EPEC e instruções que confundem serviços. Não houve consulta a documento real, transmissão ou teste no ALRA.