dhSaiEnt na NF-e: data de saída, fuso e rejeições 504 a 506

O dhSaiEnt registra a data e a hora da saída ou entrada da mercadoria ou produto. Ele não substitui a data de emissão. No leiaute, tem ocorrência 0–1; porém, é proibido na NFC-e modelo 65 e, pela NT 2026.002, também na NF-e modelo 55 com DANFE Simplificado Tipo 2, identificada por tpImp=6. Nesses casos, a presença do campo está associada à rejeição 705. MOC, B10 NT 2026.002, B10-10

O instante registrado e a origem do dado

Emitir o documento e movimentar a mercadoria são fatos diferentes:

A informação de dhSaiEnt vem da movimentação documentada na operação. Copiar automaticamente dhEmi só representa corretamente a movimentação se os dois instantes realmente coincidirem. Não use uma data estimada ou uma data conveniente para fazer a validação passar. Definições de B09 e B10

Quando o campo pode aparecer

Na NF-e modelo 55 fora do fluxo Tipo 2, o campo é estruturalmente opcional: pode ocorrer no máximo uma vez em ide. Essa ocorrência não decide eventuais exigências aplicáveis à operação; tampouco autoriza inventar uma data quando o fato não é conhecido.

Na NFC-e e na NF-e com tpImp=6, não informar dhSaiEnt é uma condição expressa da B10-10 atualizada. O MOC anterior descreve somente NFC-e; a NT 2026.002 amplia o alcance ao Tipo 2. O cronograma dessa atualização prevê produção em 03/08/2026, anterior ao corte de 26/09/2026. Cronograma e B10-10

Assim, o diagnóstico da 705 precisa considerar modelo e formato de impressão. Conferir apenas mod=55 não basta para concluir que dhSaiEnt é permitido.

Formato com fuso explícito

O formato previsto é AAAA-MM-DDThh:mm:ssTZD:

2026-09-26T12:30:00-03:00

No exemplo, a data é 26/09/2026, a hora local é 12:30:00 e o deslocamento em relação a UTC é −03:00. A letra T separa data e hora. Mês, dia, horas, minutos e segundos usam a quantidade de posições mostrada.

O tipo TDateTimeUTC do pacote oficial 010d v1.03 exige deslocamento explícito e define seu próprio padrão de calendário e horário. Nesse padrão, os minutos do deslocamento são 00, como em -03:00 ou +00:00; um deslocamento -03:30 não satisfaz o tipo. Não copie toda variante que uma biblioteca genérica de ISO 8601 consiga produzir: Z, frações de segundo, data brasileira “26/09/2026” e hora sem fuso não correspondem ao padrão desse tipo consultado. Tipo TDateTimeUTC

Além de conferir o tipo do XML, valide a data no calendário civil e interprete o instante com um parser apropriado de data, hora e fuso. A aprovação no padrão do XSD, por si só, não certifica uma data civil válida nem a movimentação real: o pacote contém expressões que precisam ser acompanhadas dessa conferência. Não altere o arquivo oficial do schema para encobrir um problema do gerador.

Apesar do nome UTC, o exemplo com offset −03:00 é uma representação prevista. Para expressar o mesmo instante em offset +00:00, seria necessário converter a hora para 15:30:00:

2026-09-26T15:30:00+00:00

A equivalência explica o significado do fuso; não recomenda mudar a representação operacional. Trocar apenas “−03:00” por “+00:00” e manter 12:30:00 altera o instante em três horas. Confira o fuso e o horário realmente usados na operação.

Limites de 30 dias e contingência

Quando dhSaiEnt está informado no modelo 55, o MOC prevê duas verificações facultativas relacionadas à data de autorização:

A referência é a data de autorização, não simplesmente dhEmi. São regras separadas para limite posterior e anterior; não atribua os dois códigos à mesma direção. Por serem facultativas no MOC, verifique a aplicação pelo autorizador e o retorno efetivamente recebido. B10-20 e B10-30, p. 76

A B10-30 tem uma observação para SEFAZ que aceita NF-e emitida em contingência há mais de 30 dias: essa rejeição deve considerar os tipos 1, 3, 6 e 7. A fonte usa a grafia tpEmi nessa observação, enquanto o campo de tipo de emissão do leiaute é tpEmis. Isso não significa criar uma tag tpEmi no XML.

A observação qualifica a aplicação daquela regra na SEFAZ correspondente; não é uma dispensa automática de toda validação temporal para qualquer modalidade de contingência ou UF. Também não altera a proibição de dhSaiEnt em NFC-e ou Tipo 2. Observação da B10-30

Saída anterior à emissão e rejeição 506

A B10-40 é outra verificação facultativa: para NF-e de saída, com tpNF=1 e dhSaiEnt informado, rejeita a data de saída menor que a data de emissão, com 506 — Data de Saída menor que a Data de Emissão. B10-40

A condição está limitada à saída. Não a transplante automaticamente para uma NF-e de entrada com tpNF 0. Uma entrada pode ter contexto documental próprio; é necessário conferir os fatos e as outras regras aplicáveis, sem inventar que qualquer data anterior está aprovada.

Ao investigar a 506, compare os valores do XML original e a representação de fuso. Se o sistema registrou o horário errado, apure a origem e a conversão feita na geração. Não altere a movimentação verdadeira para representar um fato posterior que não aconteceu.

Exemplo parcial e diagnóstico do retorno

O recorte abaixo é sintético. Ele mostra uma NF-e modelo 55 com formato normal de DANFE e uma saída posterior à emissão, ambas com o mesmo offset:

<ide xmlns="http://www.portalfiscal.inf.br/nfe">
  <mod>55</mod>
  <!-- Série e número foram omitidos. -->
  <dhEmi>2026-09-26T10:00:00-03:00</dhEmi>
  <dhSaiEnt>2026-09-26T12:30:00-03:00</dhSaiEnt>
  <tpNF>1</tpNF>
  <!-- Demais indicadores e município foram omitidos. -->
  <tpImp>1</tpImp>
</ide>

A sequência temporal ilustrada é coerente com a comparação de saída e emissão. O exemplo não informa autorização, não permite conferir os limites de 30 dias e não é uma nota completa ou pronta para transmissão.

No diagnóstico, preserve XML e resposta originais e separe a causa:

• 705: modelo 65 ou modelo 55 com Tipo 2 e campo indevidamente informado.
• 504: limite posterior em relação à autorização.
• 505: limite anterior, considerando a observação de contingência e a aplicação pela UF.
• 506: saída menor que emissão na condição específica de tpNF 1.
• Erro de schema: representação de data, hora ou deslocamento incompatível com o tipo carregado pelo validador.

A correção pertence à origem do dado e à geração coerente do documento. Não edite XML assinado, não altere datas ou o formato do DANFE apenas para eliminar o retorno e não trate aprovação estrutural como prova de adequação fiscal da operação.