Rejeição 558: entrada em contingência com data futura

A rejeição 558 significa que o horário informado para a entrada em contingência ficou depois do recebimento da nota pela SEFAZ, além da tolerância prevista. A primeira providência é conferir o campo dhCont, o fuso e os relógios envolvidos. A correção deve recuperar o momento verdadeiro da ocorrência, sem criar uma data conveniente para a validação.

Esse erro pode parar uma fila inteira quando a origem é o relógio do servidor. Também pode afetar apenas uma nota, por digitação equivocada ou conversão incorreta do horário. Antes de retransmitir, descubra qual desses cenários ocorreu.

Qual comparação produz o código 558

A regra B28-30 do MOC 7.0, Anexo I, página 78 compara a entrada em contingência com a recepção do documento. Ela admite até cinco minutos de tolerância para diferenças de sincronização entre os servidores da empresa e da SEFAZ.

A regra está documentada para NF-e, modelo 55, e NFC-e, modelo 65, no serviço de autorização, com aplicação facultativa. Portanto, o comportamento observado em uma UF não prova que todos os autorizadores estejam configurados da mesma forma. Isso não autoriza informar um horário falso onde a validação não apareça.

Separe três momentos:

• dhCont: início da contingência declarado na nota;

• dhEmi: emissão do documento;

• recebimento: momento registrado pelo autorizador ao receber aquela transmissão.

Para o 558, a referência é o recebimento. Não troque dhEmi por dhCont nem trate a data de saída da mercadoria como substituta de qualquer uma delas.

Os cinco minutos não são um prazo de transmissão

A tolerância absorve um pequeno adiantamento decorrente de sincronização. Ela não exige que toda nota em contingência chegue à SEFAZ até cinco minutos depois do início da falha. O prazo para transmitir ou regularizar o documento é outro assunto, dependente da modalidade e da legislação aplicável.

Por exemplo, uma entrada em contingência às 10h pode anteceder uma transmissão posterior à recuperação do serviço. A diferença, por si só, não produz o 558, que procura uma entrada indicada no futuro em relação à recepção. Outras regras podem avaliar atraso e prazo, e precisam ser verificadas separadamente.

A TecnoSpeed destaca dhCont e a sincronização. Ao aplicar essa orientação, preserve o sentido da comparação oficial: os cinco minutos não são uma janela simétrica obrigatória em torno do recebimento.

Um exemplo de relógio adiantado

Considere uma empresa fictícia cuja nota foi recebida às 14h, mas cujo XML informa entrada em contingência às 15h, no mesmo dia e com o mesmo fuso. Os registros técnicos mostram que a ocorrência começou às 13h50 e que um servidor estava adiantado.

Nesse caso, a equipe deve corrigir a origem do relógio e o dado incorretamente gerado, apoiada no registro da ocorrência. Não deve simplesmente reduzir uma hora em todos os arquivos. Outras notas podem ter sido geradas por máquinas diferentes ou já estar autorizadas.

Também não basta esperar até chegar às 15h. Isso poderia fazer o horário deixar de parecer futuro, mas manteria uma informação falsa sobre o início da contingência. A solução é factual e técnica, não uma espera calculada para contornar a regra.

Fuso horário merece uma conferência própria

Um horário escrito como 14h com deslocamento -03:00 não representa o mesmo instante que 14h com deslocamento -04:00. O final do campo faz parte da informação. Confira se a aplicação preserva corretamente o deslocamento ao converter dados do banco, do servidor ou do terminal.

A Dynamicca recomenda essa leitura conjunta do horário e do UTC. Não aplique o fuso de Brasília indiscriminadamente a todo estabelecimento ou servidor: verifique o local e a data pertinentes, além da forma como o sistema representa o instante.

A documentação da Berga também relaciona o erro a relógio, fuso e digitação. A utilidade prática é investigar essas origens, sem programar antecipadamente uma contingência ou copiar orientações antigas de horário de verão.

Como corrigir a nota e a causa

1. Preserve o XML rejeitado e a resposta completa, com data, ambiente, modelo e autorizador.

2. Consulte a situação da chave e os resultados de tentativas anteriores que ficaram sem resposta.

3. Compare dhCont com a recepção, considerando o deslocamento de fuso de cada registro.

4. Confira os relógios do terminal, do servidor fiscal e do banco de dados, conforme a arquitetura usada.

5. Reconstrua o início real da contingência por logs ou registros do incidente e corrija o dado que estiver errado.

6. Gere novamente o XML pelo emissor, valide, assine e transmita ao destino correto. Confira a resposta individual.

Uma alteração no relógio não corrige necessariamente os documentos já gravados. A equipe técnica precisa verificar se a fila armazena dhCont como valor fixo ou o recalcula no reenvio. Recalcular indiscriminadamente também seria inadequado: a data da contingência não deve virar a data de cada tentativa.

Modelo, versão e modalidade continuam importantes

O MOC contém uma observação histórica para versões inferiores à 3.0, nas quais a hora não era considerada nessa verificação. Ela não é uma licença para ignorar horários nos leiautes atuais.

A validade de dhCont também depende da modalidade. Na emissão normal, tpEmis=1, os dados de contingência não devem ser informados. Nas situações previstas pela B28-20, sua ausência pode levar ao 557. Uma data excessivamente antiga em relação à emissão é assunto do 569.

A NT 2026.002 v1.11 contempla off-line também para NF-e com DANFE Simplificado Tipo 2, nas condições próprias. Isso não generaliza a modalidade para todo modelo 55, nem comprova implantação uniforme por UF. SCAN permanece histórico; SVC e NFC-e têm fluxos distintos.

Encerramento e prevenção

Não crie outra nota nem altere uma já autorizada para resolver o 558. Confirme primeiro a situação fiscal e preserve certificado, ambiente e identificação da operação. Arquive o XML autorizado com seu protocolo quando a regularização terminar.

Para prevenir novas ocorrências, mantenha sincronização confiável, monitore diferenças de horário e teste a conversão de fuso. Registre a entrada em contingência uma única vez por ocorrência real e acompanhe a fila até cada documento ter um resultado conhecido.

Revisão documental por IA: 9 de outubro de 2026. Escopo: autorização de NF-e e NFC-e; o 558 não define o prazo legal de transmissão.