Fechas de la factura

El formato de fechaExpedicion y fechaOperacion, la regla de no-futuro, la zona horaria y qué espera cada administración.

Cada factura lleva hasta dos fechas, y las administraciones las tratan con reglas precisas. Esta página las reúne todas: el formato, la regla de no-futuro, la zona horaria en la que se evalúa «hoy» y el papel de la fecha en la identidad de la factura. Aplican igual a VeriFactu y a TicketBAI salvo donde se indica.

Los dos campos

Si no envías fechaOperacion, se entiende que coincide con fechaExpedicion.

Lo habitual es facturar durante o después de la operación: se entrega el día 1 y se factura el día 5, así que la fecha de operación es anterior o igual a la de expedición. La excepción son los anticipos (se factura hoy algo que se entregará más adelante), un caso legítimo que no todas las administraciones tratan igual: ver qué espera cada administración.

Formato

fechaExpedicion y fechaOperacion son cadenas JSON en formato dd-mm-aaaa, idéntico en las dos APIs:

Los espacios al principio y al final se ignoran: " 01-08-2026 " se acepta.

Dos dígitos. El esquema oficial de TicketBAI define estas fechas con longitud exacta de 10 caracteres, y la fecha viaja tal cual al documento firmado. 1-8-2026 produciría un documento inválido. La API la rechaza en la entrada, antes de firmar.

Años bisiestos. Se validan incluidas las reglas de siglo. 29-02-2024 se acepta; 29-02-2026, 29-02-1900 y 29-02-2100 se rechazan; 29-02-2000 se acepta.

La fecha de expedición no puede ser futura

Una factura no puede emitirse en el futuro. Si fechaExpedicion es posterior a hoy, la petición se rechaza con 400.

• El límite es inclusivo: la fecha de hoy es válida.
• «Hoy» se evalúa en hora peninsular española (Europe/Madrid), no en UTC. Entre las 00:00 y las 02:00 hora peninsular, la fecha UTC es todavía la del día anterior. Un sistema en una zona horaria por delante de la peninsular puede calcular ya la fecha de «mañana» según Madrid. Calcula la fecha de expedición en hora peninsular.
• Canarias va una hora por detrás de la Península: una fecha local canaria no queda por delante.

La AEAT y las tres haciendas forales aplican esta misma regla. La validación en la entrada evita el rechazo posterior de la administración.

La regla se aplica también a las fechas que referencian otra factura. Esa factura ya existe, así que su fecha no puede estar en el futuro:

• la fecha de la factura que se rectifica (rectificativa.facturasRectificadas[].fechaExpedicion),
• la fecha de la factura que se anula (endpoints de anulación).

La fecha identifica la factura

fechaExpedicion no es un dato descriptivo: junto con serie y numero, identifica la factura. Tres consecuencias directas:

1. La anulación localiza la factura por serie + numero + fechaExpedicion. Si alguno de los tres no coincide exactamente con la factura original, la anulación no la encuentra.
2. La subsanación reenvía la misma factura corregida: conserva serie, numero y fechaExpedicion. No sirve para corregir la fecha de expedición: cambiarla equivale a declarar una factura distinta.
3. Si la fecha de expedición se envió mal y el registro ya se remitió, anula la factura y emite una nueva. No subsanes.

En TicketBAI, además, la fecha de expedición va incorporada al identificador TBAI (en formato ddmmaa) y, con él, al código QR de la factura.

La fecha de operación: qué espera cada administración

La API acepta una fechaOperacion futura. Cada administración aplica su propio criterio:

Si facturas un anticipo (una operación cuya fecha es posterior a la de expedición) y el emisor tributa en Bizkaia, la Hacienda Foral de Bizkaia no admite una fecha de operación posterior a la fecha de expedición ni posterior al día actual. En VeriFactu, informa claveRegimen 14 o 15 cuando la fecha de operación sea posterior a la de expedición.

Dónde viaja cada campo

En VeriFactu las fechas de la factura van dentro de cabecera; en TicketBAI, en el nivel superior. El contrato completo está en las referencias de VeriFactu y TicketBAI.

VeriFactu

TicketBAI

En TicketBAI, el bloque rectificativa.facturasRectificadas cubre tanto las facturas rectificadas como las sustituidas: no existe un campo facturasSustituidas separado.

Las demás fechas de la petición

La regla de no-futuro no es exclusiva de fechaExpedicion. Otros tres campos la aplican, con la misma evaluación de «hoy» en hora peninsular:

Si omites horaExpedicion, la hora que queda en el documento firmado es la peninsular, la misma zona en la que se evalúa la fecha. Una hora calculada en UTC deja en el documento la fecha de hoy con la hora de ayer.

Errores

Todos los problemas de fecha se devuelven como 400 con el campo señalado por su nombre, no como un 5xx ni como un error genérico:

Mensajes reales, como referencia:

fechaExpedicion debe estar en formato DD-MM-YYYY (recibido: 1-8-2026)
fechaExpedicion no es una fecha válida en formato DD-MM-YYYY (recibido: 32-13-2026)
fechaExpedicion no puede ser posterior a hoy (recibido: 01-01-2099; hoy: 22-08-2026, hora peninsular)
rectificativa.facturasRectificadas[0].fechaExpedicion no puede ser posterior a hoy: la factura que se rectifica ya fue emitida (recibido: 01-01-2099)

Una fecha mal formada produce un solo error: si el valor no es una fecha reconocible, se informa el problema de formato y no se añade además el de fecha futura.

Ejemplos

Suponiendo que hoy es 22-08-2026: