Pular para o conteúdo
FiscalAPI
661 Autorização/Contingência

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

Motivo da rejeição

NF-e já existente para o número do EPEC informado

4 min de leitura

O que é esta rejeição?#

A Rejeição 661 é retornada pela SEFAZ durante a validação da NF-e quando há uma inconsistência relacionada a número sequencial da NF-e, série de numeração da NF-e. Isso significa que a nota fiscal não foi autorizada e precisa ser corrigida antes de ser retransmitida.

Este código indica que rejeição: NF-e já existente para o número da DPEC informada.

Os campos afetados estão na seção de chave de acesso, dados do emitente, identificação da NF-e do XML.

Campos XML relacionados#

Esta rejeição está associada aos seguintes campos do XML da NF-e. Verifique cada um deles ao diagnosticar o problema:

CampoXPath no XMLDescrição
nNFNFe/infNFe/ide/nNFNúmero da NF-e
serieNFe/infNFe/ide/serieSérie do documento fiscal
CNPJ_emitNFe/infNFe/emit/CNPJCNPJ do emitente
chNFeprotNFe/infProt/chNFeChave de acesso da NF-e (44 dígitos)

Causas comuns#

  • Uma NF-e com o mesmo número, série e CNPJ do emitente já foi autorizada pela SEFAZ
  • Houve reenvio acidental de uma NF-e que já foi processada com sucesso
  • Falha de comunicação fez com que a resposta de autorização não chegasse, levando ao reenvio
  • O sistema emissor está gerando numeração duplicada por erro de configuração

Como resolver#

  1. Consulte a situação da NF-e pela chave de acesso — se já está autorizada, utilize-a normalmente
  2. Se a NF-e original foi autorizada mas a resposta não chegou, faça uma consulta de protocolo
  3. Caso precise emitir uma nova nota, utilize o próximo número sequencial disponível na série
  4. Revise a configuração de numeração automática do seu sistema emissor para evitar duplicidades

💡
Dica: Para identificar a causa desta rejeição, comece verificando os campos nNF, serie, CNPJ_emit, chNFe no XML da NF-e. Compare os valores informados com os dados cadastrais atualizados na SEFAZ e na Receita Federal.

Verificações analíticas#

  • Se o campo nNF do XML atual coincide exatamente com o nNF de uma NF-e previamente protocolada para o mesmo CNPJ emitente (emit/CNPJ) e mesma série (serie), mas o campo dhEmi do XML reenviado é posterior ao dhRecbto registrado no protocolo original, então o sistema emissor realizou reenvio de NF-e já autorizada sem perceber o protocolo anterior: consulte a chave de acesso original via NFeConsultaProtocolo e utilize o XML já autorizado, descartando o reenvio.
  • Se tpEmis indica emissão em contingência (valores 2, 3, 4, 5, 6 ou 7) e o campo nNF do documento é idêntico ao de um EPEC já registrado para o mesmo emit/CNPJ e serie, porém o cDV da chave de acesso calculado sobre os campos do XML atual diverge do cDV da chave do EPEC transmitido anteriormente, então houve alteração de algum campo-chave (como dhEmi ou cNF) após o registro do EPEC, gerando chave inconsistente: reconstrua a chave de acesso exclusivamente com os campos usados no EPEC original e retransmita sem alterações.
  • Se finNFe indica nota complementar ou de ajuste (valores 2 ou 4) e o bloco NFref está ausente ou referencia uma chave de acesso cuja cStat retornada pela SEFAZ não corresponde a uma NF-e autorizada (cStat 100), e simultaneamente o nNF gerado já consta como existente no EPEC, então a nota foi numerada e transmitida sem que a nota de origem estivesse devidamente autorizada, criando duplicidade de número sem vínculo legal válido: autorize primeiro a NF-e referenciada, depois gere novo nNF sequencial para a complementar.
  • Se o campo cNF presente na chave de acesso do XML atual é idêntico ao cNF de outro documento emitido no mesmo dhEmi (mesmo AAMM) pelo mesmo emit/CNPJ e serie, indicando que o gerador de código numérico aleatório produziu valor repetido, e o nNF também coincide, então a colisão simultânea de nNF e cNF confirma erro de sequenciamento no sistema emissor onde o contador não foi incrementado após autorização anterior: redefina o próximo nNF para o valor imediatamente superior ao maior nNF já autorizado na série e regenere cNF com valor aleatório distinto antes de retransmitir.
  • Se tpEmis do XML é igual a 1 (emissão normal, sem contingência) e mesmo assim o motivo de rejeição 661 é retornado referenciando um EPEC, então o documento foi originalmente transmitido em contingência EPEC (tpEmis=4) com determinado nNF, e o sistema emissor posteriormente gerou a versão normal da mesma nota alterando tpEmis para 1 sem incrementar o nNF, tornando as duas versões incompatíveis em chave mas colisoras em número de EPEC: mantenha tpEmis=4 na versão definitiva transmitida após o EPEC, garantindo que a chave de acesso seja idêntica à registrada no EPEC, ou cancele o EPEC e emita com novo nNF em modo normal.
Compartilhar: WhatsApp LinkedIn Twitter

Consulte IEs e CNPJs antes de emitir NF-e

Muitas rejeições acontecem por dados cadastrais desatualizados. Com a FiscalAPI, consulte Inscrições Estaduais e CNPJs em tempo real direto da SEFAZ e Receita Federal.

Criar conta →