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.

Los modelos fiscales cuentan por la fecha de devengo

Emitir conserva ahora en operation_on una fecha de borrador anterior, así que muchas más facturas llevan un operation_on distinto de issued_on. Para que una factura no cambie de trimestre solo por emitirse más tarde, el Modelo 303 y el Modelo 130, en la API v1 y en MCP, asignan ahora cada factura de venta al periodo de su operation_on cuando la tiene y, si no, al de su issued_on.

• Modelo 303 y Modelo 130 — y sus vistas previas. El 130 es acumulado, así que una venta entra desde el trimestre de su fecha de devengo y cuenta una sola vez.
• Facturas rectificativas — cuentan siempre por su propio issued_on, porque su diferencia se declara en el periodo en que se emiten.
• Modelo 347 — no cambia: sigue asignando por issued_on.
• Gastos — no cambian.

Por ejemplo, una factura con operation_on 2026-09-28 e issued_on 2026-10-05 cuenta en el 303 del tercer trimestre y no en el del cuarto. En el 347 cuenta en el cuarto trimestre.

Un modelo ya generado no se reescribe. Generar o previsualizar de nuevo un periodo que ya pasó puede dar otro resultado: una factura emitida después cuyo operation_on cae en él cuenta ahora allí. Las operaciones que generan y previsualizan los modelos conservan su forma y su descripción, así que no están entre las operaciones actualizadas de abajo; lo que cambia es qué facturas entran en cada periodo. Qué fecha decide el periodo recoge la regla de cada modelo.

Pedidos de tienda

La factura que Factuarea crea automáticamente para un pedido de tienda, de WooCommerce o de Shopify, nace emitida con la fecha del día de emisión, como cualquier otra. El día del pedido, en la zona horaria de la aplicación, se conserva en operation_on cuando es anterior. Un pedido con fecha futura, por un desfase del reloj del proveedor, sale con la fecha de hoy y sin operation_on.

• La fecha ya no se ajusta a la serie — hasta ahora la fecha del pedido se movía a la de la última factura numerada de la serie y se registraba un evento de integración con discard_reason series_date_clamped. Eso ya no ocurre. El valor sigue en el enum de discard_reason, y como filtro de GET /v1/companies/{company}/integrations/events, porque los eventos anteriores al cambio lo conservan. La bandeja de eventos de integración lo lista como retirado.
• La regla de orden de fechas puede rechazar la factura — si la regla de arriba rechaza la factura de un pedido, porque la serie tiene una factura emitida con fecha futura, el pedido no se factura solo y no se consume número. Queda registrado en los eventos de integración con estado skipped y sin discard_reason: su error_message dice que el pedido no es elegible para facturación automática y por qué. Queda para revisión manual y no se reintenta, y is_replayable es false. Es el tratamiento que ya tenía cualquier regla de negocio que rechaza la factura de un pedido. Factúralo a mano en otra serie, o cuando llegue la fecha de esa última factura.

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.