Rejeição 577 — A data do evento não pode ser menor que a data de emissão da NF-e
Motivo da rejeição
A data do evento não pode ser menor que a data de emissão da NF-e
O que é esta rejeição?#
A Rejeição 577 é 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: A data do evento não pode ser menor que a data de emissão da NF-e.
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 viola a sequência cronológica obrigatória: ajuste dhSaiEnt para valor igual ou posterior a dhEmi, garantindo que ambos os campos usem o mesmo offset de fuso horário.
- Se tpEmis for diferente de 1 (contingência ativa como DPEC, SVC-AN, SVC-RS ou offline) e dhEmi contiver offset UTC divergente do fuso horário da UF do emitente informada em emit/enderEmit/UF, então o horário local interpretado pela SEFAZ difere do horário real de emissão: normalize o offset para o fuso oficial da UF emissora, aplicando -03:00 para horário de Brasília ou -04:00 para estados do Acre/Amazonas conforme aplicável.
- Se tpEmis indicar emissão em contingência (valores 2, 3, 4, 5, 6 ou 7) e o campo dhCont ou xJust estiver ausente ou dhCont for posterior a dhEmi, então o evento de contingência carece de referência temporal válida que justifique a data de emissão retroativa: preencha dhCont com o instante em que ocorreu a entrada em contingência, necessariamente anterior ou igual a dhEmi, e forneça xJust com justificativa mínima de 15 caracteres.
- Se dhEmi e dhSaiEnt estiverem em datas de dias diferentes e o CFOP do primeiro item iniciar com dígito 1 ou 2 (operação de entrada), mas tpNF for igual a 1 (saída), então há contradição entre o tipo de operação declarado e os CFOPs utilizados, o que pode ampliar a diferença temporal interpretada pela SEFAZ ao validar o evento: corrija tpNF para 0 (entrada) ou substitua os CFOPs por códigos iniciados em 5 ou 6 conforme a natureza real da operação.
- Se o campo dhRecbto do protocolo de autorização anterior (em caso de NF-e complementar com finNFe=2 ou de ajuste com finNFe=3) referenciada em NFref for mais recente que dhEmi da NF-e atual, então a nota referenciada foi autorizada após a data de emissão da nota em questão, tornando a referência temporalmente incoerente: verifique a chave de acesso informada em NFref e ajuste dhEmi para momento posterior à autorização da nota referenciada.
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 →