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.

Tax models count by the date of accrual

Issuing now keeps an earlier draft date in operation_on, so many more invoices carry an operation_on different from issued_on. For an invoice not to change quarter just because it was issued later, the Modelo 303 and the Modelo 130, in the API v1 and in MCP, now assign each sales invoice to the period of its operation_on when it has one, and of its issued_on when it does not.

• Modelo 303 and Modelo 130 — and their previews. The 130 is cumulative, so a sale enters from the quarter of its accrual date and counts only once.
• Corrective invoices — they always count by their own issued_on, because their difference is declared in the period in which they are issued.
• Modelo 347 — it does not change: it keeps assigning by issued_on.
• Expenses — they do not change.

For example, an invoice with operation_on 2026-09-28 and issued_on 2026-10-05 counts in the third-quarter 303 and not in the fourth-quarter one. In the 347 it counts in the fourth quarter.

A model that is already generated is not rewritten. Generating or previewing a period that has already passed again can give another result: an invoice issued later whose operation_on falls in it now counts there. The operations that generate and preview models keep their shape and their description, so they are not among the updated operations below; what changes is which invoices enter each period. Which date decides the period gives the rule of each model.

Store orders

The invoice that Factuarea creates automatically for a store order, WooCommerce or Shopify, is born issued with the date of the day of issue, like any other. The day of the order, in the time zone of the application, is kept in operation_on when it is earlier. An order dated in the future, because the clock of the provider is ahead, leaves with today's date and no operation_on.

• The date is no longer adjusted to the series — until now the date of the order was moved to the date of the last numbered invoice of the series, and an integration event was recorded with discard_reason series_date_clamped. That no longer happens. The value stays in the enum of discard_reason, and as a filter of GET /v1/companies/{company}/integrations/events, because the events recorded before the change keep it. The integration event inbox lists it as retired.
• The date order rule can refuse the invoice — if the rule above rejects the invoice of an order, because the series holds an invoice issued with a future date, the order is not invoiced on its own and no number is consumed. It is recorded in the integration events with status skipped and no discard_reason: its error_message says that the order is not eligible for automatic invoicing and why. It is left for manual review and is not retried, and is_replayable is false. It is how any business rule that rejects the invoice of an order was already treated. Invoice it by hand in another series, or once the date of that last invoice arrives.

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.