Rejeição 635 — NF-e com mesmo número e série já transmitida e aguardando processamento

O que é esta rejeição?#

A Rejeição 635 é 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 com mesmo número e série já transmitida e aguardando processament.

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:

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

Verificações analíticas#

• Se o campo nNF e serie do XML transmitido coincidem com uma consulta retornando cStat 100 para a mesma chave de acesso (cNF + CNPJ emit + mod + serie + nNF + tpEmis + cDV) então a NF-e já está autorizada e o reenvio é redundante: utilize o protocolo nProt e dhRecbto já retornados pela SEFAZ sem gerar novo documento.
• Se tpEmis=1 (emissão normal) e o sistema realizou mais de uma transmissão do mesmo XML sem incrementar nNF, porém dhEmi permanece idêntico entre as tentativas e não há registro de contingência (tpEmis 2 a 9) no histórico de envio, então o loop de reenvio ocorreu por timeout sem controle de idempotência: implemente verificação de chave de acesso no cache local antes de cada transmissão para evitar duplicidade.
• Se finNFe=2 (NF-e complementar) ou finNFe=4 (NF-e de devolução) e o grupo NFref está ausente ou referencia um nNF diferente do documento que motivou a emissão, então a numeração sequencial pode ter sido reutilizada incorretamente ao tentar corrigir a nota anterior: valide que NFref/refNFe aponta para a chave de acesso exata da NF-e de origem antes de incrementar a sequência.
• Se a diferença entre dhSaiEnt e dhEmi for negativa (dhSaiEnt anterior a dhEmi) e tpEmis indicar emissão normal (valor 1), então o sistema pode ter reprocessado um XML com timestamp corrigido manualmente mantendo o mesmo nNF e serie originais: assegure que qualquer correção de data gere obrigatoriamente um novo nNF para evitar colisão de chave na SEFAZ.
• Se cStat 635 foi recebido e a chave de acesso consultada retorna cStat 217 (NF-e não encontrada) na UF do emitente, então a NF-e pode ter sido transmitida para a UF errada em envio anterior — verificar se cUF do campo ide corresponde ao estado do CNPJ do emitente e se o endpoint SOAP utilizado pertence à mesma UF, pois divergência de roteamento pode gerar registro pendente em UF incorreta exigindo cancelamento administrativo junto à SEFAZ destino.