---
title: "2026.9 - Data de emissão (issuedOn) no contrato da NF-e"
description: "A emissão de NF-e passa a aceitar o campo issuedOn (dhEmi), separado do operationOn (dhSaiEnt), e a consulta da nota devolve a data de emissão efetivamente usada. Sem o campo, nada muda: a emissão continua assumindo o operationOn ou a data do processamento."
source_url: https://nfe.io/docs/release-notes/2026-9-nfe-issuedon-data-emissao
last_updated: 2026-09-16
---

# Data de emissão (`issuedOn`) no contrato da NF-e

> **Para quem é este comunicado:** integradores que emitem NF-e (modelo 55) pela API e precisam que a data de emissão do documento (`dhEmi`) seja diferente da data de saída ou entrada da mercadoria (`dhSaiEnt`), ou que precisam ler a data de emissão pela API.
>
> **O que muda no seu lado:** nada, se você não enviar o campo novo. A emissão continua usando o `operationOn` como data de emissão e, sem ele, a data e hora do processamento. Quem precisar das duas datas separadas passa a informar `issuedOn`.

## O problema que isso resolve

O XML da NF-e tem duas datas no grupo de identificação: `dhEmi`, a emissão do documento, e `dhSaiEnt`, a saída ou entrada da mercadoria. Até agora o contrato da API só expunha `operationOn` (`dhSaiEnt`). A data de emissão era derivada dele: com `operationOn` informado, `dhEmi` recebia o mesmo valor; sem ele, recebia a data e hora do processamento.

Isso impedia dois cenários legítimos:

- **Emitir hoje uma nota cuja mercadoria sai amanhã.** O `dhEmi` saía igual ao `dhSaiEnt`, no futuro, e a SEFAZ recusava com a rejeição 703.
- **Emitir com data de emissão anterior à saída.** Não havia como informar a emissão separadamente.

Além disso, a consulta da nota não devolvia a data de emissão. O integrador só a encontrava no XML autorizado ou no DANFE.

## O que muda

### Emissão: campo `issuedOn`

O payload de emissão da NF-e aceita o campo opcional `issuedOn`, no formato `AAAA-MM-DDThh:mm:ssTZD`, ao lado do `operationOn` já existente.

```json
{
  "issuedOn": "2026-09-14T18:30:00-03:00",
  "operationOn": "2026-09-15T08:00:00-03:00",
  "operationNature": "Venda de mercadorias"
}
```

**Precedência da data de emissão:**

| Você envia | `dhEmi` no XML |
|---|---|
| `issuedOn` e `operationOn` | `issuedOn` |
| só `operationOn` | `operationOn` (comportamento anterior) |
| nenhum dos dois | data e hora do processamento (comportamento anterior) |

A mesma data define o ano e o mês (`AAMM`) da chave de acesso e a data impressa no DANFE.

### Validações antes de consumir numeração

A API recusa o payload com `400` nos casos que a SEFAZ rejeitaria depois de a nota já ter consumido número e série. As regras valem para a **data de emissão efetiva**: o `issuedOn` ou, quando ele é omitido, o `operationOn`.

| Situação | Resposta da API | Rejeição SEFAZ evitada |
|---|---|---|
| Data de emissão efetiva mais de 5 minutos à frente do horário atual | `400 issuedOn cannot be in the future` (ou `operationOn ...`, quando `issuedOn` foi omitido) | 703 |
| Data de emissão efetiva com mais de 30 dias, em emissão normal | `400 issuedOn cannot be more than 30 days in the past` | 228 |
| NF-e de saída com a **data** de `operationOn` anterior à **data** de `issuedOn` | `400 operationOn date cannot be earlier than issuedOn date on an outgoing invoice` | 506 |

A tolerância de 5 minutos é a mesma que a SEFAZ aplica e absorve pequenas diferenças de relógio entre o seu servidor e a plataforma. O limite de 30 dias não é aplicado quando a nota traz `contingencyDetails`, porque nesse caso o prazo é definido pela SEFAZ da UF. A regra 506 compara datas civis, não instantes: uma saída no mesmo dia, em horário anterior ao da emissão, é aceita, e a NF-e de entrada não tem essa regra.

### Consulta e webhook: campo `issuedOn` na resposta

A resposta da consulta da nota e o payload do webhook passam a trazer `issuedOn` com a data de emissão efetivamente usada no XML. O campo aparece ao lado de `operationOn` e fica ausente enquanto a chave de acesso ainda não foi gerada.

```json
{
  "id": "…",
  "issuedOn": "2026-09-14T18:30:00-03:00",
  "operationOn": "2026-09-15T08:00:00-03:00",
  "status": "Issued"
}
```

## O que não muda

- **NFC-e (modelo 65):** a emissão é sempre no ato. O campo `issuedOn` não faz parte do contrato da NFC-e e, se enviado, é ignorado, como já acontece com `operationOn`.
- **Notas já emitidas:** a data de emissão gravada não muda. A consulta passa a devolvê-la.
- **Emissão em contingência:** com `contingencyDetails` informado, o limite de atraso da emissão não é aplicado pela API e continua com a SEFAZ da UF.

## Referências

- [Layout da NF-e (RTC): grupo de identificação](/documentacao/reforma-tributaria/conceitos-funcionais/nota-fiscal-de-produto/documentacao-layout-nfe-rtc) — campos `issuedOn` e `operationOn`.
- [Guia de troubleshooting: rejeição 703](/documentacao/reforma-tributaria/conceitos-funcionais/nota-fiscal-de-produto/troubleshooting-guide-rtc).
- Manual de Orientação do Contribuinte (MOC) da NF-e, Anexo I — regras de validação B09 (`dhEmi`, rejeições 703 e 228) e B10 (`dhSaiEnt`, rejeição 506).