Rejeição 212 — Data de emissão NF-e posterior a data de recebimento

O que é esta rejeição?#

A Rejeição 212 é 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 emissão NF-e posterior a data de recebimento.

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 dhSaiEnt for anterior a dhEmi (comparando os campos ISO 8601 completos incluindo offset UTC), então a data de saída/entrada é logicamente impossível pois um produto não pode sair antes de ser emitido: corrija dhSaiEnt para valor igual ou posterior a dhEmi respeitando o mesmo fuso horário configurado no servidor.
• Se o offset de fuso horário presente em dhEmi diferir do offset presente em dhSaiEnt (por exemplo dhEmi com -03:00 e dhSaiEnt com -00:00 ou Z), então há inconsistência de fuso entre os dois campos de data que pode fazer a SEFAZ calcular uma precedência temporal invertida: padronize ambos os campos para o mesmo offset UTC correspondente à UF do emitente.
• Se tpEmis for igual a 1 (emissão normal, sem contingência) e a diferença entre o horário atual de transmissão e dhEmi ultrapassar 30 minutos em qualquer direção (passado ou futuro), então o instante registrado em dhEmi está fora da janela de tolerância da SEFAZ para emissão em modo normal: sincronize o relógio do servidor via NTP e regenere dhEmi com o timestamp corrente antes de retransmitir.
• Se tpEmis indicar contingência (valores 2, 3, 4, 5, 6 ou 7) e o campo dhCont ou justificativa de contingência estiver ausente ou com dhCont posterior a dhEmi, então a linha do tempo da contingência está inválida pois dhEmi deve ser igual ou posterior ao início da contingência registrado em dhCont: verifique se dhCont reflete o momento real da queda do serviço e se dhEmi foi gerado dentro desse intervalo.
• Se a UF do emitente (endEmit/UF) pertencer a um estado que adota horário de verão e o offset em dhEmi estiver fixo em -03:00 durante um período em que o fuso oficial seria -02:00, ou vice-versa, então o horário absoluto transmitido diverge do horário real do servidor em até 60 minutos, podendo ultrapassar o limite de tolerância da SEFAZ: converta dhEmi para o offset UTC correto vigente na data da operação conforme as regras de horário de verão brasileiras publicadas pelo INMET.