Rejeição 485 — Duplicidade de numeração do EPEC (Modelo, CNPJ, Série e Número)
Motivo da rejeição
Duplicidade de numeração do EPEC (Modelo, CNPJ, Série e Número)
O que é esta rejeição?#
A Rejeição 485 é 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: Número DPEC já existe no cadastro de DPEC.
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:
| Campo | XPath no XML | Descrição |
|---|---|---|
| nNF | NFe/infNFe/ide/nNF | Número da NF-e |
| serie | NFe/infNFe/ide/serie | Série do documento fiscal |
| CNPJ_emit | NFe/infNFe/emit/CNPJ | CNPJ do emitente |
| chNFe | protNFe/infProt/chNFe | Chave 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#
- Consulte a situação da NF-e pela chave de acesso — se já está autorizada, utilize-a normalmente
- Se a NF-e original foi autorizada mas a resposta não chegou, faça uma consulta de protocolo
- Caso precise emitir uma nova nota, utilize o próximo número sequencial disponível na série
- Revise a configuração de numeração automática do seu sistema emissor para evitar duplicidades
Verificações analíticas#
- Se o campo nNF do XML submetido coincide com um nNF já presente no histórico de numeração autorizada para o mesmo CNPJ emitente (emit/CNPJ), série (serie) e modelo (mod=55), porém o campo dhEmi difere da nota original em poucos segundos ou minutos, então o sistema emissor realizou reenvio automático com incremento incorreto de timestamp sem avançar o número sequencial: cancele a tentativa de reenvio, consulte o protocolo da chave de acesso original e utilize o nNF imediatamente posterior ao último autorizado.
- Se tpEmis indica contingência (tpEmis=4, 5, 6 ou 7 — EPEC, FS-DA, SCAN ou SVC) e o nNF informado já consta como autorizado em modo normal (tpEmis=1) para o mesmo emit/CNPJ e serie, então houve sobreposição de numeração entre o bloco de contingência e o bloco de operação normal, caracterizando duplicidade estrutural: inutilize o intervalo conflitante via NF-e de inutilização (evento 110111) e sincronize o contador de série da contingência com o próximo número disponível após o maior nNF já autorizado em qualquer modalidade de emissão.
- Se infNFe/ide/nNF e infNFe/ide/serie são idênticos ao de uma NF-e anterior e o campo chNFe calculado (cUF+AAMM+CNPJ+mod+serie+nNF+tpEmis+cNF) resulta na mesma chave de 44 dígitos já registrada na SEFAZ, mas o campo cNF (código numérico aleatório) foi regenerado pelo emissor na tentativa de burlar a duplicidade, então a SEFAZ identifica colisão pela chave completa independente do cNF: não altere cNF para reaproveitar um número já usado, pois a rejeição 485 é disparada pelo conjunto modelo+CNPJ+série+número e não pelo cNF isolado; avance o nNF.
- Se o XML reenviado apresenta dhEmi dentro do mesmo período de competência fiscal (mesmo AAMM) de uma nota já autorizada com igual emit/CNPJ, serie e nNF, e o campo vNF ou qualquer campo de valor difere entre as duas versões, então o emissor tentou corrigir dados alterando o conteúdo sem mudar o número, o que além de gerar a rejeição 485 configura tentativa de substituição indevida de documento fiscal: emita a nota com o próximo nNF correto e, se necessário corrigir a nota original já autorizada, utilize Carta de Correção Eletrônica (evento 110110) ou NF-e de substituição com finNFe=3 referenciando a chave original em NFref.
- Se o campo tpEmis do XML rejeitado for 4 (EPEC) e a SEFAZ retorna especificamente cStat=485 mencionando EPEC, e o sistema emissor não registrou localmente o número de protocolo do EPEC previamente transmitido para esse mesmo nNF/serie/CNPJ, então a ausência de controle de protocolo local causou reenvio do EPEC já aceito: implemente persistência transacional do nProt retornado no momento da autorização do EPEC antes de qualquer retentativa, e consulte a situação atual pela chave de acesso antes de incrementar o número de série.
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 →