Rejeição 903 — Versão informada no QR-Code (“100”) não é mais válida para a data de emissão

O que é esta rejeição?#

A Rejeição 903 é 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.

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 dhEmi contém offset de fuso horário diferente de -03:00 (ou -02:00 em horário de verão vigente) e tpEmis=1 (emissão normal), então o offset UTC declarado diverge do fuso oficial brasileiro e causará rejeição 903: corrija o campo dhEmi para o formato AAAA-MM-DDThh:mm:ss-03:00 garantindo que o horário local convertido corresponda ao instante real de emissão.
• Se dhSaiEnt é anterior a dhEmi em qualquer número de segundos, então a data de saída/entrada precede logicamente a emissão da nota, configurando inconsistência temporal entre campos relacionados: ajuste dhSaiEnt para valor igual ou posterior a dhEmi, respeitando o mesmo padrão de offset de fuso horário.
• Se tpEmis está entre 2 e 9 (contingência) e dhEmi difere em mais de 30 minutos do horário corrente do servidor no momento da transmissão à SEFAZ, então o prazo de retransmissão de NF-e em contingência foi ultrapassado ou o relógio do servidor está dessincronizado: sincronize o relógio via NTP e retransmita dentro do prazo regulatório de contingência aplicável ao tipo informado.
• Se o valor numérico da hora extraído de dhEmi, após conversão para UTC usando o offset declarado no próprio campo, resulta em timestamp futuro superior a 5 minutos ou passado superior a 30 minutos em relação ao instante de transmissão conhecido, então o horário absoluto de emissão está fora da janela de tolerância da SEFAZ independentemente do formato: atualize dhEmi para o instante atual de emissão com offset correto e retransmita imediatamente.
• Se cDV do campo cNF foi calculado sobre uma versão de chave de acesso que inclui dígitos de dhEmi formatados incorretamente (ex: data com separadores ausentes ou mês/dia invertidos), então a chave de acesso gerada será inválida e a SEFAZ pode rejeitar apontando inconsistência de versão ou data: recalcule a chave de acesso completa de 44 dígitos a partir dos campos fonte já corrigidos, incluindo dhEmi no formato AAAAMMdd, e recompute o dígito verificador cDV antes de retransmitir.