Rejeição 505 — Data de Entrada/Saída anterior ao permitido
Motivo da rejeição
Data de Entrada/Saída anterior ao permitido
O que é esta rejeição?#
A Rejeição 505 é retornada pela SEFAZ durante a validação da NF-e quando há uma inconsistência relacionada a data e hora de emissão do documento fiscal, informação do documento fiscal. 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: Data de Entrada/Saída anterior ao permitido.
Os campos afetados estão na seção de 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 |
|---|---|---|
| dhEmi | NFe/infNFe/ide/dhEmi | Data e hora de emissão |
| dhSaiEnt | NFe/infNFe/ide/dhSaiEnt | Data e hora de saída/entrada |
| tpAmb | NFe/infNFe/ide/tpAmb | Tipo de ambiente (1=Produção, 2=Homologação) |
Causas comuns#
- A data/hora de emissão está fora do prazo permitido pela SEFAZ
- O fuso horário informado está incorreto (deve seguir o padrão UTC com offset, ex: -03:00)
- A data de emissão é futura ou muito antiga em relação ao momento da transmissão
- A data de saída/entrada é anterior à data de emissão
Como resolver#
- Ajuste a data/hora de emissão para o momento atual, dentro do prazo aceito pela SEFAZ
- Use o formato correto com fuso horário: AAAA-MM-DDThh:mm:ss-03:00 (horário de Brasília)
- Verifique se o relógio do servidor/computador emissor está sincronizado (use NTP)
- A SEFAZ geralmente aceita NF-e com até 30 minutos de diferença do horário do servidor
Verificações analíticas#
- Se dhSaiEnt for anterior a dhEmi (comparando timestamps completos incluindo offset de fuso horário), então a data de saída/entrada viola a sequência lógica obrigatória de eventos da NF-e: ajuste dhSaiEnt para valor igual ou posterior a dhEmi, garantindo que ambos utilizem o mesmo offset UTC-03:00 ou equivalente ao fuso do emitente.
- Se tpEmis for diferente de '1' (emissão normal) e dhEmi não estiver dentro da janela de transmissão permitida para contingência (ex: tpEmis=5 SVC-AN permite até 7 dias, tpEmis=9 off-line até 24h), então o prazo de transmissão pós-contingência foi ultrapassado, invalidando temporalmente o documento: verifique o tipo de emissão utilizado e retransmita dentro do prazo regulamentar correspondente ou emita nova NF-e em modo normal.
- Se o offset de fuso horário presente em dhEmi ou dhSaiEnt não corresponder à UF do emitente (ex: emitente em estado do fuso UTC-04:00 como AM/MT mas offset declarado como -03:00, ou vice-versa), então o timestamp efetivo calculado pela SEFAZ diverge do horário real de emissão, podendo colocar a data fora do prazo aceito: corrija o offset para o valor correspondente ao fuso legal da UF do emitente no momento da emissão, considerando horário de verão quando vigente.
- Se dhEmi contiver uma data em que o campo nNF ou série já foram utilizados em outra NF-e autorizada pelo mesmo emitente (CNPJ/CPF emit + serie + nNF duplicados), e o campo finNFe for '1' (NF-e normal sem referência), então a rejeição de prazo pode estar mascarando uma inconsistência de numeração que forçou reenvio com data alterada: verifique o controle de numeração e, se necessário, avance o nNF para o próximo número disponível mantendo a data atual.
- Se o campo cMunFG referenciar um município cujo código IBGE pertence a UF diferente da UF preenchida em emit/cUF ou dest/UF, e dhSaiEnt for calculado com base em regra de negócio que considera o fuso do município de ocorrência do fato gerador, então o timestamp derivado pode estar deslocado em relação ao fuso esperado pela SEFAZ para validação do prazo: corrija cMunFG para o código de município compatível com a UF do emitente e recalcule dhSaiEnt com o fuso correto.
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 →