Rejeição 703: investigue a hora e o fuso gravados no XML

Quando o retorno indicar emissão posterior ao recebimento, comece pelo arquivo enviado. Confira data, hora e fuso em dhEmi, preserve a resposta completa e descubra qual equipamento ou integração preencheu esse campo. O relógio mostrado na tela pode estar correto enquanto o documento contém outro instante.

Este guia foi conferido em 15/10/2026 e trata da autorização de NF-e modelo 55 e NFC-e modelo 65. A interpretação da B09-10 usa o MOC e o confronto com a documentação posterior consultada. A conferência documental não substitui o retorno da nota nem comprova o funcionamento de cada UF, autorizador e ambiente.

O critério documentado

A mensagem é “Rejeição: Data-Hora de Emissão posterior ao horário de recebimento”. Na página 75, a B09-10 compara emissão e recepção na SEFAZ. A linha do MOC tem modelos 55/65, aplicação obrigatória e efeito de rejeição.

Sua observação admite tolerância de até cinco minutos, relacionada ao sincronismo entre os servidores da empresa e da SEFAZ. Isso não transforma cinco minutos em meta para o relógio nem autoriza recuar a emissão artificialmente.

A linha não apresenta exceção própria, condição de tipo de emissão ou formato de impressão. Também não distingue produção e homologação nem restringe UFs. Essas características documentais não comprovam execução atual uniforme; registre o ambiente e o autorizador efetivamente utilizados.

Leia o instante completo

Na página 9 do MOC, B09 identifica ide/dhEmi: data e hora de emissão no formato AAAA-MM-DDThh:mm:ssTZD. O trecho final indica o deslocamento temporal. Leia o conjunto, inclusive o dia, para investigar diferenças.

Na mesma data, 10:00:00-03:00 corresponde a 13h UTC; 10:00:00-04:00, a 14h UTC. Os números locais parecem iguais, mas os instantes estão separados por uma hora. Esse exemplo é matemático; não define o fuso de um estabelecimento.

O MOC documenta leiaute 4.00 na página 8. Na página 10, tpAmb identifica 1 para produção e 2 para homologação. Compare esse campo com a resposta e o serviço utilizado.

A NT 2026.002 v1.11 descreve dhRecbto, na página 6, como horário de processamento, informado também em rejeição. Preserve esse dado, mas não o equipare automaticamente ao instante interno de recepção da validação. Uma divergência persistente exige análise do autorizador.

Preserve o pacote antes de ajustar

Guarde XML transmitido, retorno integral, chave e horário da tentativa. Registre estação, servidor, versão do emissor, ambiente e origem do preenchimento. Se houve importação, preserve também o registro de origem.

Relacione cada resposta ao arquivo correspondente. Um retorno antigo ou resumido na tela pode levar a investigar a tentativa errada. Quando o resultado da transmissão ficou desconhecido, peça a consulta da situação antes de criar outro documento.

A correção deve representar o fato ocorrido. Não altere data, modelo, estabelecimento ou enquadramento fiscal apenas para ultrapassar uma rejeição. Evite editar diretamente XML assinado; a geração e a assinatura precisam seguir o fluxo adequado do emissor.

Três cenários para localizar a causa

O equipamento responsável está adiantado. Identifique quem fornece a hora: caixa, servidor ou integração. Uma falha concentrada numa estação pode ajudar a investigação, mas não comprova sozinha a origem. O responsável técnico deve verificar a sincronização e comparar o valor produzido no arquivo após o ajuste.

A hora local parece certa, mas a conversão está errada. Confira fuso e transformações entre sistemas. Uma integração pode converter para UTC e aplicar novamente um deslocamento. Não imponha um único fuso para todo o Brasil nem ative horário de verão por orientação antiga. O contexto geográfico e a data precisam ser conferidos.

Uma entrada manual ou importação trouxe outra data. Compare pedido, registro da operação e processo de emissão. Um campo pode ter recebido o dia seguinte ou um horário destinado à entrega. Corrija o erro constatado preservando o fato fiscal; situações de contingência ou mudança de dia precisam da avaliação contábil.

Em filas de emissão, investigue se o arquivo já estava preparado e como sua data foi obtida. Atualizar indiscriminadamente todo documento para a hora atual pode modificar uma informação que precisa ser preservada.

Não confunda futuro com atraso

A página 8 da NT 2026.002 v1.11 trata de B09-20/228 e B09-40/704, relativas a atraso. A segunda contempla NFC-e e NF-e com DANFE Simplificado Tipo 2, sob condições próprias de impressão e emissão.

Essas condições e exceções não pertencem à B09-10. O MOC também contém 7B09-10/479, na página 138, sobre emissão anterior ao credenciamento ou abertura. O prefixo faz parte da identidade: essa regra é diferente de B09-10/703.

A emissão no futuro e o envio atrasado exigem investigações diferentes. Não transporte os prazos ou as exceções de contingência de 228 e 704 para 703. O responsável técnico deve identificar qual comparação corresponde à mensagem recebida, sem supor que um prazo de transmissão permita registrar um instante futuro.

Exemplo fictício: hora local igual, deslocamentos diferentes

Uma distribuidora analisa um pacote fictício de NF-e modelo 55 após mudar uma integração. Na mesma data hipotética, o XML registra 11:15:00-04:00, enquanto o instante de recepção considerado no exemplo é 11:15:00-03:00. O retorno fictício é 703.

O primeiro instante corresponde a 15h15 UTC; o segundo, a 14h15 UTC. A diferença é de uma hora, acima da tolerância documentada. Comparar apenas “11h15” esconderia o problema.

A equipe preserva os registros e rastreia a conversão, sem presumir qual deslocamento deveria valer numa operação real. Depois de comprovar a causa, orienta o ajuste na origem e confere o arquivo produzido. O exemplo não comprova recepção operacional, não determina fuso por UF e não termina com autorização presumida.

Encaminhe e confira o resultado

Solicite ao suporte a comparação entre parâmetro, origem da hora e dhEmi enviado. Este guia não apresenta menu ou procedimento ALRA verificado. Acione a contabilidade quando houver dúvida sobre data fiscal, contingência ou alteração do fato documentado.

Após uma correção fundamentada, confira o novo XML e a resposta ligada à chave e ao ambiente. O desaparecimento de 703 não demonstra autorização; verifique situação e eventual protocolo. Outro código exige análise própria.

Se 703 persistir com instantes conferidos, encaminhe o pacote ao atendimento do autorizador por canal protegido. Inclua horários, fusos e transformações identificadas, distinguindo recepção de processamento.

Fontes

Documentação conferida em 15/10/2026.

• MOC 7.0, Anexo I: B09-10, página 75; campos, 8–10; regra distinta 7B09-10, 138; mensagem 703, 150.

• NT 2026.002 v1.11: página 6, definição de dhRecbto; página 8, regras de atraso; página 3, cronogramas próprios. O documento não apresenta alteração expressa de B09-10/703.

• Documentos SVRS: índice oficial confrontado com os documentos preservados. A cobertura documental examinada não equivale a teste de implantação.

• Guias específicos confrontados: Treeunfe, Total ERP e IOB. Não foram adotados menus de outros sistemas, ajuste indiscriminado para hora atual, fuso único nacional ou promessa de autorização.