Rejeição 485: como investigar a duplicidade de numeração do EPEC

A rejeição 485 indica que já existe EPEC para a combinação de identificação fiscal consultada pelo serviço. Isso não significa que duas vendas ocorreram, que a nota completa já foi autorizada ou que o registro encontrado corresponde exatamente ao XML que o sistema está tentando reenviar.

Antes de agir, a empresa precisa localizar o evento anterior e confrontá-lo com a operação. O objetivo é descobrir se houve repetição de uma tentativa, perda do retorno ou conflito de numeração. Trocar o número para fazer a mensagem desaparecer pode deixar o EPEC original pendente e criar outro problema fiscal.

O que significa “mesma numeração”

Na NF-e modelo 55, a regra 3P12-10 da NT 2014.001 v1.41, página 12, consulta o banco de eventos considerando o tipo 110140, modelo 55, UF, CNPJ ou CPF do emitente, série e número da NF-e. Se encontra EPEC para essa numeração, prevê a rejeição 485.

A expressão “chave natural” descreve essa identidade do documento por modelo, UF, emitente, série e número. Ela é diferente da chave de acesso completa. O ano e mês, o código numérico e o tipo de emissão presentes na chave de acesso não fazem parte da combinação descrita nessa consulta de duplicidade do EPEC.

Por isso, produzir outra chave de acesso não torna livre uma identidade natural já usada. O mesmo vale para uma tentativa feita em outro dia: a data diferente não elimina o registro anterior.

CNPJ, CPF, série e modelo não são intercambiáveis

O CNPJ da identidade natural é o do estabelecimento emitente; não basta conferir apenas a raiz comum entre matriz e filiais. Quando o ramo admite pessoa física, deve ser considerado o CPF do emitente efetivo, dentro das regras aplicáveis ao serviço. O documento do destinatário não substitui essa identificação.

Duas notas com o mesmo número podem pertencer a séries, estabelecimentos ou modelos diferentes. Isso explica por que pesquisar apenas “nota 150” no ERP é insuficiente. Não autoriza mudar série, modelo ou emitente para escapar da rejeição: esses campos precisam representar a operação e o cadastro corretos.

Confira ainda o ambiente. Uma resposta obtida em homologação não comprova registro em produção. Preserve essa informação junto aos XMLs e protocolos para evitar que uma pesquisa no ambiente errado seja interpretada como ausência do evento.

O ramo da NFC-e exige conferência própria

A NT NFC-e 2014.003 v1.02, página 12, contém sua própria regra 3P12-10: modelo 65, evento 110140, UF, CNPJ emitente, série e número da NFC-e. Sua implementação depende da UF; não se deve transportar automaticamente o fluxo nacional da NF-e 55 para a NFC-e.

Há também uma diferença importante no CPF. A especificação preservada do EPEC 65 mantém restrição ao autor pessoa física. A ampliação de CPF no serviço de autorização da NFC-e pela NT 2023.002 não comprova, sozinha, compatibilidade no serviço EPEC. Esse caso requer confirmação específica antes de qualquer orientação operacional.

A disponibilidade precisa ser verificada separadamente. São Paulo condiciona a ativação do EPEC da NFC-e em produção à indisponibilidade da autorização normal. Para NF-e 55, a NT 2014.001 v1.41 registra restrição a emitentes de PR e PB, com produção prevista em 05/10/2026. O cronograma é documental, não prova universal de implantação; tampouco elimina a necessidade de tratar EPECs anteriormente registrados.

Reconcilie a operação antes de reenviar

1. Guarde a tentativa rejeitada. Separe XML do EPEC, XML da nota, retorno completo, data e hora reais, modelo, UF e ambiente. Evite apagar registros locais ou deixar uma fila insistir indefinidamente.

2. Localize o evento anterior. Pesquise pelos componentes completos da identidade natural nos controles do emissor e nas consultas disponibilizadas pelo serviço competente. Recupere chave, protocolo e resultado individual do registro.

3. Compare o conteúdo. Verifique se o evento encontrado pertence à mesma operação e se os dados da nota são compatíveis. Coincidência de número não dispensa comparação de chave, emitente e demais informações.

4. Consulte a situação da nota completa. Ela pode ainda aguardar autorização ou já ter um resultado que o ERP não incorporou. Recuperar esse resultado é diferente de emitir outra nota.

5. Escolha o encaminhamento documentado. Se o registro anterior é válido e corresponde à operação, prossiga com a regularização daquela mesma nota, respeitando o procedimento aplicável. Se há conflito, reúna as evidências para análise fiscal e técnica antes de transmitir novamente.

Um exemplo de retorno perdido

Um sistema envia o EPEC, perde o retorno e, numa tentativa posterior, recebe 485. A primeira transmissão pode ter sido registrada, mas é preciso comparar os arquivos. A nova tentativa pode estar usando uma chave diferente para a mesma identidade natural, por exemplo por falha de geração. Isso é hipótese de diagnóstico, nunca orientação para alterar a chave.

Na NF-e 55, repetir exatamente o evento também pode encontrar a validação 3P15-10, que retorna 573 por duplicidade de tipo de evento, chave de acesso e sequência. Essa conferência difere da 485, baseada na numeração. Portanto, timeout sozinho não explica qual validação foi acionada.

O responsável deve recuperar o retorno anterior ou a consulta correspondente e confirmar a associação com a nota. Nas especificações EPEC, o processamento do lote com cStat 128 exige leitura do resultado de cada evento. O 136 registra o evento ainda sem vínculo com a nota completa; o 124 aparece na consulta quando existe EPEC autorizado. Esses estados não equivalem à autorização final da nota.

Se a pesquisa mostrar outro documento usando a mesma identidade natural, o caso deixa de ser simples recuperação de retorno. Pode envolver filas concorrentes, restauração de dados ou erro no controle de sequência. Essas são hipóteses a testar com os registros, não conclusões automáticas da rejeição.

Evite transformar um conflito em outro

A 485 trata de EPEC já existente. A 661 verifica nota existente para o número informado, e a 662 trata de numeração inutilizada. São consultas distintas previstas nas duas especificações. Ler a mensagem completa evita aplicar a solução de uma à outra.

EPEC autorizado não pode ser simplesmente cancelado nem sua numeração tratada como disponível para inutilização. Apagar a linha do ERP não remove o registro fiscal. Também não se deve alterar data, código numérico ou tipo de emissão para contornar a conferência.

Mantenha a sequência controlada por emitente, modelo e série, preservando vínculos entre evento, documento e protocolo após migrações ou restaurações. O caso estará resolvido quando a identidade encontrada corresponder à operação real, com o resultado fiscal registrado e a pendência de conciliação tratada.

Um cuidado com arquivos antigos

No Manual de Contingência de março de 2009, o código 485 descrevia chave de acesso já existente no cadastro da antiga DPEC. Essa referência histórica não substitui a identidade natural definida para o EPEC. Ao revisar retornos antigos, identifique serviço, versão e mensagem completa; não trate DPEC como alternativa operacional atual.

Fontes e limites da análise

Revisão documental em 10/10/2026, com PDFs oficiais preservados em 09/10/2026: NT 2014.001 v1.41, de agosto de 2026, e NT NFC-e 2014.003 v1.02, de janeiro de 2015. Foram lidos Berga.App, sobre a 485, Oobj, sobre emissão EPEC e TecnoSpeed, sobre contingência EPEC. Os dois últimos são guias contextuais para fluxo, protocolo e conciliação. Orientações genéricas de usar outro número não foram adotadas como solução para a 485.