dhRecbto em infProt: horário da resposta e fuso correto
<dhRecbto>nfeProc › protNFe › infProt › dhRecbtoRevisão editorial em 15 de out. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.
dhRecbto, em /nfeProc/protNFe/infProt/dhRecbto, registra a data e hora devolvida pela SEFAZ para o processamento da nota. Não é a data de emissão informada pelo emitente. A descrição precisa deve considerar o resultado: o XSD menciona a gravação na confirmação e o recebimento do lote na rejeição; PR08 descreve o processamento, também informado em caso de rejeição.
O que conferir no formato
O campo é obrigatório em infProt e usa TDateTimeUTC. O leiaute apresenta ano-mês-dia, separador T, hora:minuto:segundo e indicação de fuso. No tipo do pacote PL_010f_v1.04, a indicação aceita um deslocamento explícito; não presuma que a letra Z será aceita só porque uma biblioteca genérica de data a reconhece. Confira a expressão de TDateTimeUTC do pacote aplicável.
O valor vem da resposta do autorizador. Não gere a hora local do recebimento pela aplicação como substituto e não altere a data para satisfazer outra validação. Se a integração também registra sua própria recepção, mantenha os dois instantes com nomes diferentes.
Fragmento e comparação de instantes
Exemplo sintético parcial de formato, sem relação com uma emissão real e sem validade de protocolo:
<dhRecbto xmlns="http://www.portalfiscal.inf.br/nfe">2026-10-15T10:00:00-03:00</dhRecbto>
O horário didático 10h no deslocamento -03:00 corresponde a 13h UTC. Uma tela que mostra 13h UTC pode representar o mesmo instante, não um atraso de três horas. Para calcular intervalo entre emissão e processamento, converta ambos os horários para uma referência comum e preserve os fusos originais para auditoria.
Isso não orienta deslocar a data fiscal da nota. dhEmi continua sendo a data/hora real de emissão, e dhRecbto é uma informação do retorno.
Divergências que merecem diagnósticos diferentes
Se o texto do XML difere da tela, compare o instante após a conversão: pode ser apenas apresentação de fuso. Se o retorno original difere da cópia armazenada, examine desserialização e serialização. Se a aplicação registra o momento de consulta como dhRecbto, há troca entre hora de obtenção do arquivo e hora documentada pela SEFAZ.
Em rejeição, não interprete esse horário como prova de autorização: ele também existe para respostas rejeitadas. Do mesmo modo, a data de um protocolo histórico não determina a situação atual após cancelamento ou outros eventos.
Roteiro de conferência
Localize o campo no infProt da chave correta, confirme tpAmb, leia cStat/xMotivo e conserve o deslocamento de fuso. Compare dhEmi, horário de envio, recepção local e dhRecbto como eventos distintos. Se faltar o original, recupere a resposta antes de concluir que o relógio ou a nota está errado. Não edite um XML assinado nem reenvie documento incerto por causa de diferença visual de horário.
Leituras relacionadas
Fontes oficiais
- Leiaute NF-e/NFC-e — PL_010f_v1.04: TProtNFe, linhas 6686–6770.
- Tipos básicos NF-e/NFC-e — PL_010f_v1.04: TChNFe, TProt, TStat, TAmb, TVerAplic, TMotivo e TDateTimeUTC.
- NT 2025.002 RTC — 1.52: seção 5.1, p. 11; PR03–PR90, p. 13.
Referência técnica para integração
- XPath completo
/nfeProc/protNFe/infProt/dhRecbto- Namespace
http://www.portalfiscal.inf.br/nfe- Leiaute
- 4.00 · PL_010e_v1.02
- Ocorrências no XSD
- 1–1 no contexto do elemento pai
- Tipo
- TDateTimeUTC · string
- Preenchimento no catálogo
- Obrigatório
A ocorrência vale dentro da estrutura XML: um campo obrigatório em um grupo opcional não torna esse grupo obrigatório. A aplicação fiscal depende da operação e da versão da regra.
- pattern
(((20(([02468][048])|([13579][26]))-02-29))|(20[0-9][0-9])-((((0[1-9])|(1[0-2]))-((0[1-9])|(1\d)|(2[0-8])))|((((0[13578])|(1[02]))-31)|(((0[1,3-9])|(1[0-2]))-(29|30)))))T(20|21|22|23|[0-1]\d):[0-5]\d:[0-5]\d([\-,\+](0[0-9]|10|11):00|([\+](12):00))- whiteSpace
preserve