Simplified or full invoices

F1, F2 and F3 — when a simplified invoice is legal, the 3.000 € cap that is actually enforced, and the one-call substitution that turns a batch of tickets into a complete invoice.

Spanish law distinguishes the complete invoice (F1), which identifies the recipient and lets them deduct VAT, from the simplified invoice (F2), the ticket a retailer hands over the counter. When a customer later needs a deductible document for a batch of tickets, the law provides a third type: the substitute invoice (F3), which aggregates several simplified ones.

When this applies

A simplified invoice is available in retail-style operations below a legal amount. It is never available for the cases below, and the eligibility check evaluates them in this exact order — the first one that matches wins:

Blocking condition	`reason_code`
Intra-community operation	`intra_community`
Reverse charge	`reverse_charge`
Recipient outside Spain (export)	`export_operation`
The customer needs a deductible invoice	`client_deduction_required`
Total above the absolute legal cap	`over_absolute_limit`

The cap that is enforced in software is 3.000 € including VAT — the maximum any simplified invoice may reach under RD 1619/2012 art. 4, whatever the sector. Crossing it answers 422 with the reason code over_absolute_limit (BR-INV-009).

The general 400 € threshold of the same article is not enforced. Factuarea does not ask a company to declare its economic sector, so it cannot know whether the raised limit applies. Staying inside 400 € when your sector does not qualify for the higher figure is the issuer's fiscal responsibility, not something the API will stop you from doing.

The tax catalogue does not change between the two types. The same VAT rates apply to an F1 and to an F2; what differs is the document's mandatory content, the amount cap and the recipient identification (BR-TAX-011).

What the API sends

Ask before you decide

POST /v1/invoices/simplified-eligibility, scope invoices:read. Built for checkout and point-of-sale flows that must choose the document type before creating anything.

curl -X POST https://api.factuarea.com/v1/invoices/simplified-eligibility \
  -H "Authorization: Bearer fact_live_3pXnR2VbY7TcA9eFmN5z8KqW" \
  -H "Content-Type: application/json" \
  -d '{"total": 3400, "client_country": "ES"}'

{
  "data": {
    "can_be_simplified": false,
    "must_be_complete": true,
    "reason_code": "over_absolute_limit",
    "reason_message": "El importe 3.400,00 EUR supera el límite de 3.000,00 EUR para una factura simplificada.",
    "sector_limit": 3000
  }
}

total is required and is the amount including VAT. client_id, client_country, is_intra_community, is_reverse_charge and client_requires_deductible are optional inputs to the blocking conditions above.

Creating a simplified invoice is not a v1 operation

POST /v1/invoices has no type field and no simplified flag, and client_id is required. The public API cannot issue an F2. Every invoice created through v1 is a complete invoice.

This is a real boundary, not an omission you can work around with a payload trick. If your point-of-sale issues simplified invoices, they are created through the dashboard or the point-of-sale surface; what v1 gives you over them is the eligibility check, reading them, and the substitution below.

The consequence for error handling: the 422 for a disbursement line inside a simplified invoice is unreachable from POST /v1/invoices and reachable only through the corrective endpoint on a simplified original — see Disbursements.

Substituting simplified invoices, in one call

POST /v1/invoices/substitute-simplified, scope invoices:write. You pass the recipient and the list of simplified invoices to aggregate; you get back a complete F3, already issued, with a definitive series number:

curl -X POST https://api.factuarea.com/v1/invoices/substitute-simplified \
  -H "Authorization: Bearer fact_live_3pXnR2VbY7TcA9eFmN5z8KqW" \
  -H "Content-Type: application/json" \
  -d '{
        "client_id": "0197a2a8-4cf0-7a31-9a5e-3f2b8c1d6e42",
        "simplified_invoice_ids": [
          "0197b1c2-3d4e-7f50-8a61-b2c3d4e5f601",
          "0197b1c2-3d4e-7f50-8a61-b2c3d4e5f602"
        ],
        "notes": "Consumos de junio"
      }'

Every simplified invoice in the list is validated (BR-INV-015): the list must be non-empty and free of duplicates, each invoice must belong to your company, each must actually be an F2, none may be annulled or cancelled, and none may already have a substitute. A failure names the offending invoice number in the 422.

The F3 is born issued, and its lines are aggregates: one line per substituted invoice, described as the substitution of that invoice number, with quantity one and the original gross total as unit price, and no tax of its own — the VAT was already charged on the simplified invoice.

Substitution does not annul the originals. Each F2 keeps its fiscal status and simply records that it has been substituted; the invoice object exposes this as substituted_by. An F3 can itself be corrected, like any complete invoice — R1–R4 apply to F1 and F3 alike, see Corrective invoices. What an F3 cannot be is substituted: only an F2 may be the target of a substitution, and only an F3 may carry substituted invoices at all (BR-INV-016).

What appears on the PDF

The visible difference is the recipient block. A complete invoice prints the recipient's name, tax ID and address, frozen at issue time; a simplified one may legitimately have none, and prints the final-consumer placeholder instead (BR-INV-024).

The F3 prints as an ordinary complete invoice — a full recipient block and one line per substituted ticket, naming each substituted invoice number.

What reaches the AEAT

The invoice type travels as the AEAT TipoFactura in the VeriFactu record and is visible on the record object as invoice_type: F1, F2, F3, or R5 for a corrective of a simplified one. The record also flags whether it substitutes simplified invoices (BR-VFC-014).

The type also has consequences in the periodic returns (BR-TXR-004):

An F3 with no recipient tax ID raises a non-blocking warning in the quarterly VAT return: unusual, but legitimate if the original ticket had none either.
An F2 with a registered customer but no tax ID raises a warning too.
An F2 with no tax ID at all is excluded from the annual third-party operations return (Modelo 347) by AEAT rule, and the exclusion is reported as a warning.

None of these block generation. The report is produced and the warnings are returned alongside it, as an empty list when there are none. Blocking would be a frequent false positive.

Traceability

Derived from the domain rules of the Factuarea backend:

BR-INV-009 — the enforced 3.000 € cap, the unenforced 400 € threshold, and the operations that disqualify a simplified invoice.
BR-INV-015 — substitution of simplified invoices by an F3, its validations and its aggregated lines.
BR-INV-016 — only an F3 carries substituted invoices, and never an empty list.
BR-INV-024 — the immutable recipient snapshot, and its absence for a final-consumer ticket.
BR-TAX-011 — the tax catalogue is identical for both types; the limit belongs to invoicing, not to the catalogue.
BR-VFC-014 — the AEAT invoice types and how the type is resolved.
BR-TXR-004 — non-blocking fiscal-quality warnings for F2 and F3 without a tax ID.

The 422 reason codes quoted in When this applies come from the eligibility domain service that materialises BR-INV-009.

Simplified or full invoices

On this page