Invoices take the date of the day they are issued

10 November 2026 — Until now, an invoice kept the date its draft carried, even when it was issued weeks later, and a series could end up with numbers out of date order. From today, issuing an invoice dates it the day it is issued. It applies to the API v1 and to MCP at once, with no notice period.

What changes

• issued_on is the day of issue — when an invoice is issued, issued_on becomes that calendar day in Europe/Madrid, whatever the draft held, earlier or later. From then on it is immutable.
• The draft date moves to operation_on — if the draft date was earlier than the day of issue and operation_on was empty, the draft date is kept in operation_on. An operation_on you had already sent is kept. A draft date later than the day of issue is replaced and does not become operation_on.
• Nothing else is recalculated — due_on and payment_terms stay as they were.

For example, issuing on 2026-11-10:

Scheduled, recurring and batches

• Scheduled invoices — an invoice you schedule leaves with the date of the day it runs, not the draft date and not the day you scheduled it. Its draft date does not move to operation_on; an operation_on you sent is kept.
• Recurring invoices — when the generation_mode of the recurring invoice is issue or issue_and_send, generate creates the invoice already issued, dated the day of issue. An earlier generation date is kept in operation_on.
• Batches issue oldest first — bulk-status to issued (or its alias sent) and bulk-send, which issues the drafts before sending them, process the invoices by draft date, and by age when two dates tie, whatever the order of ids. The lowest number goes to the oldest date. failures[] comes out in that processing order, not in the order you sent.
• bulk-create does not issue — it only creates drafts, so issued_on stays the draft date there.

A new 422 protects the order of the series

An invoice is never issued with a date earlier than the last issued invoice of its series. The call answers 422, error.code: business_rule_violation and error.subcode: issue_date_before_series_last_issue_date, with error.param: issued_on. No number is consumed and the draft stays as it was.

{
  "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"
  }
}

The day of issue is now always today, so this only happens when the series already holds an invoice dated in the future, which the API v1 allowed until now, or, in rare cases, when the server clock goes back. Changing issued_on does not help. Move the draft to another series of the same kind with series_id, or issue it once the date of that last invoice arrives.

• Where you can get it — create with options that issue, payment or type: F2; issue; send on a draft; mark-sent in API versions before 2026-10-01; bulk-send; and generate on a recurring invoice with an issuing mode. If you created the invoice with options, the draft already exists: issue that draft instead of repeating the creation.
• Batches — bulk-status reports the rejected row in failures[] with error_code business_rule_violation and no subcode, and goes on with the rest. bulk-send does the same for companies with revisioned presentation; for the others, the rejection aborts the call with this 422, the invoices before it are already issued and the ones after it are not processed.
• Scheduled invoices — one that the rule rejects when it runs is not issued: it stays scheduled, consumes no number and is tried again on the next pass.

What to check in your integration

• Read the dates from the response — if you sent a past issued_on expecting it to stay, issued_on now comes back as the day of issue and the date you sent is in operation_on. Take both from the response of issue or create, or from the invoice you read afterwards.
• Dates in the future — a future issued_on no longer survives: the invoice leaves with today's date and no operation_on. If you also sent an operation_on later than the day of issue, issuing answers operation_date_after_issue_date, unless the first line that declares a regime_key uses 14 or 15.
• Series with future dates — a series that already holds an invoice dated in the future refuses every issue until that day arrives. Use another series or wait. Annulling that invoice does not unblock the series, because annulled invoices count.
• Which date goes where — if the day the service was done matters, send it as operation_on in the draft. issued_on on a draft is only the draft date.
• MCP — the tools behave like their operations and return the same error: issue_invoice, send_invoice, create_invoice, bulk_change_invoice_status, bulk_send_invoices, bulk_create_invoices, schedule_invoice and generate_recurring_invoice. The description of update_invoice now says that issued_on is the draft date. The guardrail emision-borrador-a-emitida, listed in Resources and prompts, explains the rule.

Updated operations

The descriptions of issued_on and operation_on change in the invoice resource and in the request bodies of create and update. These nine operations change their description, and the six that can answer the new 422 declare it:

• POST /v1/companies/{company}/invoices — creating with options that issue, payment or type: F2 dates the invoice the day of issue. Declares the new 422.
• POST /v1/companies/{company}/invoices/bulk-create — its rows are drafts and are never issued there.
• POST /v1/companies/{company}/invoices/bulk-send — drafts are issued oldest first, dated the day of issue. Declares the new 422.
• POST /v1/companies/{company}/invoices/bulk-status — issuing goes oldest date first, and each invoice takes the date of the day of issue.
• POST /v1/companies/{company}/invoices/{invoice}/issue — the invoice leaves with the date of the day of issue. Declares the new 422.
• POST /v1/companies/{company}/invoices/{invoice}/mark-sent — in API versions before 2026-10-01 it issues the draft with the same rule. Declares the new 422.
• POST /v1/companies/{company}/invoices/{invoice}/schedule — the invoice leaves with the date of the day it runs, and stays scheduled if the series has a later issued invoice.
• POST /v1/companies/{company}/invoices/{invoice}/send — a draft is issued first, dated the day of issue. Declares the new 422.
• POST /v1/companies/{company}/recurring-invoices/{recurring_invoice}/generate — with an issuing mode the invoice is born issued, dated the day of issue. Declares the new 422.