Data de emissão da NF-e muito atrasada em relação ao recebimento pela SEFAZ

A rejeição 228 ocorre quando o campo <dhEmi> da NF-e contém uma data e hora muito anteriores ao momento em que a SEFAZ recebeu o lote. A causa mais comum é o relógio do servidor do emissor desregulado ou um lote que ficou represado sem ser transmitido. Corrija o horário do servidor ou reemita a nota com a data atual antes de retransmitir.

O que significa esta rejeição

A tag <dhEmi> informa a data e hora de emissão da NF-e. Ao receber o lote, a SEFAZ compara esse valor com o instante do recebimento. Se a diferença superar a tolerância definida para sincronismo de relógio (5 minutos para o tipo de emissão Normal, tpEmis = 1), o documento é rejeitado com o código 228.

A rejeição protege a integridade fiscal: uma nota com data muito no passado poderia encobrir operações retroativas não autorizadas. Ao contrário de erros de schema, este erro pode ocorrer mesmo com um XML tecnicamente correto, se o horário do servidor do emissor estiver dessincronizado ou se o lote demorou muito para ser enviado.

Causas mais comuns

• Relógio do servidor ou da estação de trabalho desregulado, com hora muito adiantada no passado em relação à hora real.
• Lote de notas gerado e armazenado localmente por horas ou dias sem ser transmitido, e depois enviado com a data de geração original.
• Emissão em modo offline sem uso de contingência (SVC), onde a nota foi criada quando a internet estava indisponível e transmitida muito depois.
• Fuso horário configurado errado, fazendo com que a data no XML fique horas atrás do horário recebido pela SEFAZ.
• Reenvio de um XML antigo que já havia sido rejeitado por outro motivo, sem atualizar <dhEmi>.

Regra de validação oficial

A regra B09-20 do Anexo I do MOC define que, para NF-e com <tpEmis> = 1 (Normal), 6 (SVC-AN) ou 7 (SVC-RS), o campo <dhEmi> não pode estar muito anterior à data e hora de recebimento pela SEFAZ. A tolerância para diferença de relógio é de 5 minutos. Se a defasagem for maior, a transmissão é rejeitada com o código 228.

Exemplo XML, antes (errado)

<ide>
  <dhEmi>2026-05-20T10:00:00-03:00</dhEmi>
  <tpEmis>1</tpEmis>
</ide>

(nota gerada no dia 20 e transmitida quatro dias depois, no dia 24, sem atualizar a data)

Exemplo XML, depois (correto)

<ide>
  <dhEmi>2026-05-24T14:32:00-03:00</dhEmi>
  <tpEmis>1</tpEmis>
</ide>

(data de emissão compatível com o momento real da transmissão)

Passo a passo para corrigir

1. Verifique o relógio do servidor ou da máquina que emite a nota. Se estiver desregulado, sincronize com um servidor NTP antes de prosseguir.
2. Confira o fuso horário configurado: deve corresponder ao fuso do local de emissão, no formato ±HH:MM.
3. Caso o lote tenha ficado represado, reemita a nota com a data e hora atuais, pois a data original já não é mais válida.
4. Corrija o <dhEmi> no XML para refletir a data e hora da nova emissão.
5. Transmita o lote imediatamente após a correção, para evitar que o mesmo problema se repita.

Como o FazendaNota previne

O FazendaNota usa a data e hora do servidor na emissão de cada NF-e, garantindo que <dhEmi> reflita o instante real da geração do documento. Quando a SEFAZ devolve a rejeição 228, a plataforma identifica que se trata de divergência de horário e orienta a verificar a sincronização do relógio do servidor antes de retransmitir, evitando reenvios repetidos com a mesma data inválida.

Rejeições relacionadas

• Rejeição 219, NF-e com data de emissão posterior à data de recebimento
• Rejeição 320, NF-e transmitida fora do prazo de cancelamento
• Rejeição 252, Prazo de transmissão da NF-e em contingência encerrado

Referência oficial

Esta rejeição está descrita no Anexo I - Leiaute e Regra de Validação do Manual de Orientação do Contribuinte (MOC) v7.0 da NF-e, publicado pelo CONFAZ. Texto integral em https://www.confaz.fazenda.gov.br/legislacao/arquivo-manuais/moc7-visao-geral.pdf