Las facturas toman la fecha del día en que se emiten

10 de noviembre de 2026 — Hasta ahora, una factura conservaba la fecha de su borrador aunque se emitiera semanas después, y una serie podía acabar con números fuera del orden de las fechas. Desde hoy, emitir una factura le pone la fecha del día en que se emite. Vale a la vez para la API v1 y para MCP, sin periodo de aviso.

Qué cambia

• issued_on es el día de emisión — al emitir una factura, issued_on pasa a ser ese día natural en Europe/Madrid, tuviera lo que tuviera el borrador, anterior o posterior. Desde entonces es inmutable.
• La fecha del borrador pasa a operation_on — si la fecha del borrador era anterior al día de emisión y operation_on estaba vacío, la fecha del borrador se conserva en operation_on. Un operation_on que ya habías enviado se conserva. Una fecha de borrador posterior al día de emisión se sustituye y no pasa a operation_on.
• Nada más se recalcula — due_on y payment_terms se quedan como estaban.

Por ejemplo, emitiendo el 2026-11-10:

Programadas, recurrentes y lotes

• Facturas programadas — una factura que programas sale con la fecha del día en que se ejecuta, no la del borrador ni la del día en que la programaste. La fecha de su borrador no pasa a operation_on; un operation_on que enviaste se conserva.
• Facturas recurrentes — cuando el generation_mode de la factura recurrente es issue o issue_and_send, generate crea la factura ya emitida, con la fecha del día de emisión. Una fecha de generación anterior se conserva en operation_on.
• Los lotes emiten de la fecha más antigua a la más reciente — bulk-status a issued (o su alias sent) y bulk-send, que emite los borradores antes de enviarlos, procesan las facturas por la fecha de su borrador, y por antigüedad si dos fechas coinciden, con independencia del orden de ids. El número más bajo va a la fecha más antigua. failures[] sale en ese orden de procesamiento, no en el que enviaste.
• bulk-create no emite — solo crea borradores, así que en esa operación issued_on sigue siendo la fecha del borrador.

Un 422 nuevo protege el orden de la serie

Una factura nunca se emite con una fecha anterior a la de la última factura emitida de su serie. La llamada responde 422, error.code: business_rule_violation y error.subcode: issue_date_before_series_last_issue_date, con error.param: issued_on. No se consume número y el borrador queda como estaba.

{
  "error": {
    "type": "invalid_request_error",
    "code": "business_rule_violation",
    "subcode": "issue_date_before_series_last_issue_date",
    "message": "No se puede emitir con fecha 10/11/2026: la serie ya tiene una factura emitida con fecha 12/11/2026.",
    "param": "issued_on",
    "doc_url": "https://docs.factuarea.com/guides/errors#business_rule_violation",
    "request_id": "req_01KFPT3RM5H7J9K2M4N6P8Q0RS"
  }
}

El día de emisión es ahora siempre hoy, así que solo ocurre cuando la serie ya tiene una factura con fecha futura, algo que la API v1 permitía hasta ahora, o, en casos raros, cuando el reloj del servidor retrocede. Cambiar issued_on no lo resuelve. Pasa el borrador a otra serie del mismo tipo con series_id, o emítelo cuando llegue la fecha de esa última factura.

• Dónde puedes recibirlo — create con opciones que emiten, payment o type: F2; issue; send sobre un borrador; mark-sent en las versiones de la API anteriores a 2026-10-01; bulk-send; y generate en una factura recurrente con un modo que emite. Si creaste la factura con options, el borrador ya existe: emite ese borrador en lugar de repetir el alta.
• Lotes — bulk-status notifica la fila rechazada en failures[] con error_code business_rule_violation y sin subcódigo, y sigue con las demás. bulk-send hace lo mismo en las empresas con presentación con revisiones; en las demás, el rechazo aborta la llamada con este 422, las facturas anteriores ya están emitidas y las posteriores no se procesan.
• Facturas programadas — la que la regla rechaza al ejecutarse no se emite: sigue en scheduled, no consume número y se vuelve a intentar en la pasada siguiente.

Qué revisar en tu integración

• Lee las fechas de la respuesta — si enviabas un issued_on pasado esperando que se conservara, ahora issued_on vuelve como el día de emisión y la fecha que enviaste está en operation_on. Toma las dos de la respuesta de issue o create, o de la factura que leas después.
• Fechas futuras — un issued_on futuro ya no sobrevive: la factura sale con la fecha de hoy y sin operation_on. Si además enviabas un operation_on posterior al día de emisión, emitir responde operation_date_after_issue_date, salvo que la primera línea que declara un regime_key use 14 o 15.
• Series con fechas futuras — una serie que ya tiene una factura con fecha futura rechaza toda emisión hasta que llegue ese día. Usa otra serie o espera. Anular esa factura no desbloquea la serie, porque las anuladas cuentan.
• Qué fecha va dónde — si importa el día en que se hizo el servicio, envíalo como operation_on en el borrador. El issued_on de un borrador es solo la fecha del borrador.
• MCP — las tools se comportan como sus operaciones y devuelven el mismo error: issue_invoice, send_invoice, create_invoice, bulk_change_invoice_status, bulk_send_invoices, bulk_create_invoices, schedule_invoice y generate_recurring_invoice. La descripción de update_invoice ahora dice que issued_on es la fecha del borrador. El guardrail emision-borrador-a-emitida, listado en Recursos y prompts, explica la regla.

Operaciones actualizadas

Las descripciones de issued_on y operation_on cambian en el recurso de factura y en los cuerpos de crear y actualizar. Estas nueve operaciones cambian su descripción, y las seis que pueden responder el 422 nuevo lo declaran:

• POST /v1/companies/{company}/invoices — crear con opciones que emiten, payment o type: F2 fecha la factura el día de emisión. Declara el 422 nuevo.
• POST /v1/companies/{company}/invoices/bulk-create — sus filas son borradores y nunca se emiten ahí.
• POST /v1/companies/{company}/invoices/bulk-send — los borradores se emiten de la fecha más antigua a la más reciente, con la fecha del día de emisión. Declara el 422 nuevo.
• POST /v1/companies/{company}/invoices/bulk-status — la emisión va de la fecha más antigua a la más reciente, y cada factura toma la fecha del día de emisión.
• POST /v1/companies/{company}/invoices/{invoice}/issue — la factura sale con la fecha del día de emisión. Declara el 422 nuevo.
• POST /v1/companies/{company}/invoices/{invoice}/mark-sent — en las versiones de la API anteriores a 2026-10-01 emite el borrador con la misma regla. Declara el 422 nuevo.
• POST /v1/companies/{company}/invoices/{invoice}/schedule — la factura sale con la fecha del día en que se ejecuta, y sigue programada si la serie tiene una factura emitida posterior.
• POST /v1/companies/{company}/invoices/{invoice}/send — un borrador se emite primero, con la fecha del día de emisión. Declara el 422 nuevo.
• POST /v1/companies/{company}/recurring-invoices/{recurring_invoice}/generate — con un modo que emite, la factura nace emitida, con la fecha del día de emisión. Declara el 422 nuevo.