Rejeição 703: emissão posterior ao recebimento na SEFAZ
Revisão editorial em 15 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.
A Rejeição 703, regra B09-10, indica que a data e hora de emissão estão posteriores ao recebimento pela SEFAZ além da tolerância documentada. A verificação alcança NF-e e NFC-e, modelos 55 e 65. O MOC aceita uma diferença de até cinco minutos por sincronismo entre os relógios do emissor e da SEFAZ; isso não autoriza registrar um horário fictício. MOC 7.0, Anexo I, p. 75.
Quais horários devem ser comparados?
Localize dhEmi no grupo infNFe/ide do XML enviado. O formato inclui data, hora e deslocamento de fuso, como -03:00. Compare o instante representado por esse valor ao horário de recepção do autorizador associado à mesma tentativa. O horário de processamento apresentado no retorno e os logs ajudam a reconstruir a sequência; o relógio atual do computador, sozinho, não reconstitui a tentativa passada.
Uma comparação de texto sem normalizar os fusos pode mostrar uma diferença inexistente. Também verifique se o sistema aplica o deslocamento duas vezes, confunde horário local com UTC ou reaproveita uma data futura armazenada no rascunho. Os formatos estão descritos no MOC, campos B09 e retorno PR08.
Como funciona a tolerância de cinco minutos?
A B09-10 verifica emissão no futuro em relação à recepção. A tolerância cobre até cinco minutos; uma diferença maior satisfaz a condição de rejeição. Não é uma recomendação de emitir adiantado nem uma janela para escolher datas.
Compare isso à 704/B09-40: nessa outra regra, o problema é atraso entre emissão e recepção nos documentos abrangidos. A 703 olha o sentido contrário. Um emissor pode ter falhas de fuso ou fila que produzem sintomas distintos; o código e os horários da tentativa determinam o diagnóstico. MOC 7.0, Anexo I, p. 75.
Exemplos de fuso e relógio adiantado
Exemplo sintético: dhEmi representa 15/10/2026 às 12:10-03:00 e a recepção é 12:02-03:00. A emissão aparece oito minutos no futuro, acima da tolerância. Se os registros da operação mostram que a emissão real ocorreu 12:02, investigue o relógio e a geração de dhEmi; não subtraia oito minutos de todas as notas como solução.
Em outro exemplo, dhEmi=12:00-03:00 e um log de recepção registra 15:00Z. Esses valores representam o mesmo instante: 12:00 no deslocamento -03:00 corresponde a 15:00UTC. A leitura literal “15 menos 12” produziria um diagnóstico falso. Horários e datas aqui são hipóteses didáticas, não valores para preencher notas reais.
O que corrigir e como verificar?
Confronte o horário real da emissão com o dado persistido, o serializador XML e a configuração de fuso. Se a causa for relógio incorreto, ajuste o sincronismo na infraestrutura e confirme seu efeito em novos registros de teste. Se for conversão ou reaproveitamento do rascunho, corrija essa origem preservando a data real e o histórico.
Antes de nova transmissão, confira se existe resposta conclusiva ou autorização da tentativa original. Resultado incerto exige consulta, não reenvio. Depois de corrigir um documento ainda não autorizado quando cabível, valide novamente o instante com fuso e o retorno individual; não edite XML assinado ou autorizado manualmente.
Os exemplos são cenários sintéticos de diagnóstico. Os valores são apresentados em texto para comparação; não constituem um XML fiscal pronto para transmitir. A conferência operacional exige o XML original e o retorno da mesma tentativa.