Rejeição 558 — Data de entrada em contingência posterior a data de recebimento.

O que é esta rejeição?#

A Rejeição 558 é 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 em contingência posterior a data de emissão.

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:

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#

1. Ajuste a data/hora de emissão para o momento atual, dentro do prazo aceito pela SEFAZ
2. Use o formato correto com fuso horário: AAAA-MM-DDThh:mm:ss-03:00 (horário de Brasília)
3. Verifique se o relógio do servidor/computador emissor está sincronizado (use NTP)
4. A SEFAZ geralmente aceita NF-e com até 30 minutos de diferença do horário do servidor

Verificações analíticas#

• Se tpEmis for diferente de 1 (contingência ativa, ex: tpEmis=2,3,4,5,6,7) e dhCont estiver preenchida com valor posterior ao dhRecbto retornado pela SEFAZ na resposta de autorização, então a janela de contingência declarada ultrapassa o momento de recebimento, violando a regra de que o início da contingência deve ser anterior ao instante em que a SEFAZ processou o documento: corrija dhCont para refletir o instante real em que o sistema entrou em contingência, garantindo que dhCont < dhRecbto.
• Se dhSaiEnt estiver preenchida e seu valor for anterior a dhEmi (ignorando fuso horário após normalização para UTC), então a nota declara saída ou entrada antes de ter sido emitida, o que é semanticamente impossível e causa rejeição: ajuste dhSaiEnt para um instante igual ou posterior a dhEmi, respeitando o fuso correto -03:00 ou o offset real do estabelecimento emitente.
• Se tpEmis for diferente de 1 e a diferença entre dhEmi e dhRecbto for superior a 168 horas (7 dias) para contingência offline (tpEmis=5) ou superior a 24 horas para contingência em formulário de segurança (tpEmis=4), então a transmissão ocorreu fora do prazo legal de retorno da contingência: reemita o documento com dhEmi atualizada ou verifique se a NF-e deveria ter sido cancelada antes do prazo expirar.
• Se tpEmis for igual a 1 (emissão normal, sem contingência) e o campo dhCont estiver presente e preenchido no XML, então existe contradição estrutural entre o modo de emissão declarado e a presença de data de contingência, podendo causar rejeição por inconsistência de campos: remova o elemento dhCont e o elemento xJust do bloco ide quando tpEmis=1, pois esses campos são exclusivos de operações em contingência.
• Se o offset de fuso horário embutido em dhEmi ou dhSaiEnt for diferente do offset esperado para a UF do emitente (ex: cUF correspondente a estado no horário de Brasília usando -02:00 em período de horário de verão não vigente, ou -04:00 fora de qualquer regra oficial), então o instante absoluto resultante após conversão UTC diverge do horário real de emissão, podendo colocar dhEmi artificialmente no futuro ou no passado em relação ao dhRecbto da SEFAZ: padronize o offset para -03:00 para estados que seguem BRT sem horário de verão e sincronize o relógio do servidor via NTP antes de gerar o próximo documento.