Rejeição 504 — Data de Entrada/Saída posterior ao permitido
Motivo da rejeição
Data de Entrada/Saída posterior ao permitido
O que é esta rejeição?#
A Rejeição 504 é 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 posterior 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 UTC), então a data de saída/entrada é logicamente impossível pois precede a própria emissão do documento: ajuste dhSaiEnt para valor igual ou posterior a dhEmi, respeitando o mesmo fuso horário configurado no servidor emissor.
- Se tpEmis for diferente de 1 (contingência ativa como 2-FS, 3-SCAN, 4-DPEC, 5-FSda, 6-SVC-AN, 7-SVC-RS, 9-OFF) e dhSaiEnt estiver ausente ou nula, então a ausência de data de saída/entrada em emissão normal pode ter sido interpretada pela SEFAZ como data inválida ou fora do prazo: preencha dhSaiEnt com timestamp válido no formato AAAA-MM-DDThh:mm:ss-03:00 coerente com o momento da operação.
- Se o offset de fuso horário embutido em dhEmi ou dhSaiEnt for -00:00, +00:00 ou Z (UTC puro) enquanto o cMunFG ou a UF do emitente pertencer a estado brasileiro fora do fuso de Brasília (ex: Acre com -05:00 ou Amazonas com -04:00 no horário de verão), então o offset declarado diverge do fuso legal da UF de ocorrência do fato gerador: corrija o offset para o valor correspondente ao horário oficial vigente na UF emissora no momento da emissão.
- Se dhEmi convertida para UTC resultar em timestamp superior a dhRecbto da SEFAZ em mais de 30 minutos (ou anterior em mais de 5 minutos, indicando relógio adiantado no servidor emissor), então a NF-e foi transmitida fora da janela de tolerância temporal aceita pela SEFAZ: sincronize o relógio do servidor via NTP com servidor stratum confiável (ex: a.ntp.br) e retransmita com dhEmi recalculada para o instante atual.
- Se tpEmis indicar contingência offline (valores 5, 6 ou 7) e dhEmi estiver além do prazo máximo permitido para regularização pós-contingência (geralmente 168 horas após o início da contingência conforme NT 2013.007), então a NF-e contingenciada foi transmitida fora do prazo legal de retorno ao ambiente normal: verifique o registro de início da contingência, cancele documentos vencidos e reemita com nova dhEmi dentro do prazo regulamentar.
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 →