Invoice types
F1, F2, F3, R1–R5 — what each VeriFactu invoice type means, when BeeL. emits each one, and which API fields map to which AEAT code.
Every invoice you submit to VeriFactu carries a tipo_factura code. BeeL. derives that code from your invoice's type and (for correctives) the rectification_code you set. This page is the canonical map between BeeL's invoice model and the AEAT type codes.
The full catalogue
| AEAT code | AEAT name | BeeL. request fields | Customer ID required? | Notes |
|---|---|---|---|---|
| F1 | Factura ordinaria | type: STANDARD | Yes (NIF or alternative_id) | Default for B2B, and any invoice whose recipient you identify |
| F2 | Factura simplificada | type: SIMPLIFIED | Never — BeeL. rejects an identified recipient | Total ≤ 3,000 € VAT included; whether your activity allows more than 400 € is for you and your tax advisor to check (see Simplified vs standard) |
| F3 | Factura emitida en sustitución de facturas simplificadas | The exchange of simplified invoices (a STANDARD invoice with replaced_invoice_ids) | Yes | Replaces simplified invoices the AEAT already accepted; see Exchanging simplified invoices |
| R1 | Rectificativa por error fundado en derecho | type: CORRECTIVE + rectification_code: R1 | Yes | Most common correction |
| R2 | Rectificativa por concurso de acreedores | type: CORRECTIVE + rectification_code: R2 | Yes | Customer in formal insolvency |
| R3 | Rectificativa por crédito incobrable | type: CORRECTIVE + rectification_code: R3 | Yes | Bad debt |
| R4 | Rectificativa por resto de causas | type: CORRECTIVE + rectification_code: R4 | Yes | Catch-all not in R1–R3 |
| R5 | Rectificativa de factura simplificada | type: CORRECTIVE + rectification_code: R5 | No (like the F2, sent to AEAT without recipient) | The only way to correct an F2 |
rectification_code (R1–R5) is why the rectificative exists. rectification_type (PARTIAL / TOTAL) is how the correction works mathematically — see Corrective invoices. The free-text reason is the human description.
PROFORMA has no AEAT code. The fourth value of type is a commercial document with no fiscal validity: it never enters VeriFactu (no QR, no AEAT submission, no verifactu block). See Proformas.
How BeeL. chooses the code
The decision happens at issuance, never on the draft:
type=STANDARD → F1 (F3 when issued in exchange for simplified invoices)
type=SIMPLIFIED → F2 (no identified recipient, total ≤ 3 000 €)
type=CORRECTIVE → R{rectification_code} (R1, R2, R3, R4, R5)You cannot override tipo_factura directly — set the right type and rectification_code and BeeL. maps them. If you try to issue a STANDARD invoice that fails the F1 rules (e.g. missing recipient.nif and no alternative_id), the request is rejected with a descriptive error before anything is sent to AEAT.
F1 and F2
Use F1 (STANDARD) whenever you identify the recipient, at any amount; F2 (SIMPLIFIED) only for a consumer you don't identify, up to 3,000 € VAT included. The decision table, the rules BeeL. enforces on each path and a canonical request for each are in Simplified vs standard. Invoices BeeL. generates from a Stripe payment follow the same rule: a buyer with a NIF (or foreign identifier) and a complete address gets F1 at any amount (see Generated invoices).
R1–R5 — Rectificative invoices
A corrective invoice always targets an original (via the URL {invoice_id}) and carries:
rectification_code—R1–R5(the AEAT legal motive)rectification_type—PARTIAL(delta) orTOTAL(replace)reason— free-text human description (required)
The combination determines what BeeL. sends to AEAT (tipo_rectificativa = S for TOTAL, I for PARTIAL). Examples for every common scenario live in Corrective invoices.
R5 is reserved for correcting an F2, and R1–R4 for everything else.
Related
Testing VeriFactu in sandbox
How VeriFactu behaves in sandbox — always on, registered against AEAT's test environment, no representation to sign — and the few ways it differs from Live.
Simplified vs standard (F1 vs F2)
When BeeL. issues a simplified invoice (F2) or a standard invoice (F1), the rules of the RD 1619/2012 behind them, and what BeeL. enforces at the API boundary.