Simplified or full invoices

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. And a simplified invoice that already names its recipient is a qualified simplified invoice: it lets the recipient deduct the VAT, and the AEAT registers it as an F1 (below).

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:

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 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/companies/{company}/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/companies/{company}/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.

Issuing a simplified invoice through v1

POST /v1/companies/{company}/invoices accepts type with the values F1 (the default) or F2. With type: "F2":

• client_id is optional. Without it the invoice is an anonymous ticket; with one, it is a qualified simplified invoice. The client must belong to your company.
• The company must have simplified invoices enabled; otherwise the answer is 422 simplified_invoices_disabled. The check uses the company of the API key, not a user.
• The invoice must be eligible: absolute cap of 3.000 € VAT included, and no intra-community, reverse-charge or export operation. If it is not, 422 business_rule_violation with subcode: simplified_invoice_not_allowed and the reason in the message.
• series_id is optional. A simplified invoice is only numbered in a series of simplified invoices (invoice_kind: simplified): without series_id it goes to your default simplified series (S), created automatically the first time; with the series_id of another purpose the answer is 422 series_invoice_kind_mismatch. GET /v1/companies/{company}/series/default?document_type=invoice&invoice_kind=simplified returns the series to use. A corrective of a simplified invoice goes in its own series (simplified_corrective, RS).

With type: "F1" or no type, client_id is still required and the client must have a complete tax ID.

The usual flow of a point of sale — an F2 already paid, with the prices the customer saw, the VERI*FACTU registration and its QR in the same response — is in Unattended checkout invoicing.

A disbursement line is not allowed inside a simplified invoice: the answer is 422 suplido_not_allowed_in_simplified_invoice, whether you create the F2 or correct one. See Disbursements.

The qualified simplified invoice

A simplified invoice that carries the recipient's tax ID is a qualified simplified invoice (RD 1619/2012, art. 7.2 and 7.3): it is still a simplified invoice, but the recipient can deduct the VAT. The AEAT rejects an F2 that has a recipient (error 1190), so Factuarea registers it as:

In Factuarea the invoice remains simplified in its type, its PDF and its numbering: only the record sent to the AEAT changes. To qualify an invoice, send type: "F2" with a client_id that has a tax ID.

Substituting simplified invoices, in one call

POST /v1/companies/{company}/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/companies/{company}/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.

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; a qualified one prints its recipient (BR-INV-024). The date of the operation is printed next to the issue date when it differs, and a simplified invoice can also be printed as a thermal ticket (ticket_80 or ticket_58, see Unattended checkout invoicing).

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. A qualified simplified invoice is declared as F1 with FacturaSimplificadaArt7273, and its corrective as R1 to R4 with the same mark. 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.