# Create an invoice API Reference Creates an invoice for this company. The issuer data comes from the company in the path, and the document is created as a draft unless you ask for it to be issued. - **Issuing:** `options.issue_directly` numbers and issues the invoice in the same call. Submission to the AEAT is asynchronous, so `verifactu.submission_status` comes back as `PENDING`: a 2xx means the invoice was accepted for submission, not that the AEAT has registered it. If the number the series would assign is already used by another invoice of the same company, in this series or in another one, it fails with `400 SERIES_NUMBER_COLLISION` without issuing anything or consuming a number: the series needs review, so contact support. - **Document type:** `type` chooses the document. A `PROFORMA` is non-fiscal — it is born `ACTIVE`, numbered `PRO-...` from its own non-fiscal series, and ignores `issue_directly`. - **Related:** to copy an existing invoice into a new draft, use `POST …/invoices/derivations`, which carries neither `type`, nor `recipient`, nor `lines`. ## POST /v1/companies/{company_id}/invoices **Create an invoice** Creates an invoice for this company. The issuer data comes from the company in the path, and the document is created as a draft unless you ask for it to be issued. - **Issuing:** `options.issue_directly` numbers and issues the invoice in the same call. Submission to the AEAT is asynchronous, so `verifactu.submission_status` comes back as `PENDING`: a 2xx means the invoice was accepted for submission, not that the AEAT has registered it. If the number the series would assign is already used by another invoice of the same company, in this series or in another one, it fails with `400 SERIES_NUMBER_COLLISION` without issuing anything or consuming a number: the series needs review, so contact support. - **Document type:** `type` chooses the document. A `PROFORMA` is non-fiscal — it is born `ACTIVE`, numbered `PRO-...` from its own non-fiscal series, and ignores `issue_directly`. - **Related:** to copy an existing invoice into a new draft, use `POST …/invoices/derivations`, which carries neither `type`, nor `recipient`, nor `lines`. ### Authentication Accepts any of: - `ApiKeyAuth` (HTTP bearer, token format `beel_sk_*`) ### Parameters - **company_id** (required) in path `string`: Unique identifier (UUID) of the company the operation acts on — its identifier, not its NIF. It is the only source of context: the account that owns it is derived from it, and the `BeeL-Active-Company` header plays no part. A company you do not reach answers `403`, and so does a company that does not exist, so the existence of a company in another account is never disclosed. - **Idempotency-Key** (optional) in header `string`: Idempotency key to prevent duplicates in sensitive operations. - Any unique client-generated string (e.g. an order id). A UUID also works but is not required - Allowed characters: letters, digits, `_` and `-` (max 255 chars) - Retrying with the same key replays the first response when it was a success (2xx) or a server error (5xx): same status and body, plus the header `Idempotency-Replay: true`. After a 5xx, check whether the operation took effect before retrying with a **new** key - A 4xx is not stored: the key is released, so the corrected request can reuse it - Stored responses expire 24 hours after processing The key is scoped per user and environment, and bound to the request body, so retrying after a network timeout replays the stored response instead of repeating the operation. | Status | Code | When | |---|---|---| | `400` | `INVALID_IDEMPOTENCY_KEY` | The key breaks the format rules above. | | `409` | `IDEMPOTENCY_KEY_PROCESSING` | The first request is still in flight. Wait for the `Retry-After` seconds (2) and retry with the same key. | | `409` | `IDEMPOTENCY_KEY_MISMATCH` | The key was already used with a **different** body. Use a new key. | - **wait_for_pdf** (optional) in query `boolean` (default: false): Same flag as `options.wait_for_pdf`. Only applies when the invoice is issued in this call (`options.issue_directly: true`). ### Request Body Required. **Content `application/json`:** - **type** (required): Invoice type to create. `CORRECTIVE` is **not** accepted here: a corrective invoice is always created from the invoice it corrects, via `POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`, which is where its rectification type and VeriFactu code (R1–R5) are declared. - **series_id** `string` (uuid): Invoicing series. It must be a series of the invoice's type: a series numbers only documents of its own type (RD 1619/2012, arts. 6.1.a and 7.1.a), otherwise `422 SERIES_INCOMPATIBLE_DOC_TYPE`. If omitted, the company's default series of that type is used; the `SIMPLIFIED` one is created on first use if the company has none, while a missing `STANDARD` default fails with `422 SERIES_DEFAULT_NOT_FOUND`. (example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890") - **operation_date** `string` (date): Date when the operation actually occurred. Optional. Use when invoicing for a past operation (e.g., services delivered last month but invoiced this month). **Must be today or a past date**, and not more than twenty years before today (AEAT does not accept an older one): an older date answers `422 OPERATION_DATE_TOO_OLD`, on creation and again on issue. If omitted, the operation date is assumed to be the same as the issue date (today). The `issue_date` is not an input: BeeL sets it to the day the invoice is issued. To issue an invoice on a future date, create a draft and use `POST /v1/invoices/{invoice_id}/schedule`. (example: "2025-01-10") - **due_date** `string` (date): Payment due date. If not specified, calculated according to payment method. **Must be the same as or after the issue date (today).** (example: "2025-02-14") - **valid_until** `string` (date): Offer validity date. Only rendered on PROFORMA invoices; on any other invoice type the field is inert (accepted and stored, but never shown on the document). Optional and purely informational — nothing is triggered automatically when it passes. Not to be confused with `due_date` (payment due date). (example: "2025-02-28") - **recipient** (required) `Recipient`: Invoice recipient: either a registered customer (`customer_id`) or the recipient's data inline (`legal_name`, `nif`, `address`…), never both. Sending `customer_id` together with any other recipient field returns 422 `RECIPIENT_CUSTOMER_AND_DATA_EXCLUSIVE`, on create and on edit. All fields are optional at schema level, but for an ad-hoc recipient (no customer_id) on non-SIMPLIFIED invoices the API requires legal_name, address and nif (or alternative_id); omitting the address returns 422 RECIPIENT_ADDRESS_REQUIRED. - **lines** (required) `array[object]`: No description - **description** `string`: Description of invoiced concept. Required for NORMAL lines; optional for SUPLIDO lines (may be empty or absent). (example: "Web application development - Sprint 1") - **quantity** (required) `number`: Product/service quantity (can be negative for franchises or discounts) (example: 40) - **unit** `string`: No description (example: "hours") - **unit_price** `number`: Unit price before taxes. `0` is accepted (a discount granted before or simultaneously with the sale, e.g. a free introductory month). Supports up to 4 decimal places for micro-pricing (e.g., €0.0897/unit for labels, packaging). (example: 50) - **total_excluding_tax** `number`: Declared line total excluding taxes (total-declared mode, e.g. 300 units invoiced for exactly 1.00). The taxable base of the line is EXACTLY this amount — it is never recalculated from the unit price. The unit price becomes derived and informational (`total / quantity`, 4 decimals). Each line must carry exactly one of `unit_price`, `total_excluding_tax` or `total_including_tax` (anything else is rejected with `LINE_UNIT_PRICE_XOR_DECLARED_TOTAL`). Incompatible with `discount_percentage` (`LINE_DECLARED_TOTAL_FORBIDS_DISCOUNT`): any discount is already included in the declared total. Can be negative in corrective invoices. (example: 1) - **total_including_tax** `number`: Declared line total including taxes (tax-inclusive total-declared mode): what the customer paid for this line — taxable base + VAT + equivalence surcharge. IRPF withholding is NOT part of it (it is a retention, not price; it is computed on the derived base as usual). The engine works the breakdown backwards from the unrounded base (`base_raw = total / (1 + vat + surcharge)`, DGT V1919-18) so the rounded amounts add up to the declared total exactly (e.g. 100.00 at 21% → 82.64 + 17.36 = 100.00). On exempt or 0% lines it is equivalent to `total_excluding_tax` (base = total, quota 0). Each line must carry exactly one of `unit_price`, `total_excluding_tax` or `total_including_tax` (anything else is rejected with `LINE_UNIT_PRICE_XOR_DECLARED_TOTAL`). Incompatible with `discount_percentage` (`LINE_DECLARED_TOTAL_FORBIDS_DISCOUNT`). Can be negative in corrective invoices. (example: 100) - **discount_percentage** `number`: Discount percentage applied (0-100) (example: 10) - **main_tax**: Main tax of the line: regime (IVA/IGIC/IPSI/OTHER), percentage and regime key. **Mandatory on `NORMAL` lines.** It is never defaulted: omitting it is rejected with `422 LINE_MAIN_TAX_REQUIRED`, and is never filled in from the company's `default_main_tax` — that setting is a UI prefill, not an API default, because which tax a line bears is a fiscal decision that drives the VeriFactu breakdown and the tax printed on the invoice. **Forbidden on `SUPLIDO` lines**, which are payments made on behalf of the client and sit outside VAT (art. 78.Tres.3 LIVA): sending one is rejected with `422 LINE_SUPLIDO_MUST_HAVE_NO_TAX`. That conditional obligation is why the field is not listed under `required`: OpenAPI 3.0 cannot express "required unless `line_type` is `SUPLIDO`". A 0 % under IVA or IPSI is not a rate but the exemption sentinel and needs an `exemption_reason`; see `TaxInfo`. - **equivalence_surcharge_rate**: Equivalence surcharge rate for this line. **Default behaviour:** if omitted and the company has `apply_equivalence_surcharge: true` in its tax configuration, the line inherits the surcharge — and its percentage is a legal function of the line's VAT rate, not the configured default: 21 ↔ 5.2, 10 ↔ 1.4, 5 ↔ 0.62, 4 ↔ 0.5 (the pairs enumerated by `EquivalenceSurchargePercentage`). A company configured with `default_equivalence_surcharge: 5.2` therefore produces 1.4 on a 10% line, not 5.2. **The inheritance also rewrites the line's `regime_key` from `01` to `18`** (special regime for equivalence surcharge). This is deliberate: a surcharge and general regime `01` are fiscally incoherent, so the line comes back as `18` even if `01` was sent. To issue a line **without** surcharge under such a company, send `equivalence_surcharge_rate: 0` explicitly — exactly as with `irpf_rate`: the `01` regime key is then respected and no surcharge is applied. Sending an explicit rate greater than 0 together with `regime_key: "01"` is **not** rejected: the very same rewrite applies and the line comes back as `18`. **Any other regime with a surcharge is rejected** with `422 SURCHARGE_REQUIRES_REGIME`. Only the general regime `01` **rewrites**; REBU (`03`), exports (`02`), OSS (`17`)… never do, because a surcharge under them is fiscally invalid — an error to surface, not a shorthand to normalise. - **irpf_rate**: IRPF withholding rate for this line. **Default behaviour:** if omitted, the line inherits the account's default IRPF rate (configured in the tax profile, e.g. 15%). To issue a line **without** withholding you must send `irpf_rate: 0` explicitly. On SIMPLIFIED invoices (F2) IRPF withholding is **not allowed** (AEAT forbids it on F2): sending an `irpf_rate` other than 0 is **rejected** with `SIMPLIFICADA_FORBIDS_IRPF` — it is not coerced to 0. Omit the field or send `irpf_rate: 0` on F2 lines. On all other invoice types an explicit value is always respected. The rate must be one the issuer can bear (see `WithholdingOptions` in the tax configuration). No entity pays IRPF: a legal person or a permanent establishment (NIF starting with `A`, `B`, `C`, `D`, `F`, `G`, `Q`, `R`, `U` or `W`) only accepts `0`, `19`, `24` and `9.5` (rents in Ceuta and Melilla), a non-resident entity (`N`) `0`, `19` and `24`, and the State, an Autonomous Community or a local entity (`S`, `P`) only `0`; any other rate is rejected with `IRPF_RATE_NOT_FOR_CORPORATE_ISSUER`. `9.5` from an individual is rejected with `IRPF_RATE_ONLY_FOR_CORPORATE_ISSUER`: under IRPF the Ceuta and Melilla reduced rates are `6`, `2.8` and `7.6`. Checked on creation, on edit and again on issue; corrective invoices are not checked: they correct by differences what the original carried. - **exemption_reason** `ExemptionReason`: Tax exemption reason code per the Spanish VAT Law (Ley 37/1992, LIVA), with the VeriFactu code each one is reported as. - `EXENTA_ART_20`: exempt, art. 20 (domestic operations such as medical, educational, cultural and financial services, or housing rentals). E1. - `EXENTA_ART_21`: exempt, art. 21 (exports of goods). E2. - `EXENTA_ART_22`: exempt, art. 22 (operations treated as exports). E3. - `EXENTA_ART_24`: exempt, art. 24 (free zones, warehouses and customs regimes). E4. - `EXENTA_ART_25`: exempt, art. 25 (intra-community supplies of goods). E5. - `EXENTA_ART_26`: exempt, art. 26 (intra-community acquisitions of goods). It exempts the buyer's acquisition, not a supply the seller invoices, so an invoice line that carries it is rejected with `EXEMPTION_NOT_FOR_ISSUED_INVOICE`; a supply to another Member State is `EXENTA_ART_25`. - `NO_SUJETA_ART_7_9`: not subject under art. 7 (such as the transfer of a business as a going concern, art. 7.1º). N1. - `NO_SUJETA_LOCALIZACION`: not subject by the place-of-supply rules (intra-community or non-EU services, arts. 69 and 70). N2. - `ISP_ART_84_2_A` … `ISP_ART_84_2_F`: reverse charge (the invoice states «inversión del sujeto pasivo»), art. 84.Uno.2.º letters a) (supplier not established in Spain), b) (unwrought or semi-finished gold), c) (scrap, waste and recovery materials, plastic, paper, cardboard, glass and textile waste, and semi-finished non-ferrous metal products), d) (greenhouse gas emission allowances), e) (certain real estate supplies: in insolvency proceedings, with the exemption waived, or enforcing a security) and f) (construction or renovation works). S2. - `ISP_ART_84_2_G`: reverse charge of letter g) (silver, platinum, palladium, mobile phones, consoles, laptops and tablets). The law requires these supplies to be invoiced in a special series, so an invoice line that carries it is rejected with `REVERSE_CHARGE_CASE_NOT_SUPPORTED`. - `EXENTA_ART_140`: investment gold exemption, art. 140 bis (usually with `regime_key` `04`). E6. - `REGIMEN_ART_129` (agriculture, livestock and fishing, arts. 124 to 134 bis), `REGIMEN_ART_135` (second-hand goods, art and antiques), `REGIMEN_ART_141` (travel agencies), `REGIMEN_ART_154` (equivalence surcharge) and `REGIMEN_ART_163_DECIES` (cash basis, arts. 163 decies to 163 sexiesdecies): operations of special regimes, which VeriFactu identifies by the regime key rather than by an exemption code. An invoice line that carries one is rejected with `EXEMPTION_REGIME_NOT_SUPPORTED_IN_VERIFACTU`; declare the regime with `regime_key` instead. - `OTRO`: any other provision. Requires the text in `exemption_reason_text`. E6. - **exemption_reason_text** `string`: Custom exemption text. Only used when exemption_reason is OTRO. - **line_type**: Fiscal line type. Defaults to `NORMAL`. Use `SUPLIDO` for payments on behalf of the final client (art. 78.Tres.3 LIVA). Requires `source_invoice_reference`. - **source_invoice_reference** `string`: Reference to the original invoice issued by the third party in the client's name. Required when `line_type=SUPLIDO`. - **source_invoice_ids** `array[string]`: Ids of the issued invoices that make up the SUPLIDO. They may belong to the issuing account or to accounts it manages with VIEW access. Their sum is the amount (never typed). Audit traceability. - **payment_info** `PaymentInfo` - **notes** `string`: No description (example: "Payment by bank transfer. Includes technical support for 30 days.") - **external_ref**: This field was previously named `external_reference`. The old name is still accepted as an alias for backwards compatibility and will be withdrawn in a future major version — send `external_ref`. - **metadata** `InvoiceMetadata`: Your own key/value pairs to cross-reference this invoice with records in your system (order ids, tenants, internal codes). Namespace them to avoid clashing with the system keys BeeL adds on payment-generated invoices. - **options** `InvoiceProcessingOptions`: Controls how the invoice is processed after creation. All fields default to `false` if not specified. VeriFactu is **not** an option here: whether an invoice is registered with AEAT is a fact of the tax identity (NIF x environment), resolved at issue time against the company's regime. See `verifactu.enabled` in the invoice response for what was applied. **Common combinations:** - Draft (default): omit `options` or set all to `false` - Issue immediately: `{ issue_directly: true }` - Issue + wait for PDF: `{ issue_directly: true, wait_for_pdf: true }` - Issue + send email: `{ issue_directly: true, send_automatically: true }` - Full automation: `{ issue_directly: true, wait_for_pdf: true, send_automatically: true, email_config: { ... } }` **Example `basic_invoice`** — Basic ordinary invoice: ```json { "type": "STANDARD", "recipient": { "customer_id": "123e4567-e89b-12d3-a456-426614174000" }, "lines": [ { "description": "Corporate website development", "quantity": 40, "unit": "hours", "unit_price": 37.5, "discount_percentage": 0, "main_tax": { "type": "IVA", "percentage": 21, "regime_key": "01" } } ], "payment_info": { "method": "BANK_TRANSFER", "iban": "ES9121000418450200051332", "payment_term_days": 30 }, "notes": "Payment via bank transfer" } ``` **Example `adhoc_invoice`** — Invoice with ad-hoc customer: ```json { "type": "STANDARD", "recipient": { "legal_name": "Comercial Martínez SL", "nif": "B87654321", "email": "contacto@comercialmartinez.es", "phone": "+34912345678", "address": { "street": "Avenida de la Constitución", "number": "45", "floor": "3º B", "postal_code": "41001", "city": "Sevilla", "province": "Sevilla", "country": "España" } }, "lines": [ { "description": "Business strategic consulting", "quantity": 8, "unit": "hours", "unit_price": 125, "discount_percentage": 0, "main_tax": { "type": "IVA", "percentage": 21, "regime_key": "01" } }, { "description": "Executive report preparation", "quantity": 1, "unit": "document", "unit_price": 500, "discount_percentage": 0, "main_tax": { "type": "IVA", "percentage": 21, "regime_key": "01" } } ], "payment_info": { "method": "BANK_TRANSFER", "iban": "ES9121000418450200051332", "payment_term_days": 30 }, "notes": "Invoice for consulting services for the month of January.\nIncludes 8 hours of consulting and report preparation.\n" } ``` **Example `issue_directly`** — Create, issue directly, and send by email: ```json { "type": "STANDARD", "recipient": { "customer_id": "123e4567-e89b-12d3-a456-426614174000" }, "lines": [ { "description": "Monthly web application maintenance", "quantity": 1, "unit": "month", "unit_price": 850, "discount_percentage": 0, "main_tax": { "type": "IVA", "percentage": 21, "regime_key": "01" }, "irpf_rate": 15 } ], "payment_info": { "method": "DIRECT_DEBIT", "iban": "ES9121000418450200051332" }, "options": { "issue_directly": true, "wait_for_pdf": true, "send_automatically": true } } ``` **Example `custom_email`** — Create invoice with custom email recipients: ```json { "type": "STANDARD", "due_date": "2025-02-26", "recipient": { "legal_name": "Acme Corporation SL", "nif": "B12345674", "email": "info@acme.es", "address": { "street": "Calle Gran Vía", "number": "42", "floor": "5º", "postal_code": "28013", "city": "Madrid", "province": "Madrid", "country": "España" } }, "lines": [ { "description": "Mobile application development - Phase 1", "quantity": 80, "unit": "hours", "unit_price": 65, "main_tax": { "type": "IVA", "percentage": 21, "regime_key": "01" }, "irpf_rate": 15 }, { "description": "Application UX/UI design", "quantity": 20, "unit": "hours", "unit_price": 55, "main_tax": { "type": "IVA", "percentage": 21, "regime_key": "01" }, "irpf_rate": 15 } ], "payment_info": { "method": "BANK_TRANSFER", "iban": "ES9121000418450200051332", "payment_term_days": 30 }, "notes": "Project APP-2025. Includes source code and technical documentation.", "metadata": { "project_code": "APP-2025-001", "purchase_order": "PO-ACME-2025-042" }, "options": { "issue_directly": true, "wait_for_pdf": true, "send_automatically": true, "email_config": { "recipients": [ "facturas@acme.es", "pedro.garcia@acme.es", "maria.lopez@acme.es" ], "cc": [ "contabilidad@miempresa.com", "gestor@asesoria.es" ], "subject": "Invoice project APP-2025 - Mobile application development", "message": "Dear Acme Corporation team,\n\nPlease find attached the invoice corresponding to the first phase\nof the mobile application development as agreed.\n\nPayment is due within 30 days. For any questions,\nplease do not hesitate to contact us.\n\nKind regards.\n" } } } ``` **Example `simplified_under_3000`** — Simplified invoice without NIF under 3000 EUR: ```json { "type": "SIMPLIFIED", "recipient": {}, "lines": [ { "description": "Menú del día", "quantity": 2, "unit": "unit", "unit_price": 14.5, "main_tax": { "type": "IVA", "percentage": 10, "regime_key": "01" } } ], "options": { "issue_directly": true } } ``` **Example `standard_spanish_b2b`** — Standard B2B invoice - Spanish business customer: ```json { "type": "STANDARD", "due_date": "2026-06-19", "recipient": { "legal_name": "ACCIONA SA", "nif": "A08001851", "address": { "street": "Avenida de Europa", "number": "18", "postal_code": "28108", "city": "Alcobendas", "province": "Madrid", "country": "España", "country_code": "ES" } }, "lines": [ { "description": "Consultoría de arquitectura — Sprint mayo", "quantity": 40, "unit": "hours", "unit_price": 75, "main_tax": { "type": "IVA", "percentage": 21, "regime_key": "01" } } ], "payment_info": { "method": "BANK_TRANSFER", "iban": "ES9121000418450200051332", "payment_term_days": 30 }, "options": { "issue_directly": true } } ``` **Example `standard_multiple_vat`** — Standard invoice with multiple VAT rates: ```json { "type": "STANDARD", "recipient": { "legal_name": "ACCIONA SA", "nif": "A08001851", "address": { "street": "Calle Cava Baja", "number": "35", "postal_code": "28005", "city": "Madrid", "province": "Madrid", "country": "España", "country_code": "ES" } }, "lines": [ { "description": "Vino reserva (caja 6 botellas)", "quantity": 4, "unit": "box", "unit_price": 90, "main_tax": { "type": "IVA", "percentage": 21, "regime_key": "01" } }, { "description": "Servicio de catering — menú degustación", "quantity": 25, "unit": "menu", "unit_price": 32, "main_tax": { "type": "IVA", "percentage": 10, "regime_key": "01" } }, { "description": "Pan artesano", "quantity": 50, "unit": "unit", "unit_price": 1.2, "main_tax": { "type": "IVA", "percentage": 4, "regime_key": "01" } } ], "options": { "issue_directly": true } } ``` **Example `line_by_declared_total_out_of_range`** — Declared total over a minimal quantity (rejected, 422): ```json { "type": "STANDARD", "recipient": { "customer_id": "123e4567-e89b-12d3-a456-426614174000" }, "lines": [ { "description": "Consulting", "quantity": 0.01, "total_excluding_tax": 99999999.99, "main_tax": { "type": "IVA", "percentage": 21 } } ] } ``` **Example `standard_irpf`** — Standard invoice with IRPF withholding (professional services): ```json { "type": "STANDARD", "recipient": { "legal_name": "ACCIONA SA", "nif": "A08001851", "address": { "street": "Avenida de Europa", "number": "18", "postal_code": "28108", "city": "Alcobendas", "province": "Madrid", "country": "España", "country_code": "ES" } }, "lines": [ { "description": "Servicios de abogacía — asesoramiento mercantil", "quantity": 12, "unit": "hours", "unit_price": 120, "main_tax": { "type": "IVA", "percentage": 21, "regime_key": "01" }, "irpf_rate": 15 } ], "options": { "issue_directly": true } } ``` **Example `standard_recargo`** — Standard invoice with equivalence surcharge (RECAREGO): ```json { "type": "STANDARD", "recipient": { "legal_name": "ACCIONA SA", "nif": "A08001851", "address": { "street": "Calle del Comercio", "number": "56", "postal_code": "08001", "city": "Barcelona", "province": "Barcelona", "country": "España", "country_code": "ES" } }, "lines": [ { "description": "Lote de auriculares inalámbricos para reventa", "quantity": 30, "unit": "unit", "unit_price": 45, "main_tax": { "type": "IVA", "percentage": 21, "regime_key": "18" }, "equivalence_surcharge_rate": 5.2 } ], "options": { "issue_directly": true } } ``` **Example `standard_eu_goods_e5`** — B2B intra-EU goods (E5) - exempt Art. 25: ```json { "type": "STANDARD", "recipient": { "legal_name": "Berliner Industrie GmbH", "alternative_id": { "type": "NIF_IVA", "number": "DE123456789", "country_code": "DE" }, "address": { "street": "Friedrichstraße", "number": "200", "postal_code": "10117", "city": "Berlin", "province": "Berlin", "country": "Alemania", "country_code": "DE" } }, "lines": [ { "description": "Componentes electrónicos — pedido EU-2026-0042", "quantity": 500, "unit": "unit", "unit_price": 8.4, "main_tax": { "type": "IVA", "percentage": 0, "regime_key": "01" }, "exemption_reason": "EXENTA_ART_25" } ], "options": { "issue_directly": true } } ``` **Example `standard_eu_services_n2`** — B2B intra-EU services (N2) - no sujeta localization: ```json { "type": "STANDARD", "recipient": { "legal_name": "Berliner Industrie GmbH", "alternative_id": { "type": "NIF_IVA", "number": "DE123456789", "country_code": "DE" }, "address": { "street": "Friedrichstraße", "number": "200", "postal_code": "10117", "city": "Berlin", "province": "Berlin", "country": "Alemania", "country_code": "DE" } }, "lines": [ { "description": "Consultoría de arquitectura cloud", "quantity": 60, "unit": "hours", "unit_price": 110, "main_tax": { "type": "IVA", "percentage": 0, "regime_key": "01" }, "exemption_reason": "NO_SUJETA_LOCALIZACION" } ], "options": { "issue_directly": true } } ``` **Example `standard_b2c_oss_over`** — B2C OSS (One-Stop-Shop) over threshold: ```json { "type": "STANDARD", "recipient": { "legal_name": "Anna Schmidt", "alternative_id": { "type": "PASSPORT", "number": "C0HJ4P9DT", "country_code": "DE" }, "address": { "street": "Müllerstraße", "number": "47", "postal_code": "80469", "city": "München", "province": "Bayern", "country": "Alemania", "country_code": "DE" } }, "lines": [ { "description": "Suscripción anual plataforma SaaS", "quantity": 1, "unit": "year", "unit_price": 480, "main_tax": { "type": "IVA", "percentage": 0, "regime_key": "17" }, "exemption_reason": "NO_SUJETA_LOCALIZACION" } ], "options": { "issue_directly": true } } ``` **Example `standard_b2c_oss_under`** — B2C under OSS threshold: ```json { "type": "STANDARD", "recipient": { "legal_name": "Anna Schmidt", "alternative_id": { "type": "PASSPORT", "number": "C0HJ4P9DT", "country_code": "DE" }, "address": { "street": "Müllerstraße", "number": "47", "postal_code": "80469", "city": "München", "province": "Bayern", "country": "Alemania", "country_code": "DE" } }, "lines": [ { "description": "Curso online — fotografía digital", "quantity": 1, "unit": "course", "unit_price": 149, "main_tax": { "type": "IVA", "percentage": 21, "regime_key": "01" } } ], "options": { "issue_directly": true } } ``` **Example `standard_export_e2`** — Export of goods to non-EU (E2) - exempt Art. 21: ```json { "type": "STANDARD", "recipient": { "legal_name": "Northeast Imports Inc.", "alternative_id": { "type": "PASSPORT", "number": "551234567", "country_code": "US" }, "address": { "street": "5th Avenue", "number": "725", "postal_code": "10022", "city": "New York", "province": "NY", "country": "Estados Unidos", "country_code": "US" } }, "lines": [ { "description": "Aceite de oliva virgen extra — palet 480 botellas", "quantity": 1, "unit": "pallet", "unit_price": 3850, "main_tax": { "type": "IVA", "percentage": 0, "regime_key": "02" }, "exemption_reason": "EXENTA_ART_21" } ], "options": { "issue_directly": true } } ``` **Example `standard_services_noeu`** — Services to non-EU (N2) - no sujeta: ```json { "type": "STANDARD", "recipient": { "legal_name": "Northeast Imports Inc.", "alternative_id": { "type": "PASSPORT", "number": "551234567", "country_code": "US" }, "address": { "street": "5th Avenue", "number": "725", "postal_code": "10022", "city": "New York", "province": "NY", "country": "Estados Unidos", "country_code": "US" } }, "lines": [ { "description": "Diseño de identidad de marca", "quantity": 1, "unit": "project", "unit_price": 6500, "main_tax": { "type": "IVA", "percentage": 0, "regime_key": "01" }, "exemption_reason": "NO_SUJETA_LOCALIZACION" } ], "options": { "issue_directly": true } } ``` **Example `standard_exempt_art20`** — Exempt operation (E1) - educational/medical Art. 20: ```json { "type": "STANDARD", "recipient": { "legal_name": "Academia Cervantes SL", "nif": "A08001851", "address": { "street": "Calle Princesa", "number": "27", "postal_code": "28008", "city": "Madrid", "province": "Madrid", "country": "España", "country_code": "ES" } }, "lines": [ { "description": "Clases particulares de matemáticas — trimestre primavera", "quantity": 36, "unit": "hours", "unit_price": 28, "main_tax": { "type": "IVA", "percentage": 0, "regime_key": "01" }, "exemption_reason": "EXENTA_ART_20", "exemption_reason_text": "Operación exenta de IVA según Art. 20.Uno.10º LIVA (enseñanza)" } ], "options": { "issue_directly": true } } ``` **Example `standard_igic`** — IGIC (Canary Islands) 7% instead of IVA: ```json { "type": "STANDARD", "recipient": { "legal_name": "Importaciones Atlántico SL", "nif": "A08001851", "address": { "street": "Calle León y Castillo", "number": "200", "postal_code": "35004", "city": "Las Palmas de Gran Canaria", "province": "Las Palmas", "country": "España", "country_code": "ES" } }, "lines": [ { "description": "Mobiliario de oficina — sillas ergonómicas", "quantity": 10, "unit": "unit", "unit_price": 180, "main_tax": { "type": "IGIC", "percentage": 7, "regime_key": "01" } } ], "options": { "issue_directly": true } } ``` **Example `standard_not_subject`** — Not subject (N1) - Art. 7/9 LIVA: ```json { "type": "STANDARD", "recipient": { "legal_name": "Distribuciones Hermanas Pérez SL", "nif": "A08001851", "address": { "street": "Polígono Industrial San Isidro", "number": "12", "postal_code": "46980", "city": "Paterna", "province": "Valencia", "country": "España", "country_code": "ES" } }, "lines": [ { "description": "Muestras comerciales sin valor — catálogo 2026", "quantity": 50, "unit": "unit", "unit_price": 12, "main_tax": { "type": "IVA", "percentage": 0, "regime_key": "01" }, "exemption_reason": "NO_SUJETA_ART_7_9", "exemption_reason_text": "Entrega de muestras gratuitas (Art. 7.2º LIVA)" } ], "options": { "issue_directly": true } } ``` **Example `standard_isp_reverse`** — ISP reverse charge (S2) - Art. 84.2.f LIVA: ```json { "type": "STANDARD", "recipient": { "legal_name": "Promociones Inmobiliarias del Mediterráneo SA", "nif": "A46789012", "address": { "street": "Gran Vía Marqués del Turia", "number": "47", "postal_code": "46005", "city": "Valencia", "province": "Valencia", "country": "España", "country_code": "ES" } }, "lines": [ { "description": "Ejecución de obra — instalación eléctrica edificio Torre Norte", "quantity": 1, "unit": "project", "unit_price": 42000, "main_tax": { "type": "IVA", "percentage": 0, "regime_key": "01" }, "exemption_reason": "ISP_ART_84_2_F", "exemption_reason_text": "Inversión del sujeto pasivo — Art. 84.Uno.2º.f LIVA (ejecución de obra)" } ], "options": { "issue_directly": true } } ``` **Example `standard_rebu`** — REBU special regime (used goods, art, antiques): ```json { "type": "STANDARD", "recipient": { "legal_name": "Galería de Arte Velázquez SL", "nif": "A08001851", "address": { "street": "Calle de Jorge Juan", "number": "12", "postal_code": "28001", "city": "Madrid", "province": "Madrid", "country": "España", "country_code": "ES" } }, "lines": [ { "description": "Pintura óleo siglo XIX — REBU (margen): venta 3 000 € / coste 2 000 €", "quantity": 1, "unit": "unit", "unit_price": 826.45, "main_tax": { "type": "IVA", "percentage": 21, "regime_key": "03" } } ], "notes": "Régimen especial de bienes usados (Art. 135 LIVA). Base imponible calculada sobre el margen.", "options": { "issue_directly": true } } ``` ### Responses #### 201: Invoice created successfully **Headers:** - `Location` `string`: URI of the created resource — its canonical GET (`/v1/companies/{company_id}/...` or `/v1/accounts/{account_id}/...`). **Content `application/json`:** - **success** (required) `boolean`: No description (example: true) - **data** (required): The payload. An object for a single resource; an object holding the named collection (and its `pagination`) for a listing. Never a bare array at this level in v1. - **meta** `ResponseMeta` - **data** `Invoice`: A stored invoice. Being stored is what makes `id`, `created_at` and `updated_at` part of its contract: every one of them always travels. **Example `created_success`** — Invoice created (201): ```json { "success": true, "data": { "id": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "invoice_number": null, "number": null, "type": "STANDARD", "status": "DRAFT", "issue_date": "2025-01-20", "issuer": { "legal_name": "Tu Empresa SL", "nif": "B12345674", "address": { "street": "Calle Ejemplo", "number": "123", "postal_code": "28001", "city": "Madrid", "province": "Madrid", "country": "España" } }, "series": { "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890", "code": "A" }, "recipient": { "customer_id": "123e4567-e89b-12d3-a456-426614174000", "legal_name": "Cliente Ejemplo SL", "nif": "B87654321", "email": "cliente@ejemplo.com", "address": { "street": "Avenida Cliente", "number": "456", "postal_code": "28013", "city": "Madrid", "province": "Madrid", "country": "España" } }, "lines": [ { "description": "Corporate website development", "quantity": 40, "unit": "hours", "unit_price": 37.5, "discount_percentage": 0, "taxable_base": 1500, "main_tax": { "type": "IVA", "percentage": 21, "regime_key": "01" }, "line_total": 1815 } ], "totals": { "taxable_base": 1500, "total_vat": 315, "total_irpf": 0, "total_equivalence_surcharge": 0, "vat_breakdown": [ { "type": 21, "base": 1500, "amount": 315 } ], "invoice_total": 1815 }, "payment_info": { "method": "BANK_TRANSFER", "payment_term_days": 30 }, "notes": "Payment via bank transfer", "verifactu": { "enabled": false }, "created_at": "2025-01-20T10:30:00Z", "updated_at": "2025-01-20T10:30:00Z" }, "meta": { "timestamp": "2025-01-20T10:30:00Z", "request_id": "c1d2e3f4-a5b6-4c7d-8e9f-0a1b2c3d4e5f" } } ``` #### 400: One of: - `INVALID_JSON_FORMAT`: the body is not valid JSON, or a property has the wrong type or format. `details` follows `FieldDeserializationError`: `field`, `invalid_value` and, where there is one, `expected_format`. - `SIMPLIFIED_INVOICE_EXCEEDS_LEGAL_LIMIT`: a `SIMPLIFIED` invoice whose total, VAT included, is above 3,000€. The same answer when the invoice is created and when an edit takes it over the cap, whether the edit changes the lines or changes `type` to `SIMPLIFIED`. Issue a `STANDARD` invoice with the customer identified instead. **Content `application/json`:** - **success** (required) `boolean`: No description (example: false) - **error** (required) `ErrorDetail` - **meta** `ResponseMeta` - **type** `string` (uri): Stable URI that identifies the problem type and where the integrator will find its documentation. (example: "https://docs.beel.es/errors/INVOICE_NO_LINES") - **title** `string`: Short summary of the problem type. Stable between occurrences of the same `type`. (example: "INVOICE_NO_LINES") - **detail** `string`: Specific message for this occurrence, localized according to `Accept-Language` (`es`, `en`, `ca`); defaults to English. Matches the legacy `error.message`. (example: "The invoice must have at least one line") - **instance** `string` (uri-reference): URI that identifies the specific occurrence of the problem — typically the path of the affected resource. (example: "/v1/invoices/abc-123") **Example `invalid_json_format`** — A property with the wrong format: ```json { "success": false, "error": { "code": "INVALID_JSON_FORMAT", "message": "The field 'due_date' has an invalid date format: '2026-03-04fds'. Expected format: YYYY-MM-DD.", "details": { "field": "due_date", "invalid_value": "2026-03-04fds", "expected_format": "YYYY-MM-DD" } }, "meta": { "timestamp": "2026-03-05T10:30:00Z", "request_id": "4bf92f3577b34da6a3ce929d0e0e4736" } } ``` **Example `error_simplified_exceeds_limit`** — Simplified invoice over 3,000€ (400): ```json { "success": false, "error": { "code": "SIMPLIFIED_INVOICE_EXCEEDS_LEGAL_LIMIT", "message": "Simplified invoices cannot exceed 3,000€ (VAT included). Current total: 4,235€. Reduce the amount or issue an ordinary invoice.", "details": {} }, "meta": { "timestamp": "2025-02-03T12:00:00Z", "request_id": "req_error_simpl001" } } ``` #### 401: Missing or invalid authentication. Like every other error, `message`/`detail` is localized according to `Accept-Language` (`es`, `en`, `ca`); defaults to English when the header is missing or asks for none of those. **Content `application/json`:** - **success** (required) `boolean`: No description (example: false) - **error** (required) `ErrorDetail` - **meta** `ResponseMeta` - **type** `string` (uri): Stable URI that identifies the problem type and where the integrator will find its documentation. (example: "https://docs.beel.es/errors/INVOICE_NO_LINES") - **title** `string`: Short summary of the problem type. Stable between occurrences of the same `type`. (example: "INVOICE_NO_LINES") - **detail** `string`: Specific message for this occurrence, localized according to `Accept-Language` (`es`, `en`, `ca`); defaults to English. Matches the legacy `error.message`. (example: "The invoice must have at least one line") - **instance** `string` (uri-reference): URI that identifies the specific occurrence of the problem — typically the path of the affected resource. (example: "/v1/invoices/abc-123") **Example:** ```json { "success": false, "error": { "code": "UNAUTHORIZED", "message": "Authentication is required to access this resource" }, "meta": { "timestamp": "2025-01-15T10:30:00Z", "request_id": "4bf92f3577b34da6a3ce929d0e0e4736" } } ``` #### 403: Your account does not own or manage this company, or does not hold the required access over it. A NIF that does not exist answers the same way. **Content `application/json`:** - **success** (required) `boolean`: No description (example: false) - **error** (required) `ErrorDetail` - **meta** `ResponseMeta` - **type** `string` (uri): Stable URI that identifies the problem type and where the integrator will find its documentation. (example: "https://docs.beel.es/errors/INVOICE_NO_LINES") - **title** `string`: Short summary of the problem type. Stable between occurrences of the same `type`. (example: "INVOICE_NO_LINES") - **detail** `string`: Specific message for this occurrence, localized according to `Accept-Language` (`es`, `en`, `ca`); defaults to English. Matches the legacy `error.message`. (example: "The invoice must have at least one line") - **instance** `string` (uri-reference): URI that identifies the specific occurrence of the problem — typically the path of the affected resource. (example: "/v1/invoices/abc-123") #### 409: Conflict. One of: - Idempotency key already processed, or duplicate invoice number. - `INVOICE_DUPLICATE_EXTERNAL_REFERENCE`: a live invoice with the same `external_ref` already exists. **Content `application/json`:** - **success** (required) `boolean`: No description (example: false) - **error** (required) `ErrorDetail` - **meta** `ResponseMeta` - **type** `string` (uri): Stable URI that identifies the problem type and where the integrator will find its documentation. (example: "https://docs.beel.es/errors/INVOICE_NO_LINES") - **title** `string`: Short summary of the problem type. Stable between occurrences of the same `type`. (example: "INVOICE_NO_LINES") - **detail** `string`: Specific message for this occurrence, localized according to `Accept-Language` (`es`, `en`, `ca`); defaults to English. Matches the legacy `error.message`. (example: "The invoice must have at least one line") - **instance** `string` (uri-reference): URI that identifies the specific occurrence of the problem — typically the path of the affected resource. (example: "/v1/invoices/abc-123") **Example `conflict`** — Conflict (409): ```json { "success": false, "error": { "code": "CLIENT_DUPLICATE", "message": "A client with this NIF already exists", "details": {} }, "meta": { "timestamp": "2025-01-20T10:00:00Z", "request_id": "d4d4d4d4-0004-4000-a000-000000000004" } } ``` #### 422: Validation error, or (when creating and issuing directly) the company/NIF is not ready to issue in this environment. In the latter case `error.code` is `EMISSION_NOT_READY` and `error.details.blockers[]` lists the reasons (`PROFILE_INCOMPLETE`, `COMPANY_NOT_ACTIVATED`, `ENV_MISMATCH`, `NIF_NOT_REGISTERED`, `NIF_REPRESENTATION_REQUIRED`). When a blocker is `PROFILE_INCOMPLETE`, `error.details.missing_fields[]` names which fields of the company's fiscal identity are still missing (`entity_type`, `legal_name`, `address`) — the same tokens the profile endpoints use. Separately: on a line priced by declared total (`total_excluding_tax` or `total_including_tax`) the unit price is not sent — it is derived as total ÷ quantity — so a quotient that does not fit the field storing it is rejected with `error.code` `LINE_UNIT_PRICE_OUT_OF_RANGE` and an `error.details` that follows `LineUnitPriceOutOfRangeDetails`: `field` names the offending line (`lines[0]`), not a `unit_price` you never sent, while `max` and `derived_unit_price` carry the limit and the quotient as JSON numbers, so they can be compared without parsing `error.message`. At issue time the generated number must also fit the AEAT invoice number: more than 60 characters answers `INVOICE_NUMBER_TOO_LONG`, a character outside printable ASCII or one of `"`, `'`, `<`, `>`, `=` answers `INVOICE_NUMBER_INVALID_CHARACTERS`. In both cases the invoice is not issued and the number is not used; issue it with another series, or fix the series code or format while the series has no issued invoices, and retry. When the invoice is recorded with VeriFactu, its tax breakdown must also fit one AEAT record: lines are grouped by tax, regime key, operation type, exemption, tax rate and equivalence surcharge rate, and more than 12 different groups answers `INVOICE_TAX_BREAKDOWN_TOO_LONG`, and a tax or surcharge rate with more than two decimals answers `INVOICE_TAX_RATE_TOO_MANY_DECIMALS`. The recipient's `legal_name` is recorded as it is on the invoice, so with VeriFactu it must be at most 120 characters: a longer one answers `FIELD_TOO_LONG`. BeeL. builds the record it will send before numbering and checks it against AEAT's validations: an invoice with nothing but disbursements (`SUPLIDO` lines) is not an invoice and answers `INVOICE_REQUIRES_AT_LEAST_ONE_NORMAL_LINE`, and any other record AEAT would reject answers the specific code or `VERIFACTU_RECORD_NOT_DECLARABLE`, with the AEAT section in its message. In all these cases the invoice is not issued and the number is not used. **Content `application/json`:** - **success** (required) `boolean`: No description (example: false) - **error** (required) `ErrorDetail` - **meta** `ResponseMeta` - **type** `string` (uri): Stable URI that identifies the problem type and where the integrator will find its documentation. (example: "https://docs.beel.es/errors/INVOICE_NO_LINES") - **title** `string`: Short summary of the problem type. Stable between occurrences of the same `type`. (example: "INVOICE_NO_LINES") - **detail** `string`: Specific message for this occurrence, localized according to `Accept-Language` (`es`, `en`, `ca`); defaults to English. Matches the legacy `error.message`. (example: "The invoice must have at least one line") - **instance** `string` (uri-reference): URI that identifies the specific occurrence of the problem — typically the path of the affected resource. (example: "/v1/invoices/abc-123") **Example `validation_error`** — Validation error (422): ```json { "success": false, "error": { "code": "VALIDATION_ERROR", "message": "The provided data is not valid.", "details": { "nif": "The field 'nif' cannot be empty", "lines": "The field 'lines' cannot be empty", "recipient.address.postal_code": "Contains invalid characters." } }, "meta": { "timestamp": "2025-01-20T10:00:00Z", "request_id": "c3c3c3c3-0003-4000-a000-000000000003" } } ``` **Example `error_invoice_empty_lines`** — Invoice without lines (422): ```json { "success": false, "error": { "code": "VALIDATION_ERROR", "message": "Invoice must have at least one line item", "details": { "lines": [ "Array must contain at least 1 element(s)" ] } }, "meta": { "timestamp": "2025-01-26T11:15:00Z", "request_id": "b1b1b1b1-0001-4000-a000-000000000010" } } ``` **Example `error_invoice_invalid_nif`** — Recipient tax id is not valid (422): ```json { "success": false, "error": { "code": "VALIDATION_ERROR", "message": "Invalid NIF format", "details": { "nif": [ "Invalid Spanish NIF format: B123INVALID" ] } }, "meta": { "timestamp": "2025-01-26T10:45:00Z", "request_id": "req_error_nif001" } } ``` **Example `error_invoice_required_fields`** — Required fields missing (422): ```json { "success": false, "error": { "code": "VALIDATION_ERROR", "message": "Multiple validation errors found", "details": { "issue_date": [ "Field is required" ], "recipient": { "nif": [ "Either 'nif' or 'alternative_id' must be provided" ], "address": { "postal_code": [ "Field is required" ], "city": [ "Field is required" ], "province": [ "Field is required" ] } }, "lines": { "0": { "unit_price": [ "Field is required" ] } } } }, "meta": { "timestamp": "2025-01-26T11:30:00Z", "request_id": "req_error_validation001" } } ``` **Example `error_simplified_identified_recipient`** — Simplified invoice with an identified recipient (422): ```json { "success": false, "error": { "code": "SIMPLIFIED_INVOICE_FORBIDS_IDENTIFIED_RECIPIENT", "message": "BeeL. does not issue simplified invoices with an identified recipient (NIF or alternative identifier). Issue an ordinary invoice instead.", "details": {} }, "meta": { "timestamp": "2025-02-03T12:05:00Z", "request_id": "req_error_simpl002" } } ``` **Example `error_derived_unit_price_out_of_range`** — Derived unit price out of range (422): ```json { "success": false, "error": { "code": "LINE_UNIT_PRICE_OUT_OF_RANGE", "message": "The unit price is out of the accepted range: the maximum is 99999999.9999 per unit", "details": { "field": "lines[0]", "max": 99999999.9999, "derived_unit_price": 9999999999 } }, "meta": { "timestamp": "2026-03-05T10:30:00Z", "request_id": "b1b1b1b1-0001-4000-a000-000000000011" } } ``` #### 429: Rate limit exceeded **Headers:** - `Retry-After` `integer`: Seconds until the rate limit resets - `RateLimit-Limit` `integer`: Maximum requests allowed in the window - `RateLimit-Remaining` `integer`: Remaining requests in the current window - `RateLimit-Reset` `integer`: Seconds until the current window resets **Content `application/json`:** - **success** (required) `boolean`: No description (example: false) - **error** (required) `ErrorDetail` - **meta** `ResponseMeta` - **type** `string` (uri): Stable URI that identifies the problem type and where the integrator will find its documentation. (example: "https://docs.beel.es/errors/INVOICE_NO_LINES") - **title** `string`: Short summary of the problem type. Stable between occurrences of the same `type`. (example: "INVOICE_NO_LINES") - **detail** `string`: Specific message for this occurrence, localized according to `Accept-Language` (`es`, `en`, `ca`); defaults to English. Matches the legacy `error.message`. (example: "The invoice must have at least one line") - **instance** `string` (uri-reference): URI that identifies the specific occurrence of the problem — typically the path of the affected resource. (example: "/v1/invoices/abc-123") **Example:** ```json { "success": false, "error": { "code": "RATE_LIMIT_EXCEEDED", "message": "Too many requests. Please try again in 60 seconds." }, "meta": { "timestamp": "2025-01-15T10:30:00Z", "request_id": "4bf92f3577b34da6a3ce929d0e0e4736" } } ``` #### 500: Internal server error **Content `application/json`:** - **success** (required) `boolean`: No description (example: false) - **error** (required) `ErrorDetail` - **meta** `ResponseMeta` - **type** `string` (uri): Stable URI that identifies the problem type and where the integrator will find its documentation. (example: "https://docs.beel.es/errors/INVOICE_NO_LINES") - **title** `string`: Short summary of the problem type. Stable between occurrences of the same `type`. (example: "INVOICE_NO_LINES") - **detail** `string`: Specific message for this occurrence, localized according to `Accept-Language` (`es`, `en`, `ca`); defaults to English. Matches the legacy `error.message`. (example: "The invoice must have at least one line") - **instance** `string` (uri-reference): URI that identifies the specific occurrence of the problem — typically the path of the affected resource. (example: "/v1/invoices/abc-123") **Example:** ```json { "success": false, "error": { "code": "INTERNAL_ERROR", "message": "Internal server error" }, "meta": { "timestamp": "2025-01-15T10:30:00Z", "request_id": "4bf92f3577b34da6a3ce929d0e0e4736" } } ``` #### default: Any status code the operation does not list above. Every operation declares it, so a generated client always has a branch to fall into and never loses the cause of a failure it did not anticipate. This is where the transport-level answers land — `405`, `406`, `415` and `429` — together with any status a future version of the API starts returning. All of them carry the same error envelope as the codes listed explicitly, so `error.code` is what tells them apart: switching on the status code alone is not enough. See «Transport-level errors» in the API description for when each one is produced. A `502` carrying `EXTERNAL_SERVICE_ERROR` also lands here: an outbound integration the operation depends on failed or did not answer in time. It is a transient condition — retry with the same `Idempotency-Key` where the operation accepts one. One exception to the envelope: a failure of the network edge that never reaches the application (`502`, `503`, `504`, `524`) is generated by Cloudflare and its body is not BeeL's — it may not even be JSON. Treat those as "no answer", and retry. **Content `application/json`:** - **success** (required) `boolean`: No description (example: false) - **error** (required) `ErrorDetail` - **meta** `ResponseMeta` - **type** `string` (uri): Stable URI that identifies the problem type and where the integrator will find its documentation. (example: "https://docs.beel.es/errors/INVOICE_NO_LINES") - **title** `string`: Short summary of the problem type. Stable between occurrences of the same `type`. (example: "INVOICE_NO_LINES") - **detail** `string`: Specific message for this occurrence, localized according to `Accept-Language` (`es`, `en`, `ca`); defaults to English. Matches the legacy `error.message`. (example: "The invoice must have at least one line") - **instance** `string` (uri-reference): URI that identifies the specific occurrence of the problem — typically the path of the affected resource. (example: "/v1/invoices/abc-123") **Example:** ```json { "success": false, "error": { "code": "UNSUPPORTED_MEDIA_TYPE", "message": "Unsupported media type: text/plain. Supported: application/json" }, "meta": { "timestamp": "2025-01-15T10:30:00Z", "request_id": "4bf92f3577b34da6a3ce929d0e0e4736" } } ``` --- # Related Schema Definitions ## CreateInvoiceRequest - **type** (required): Invoice type to create. `CORRECTIVE` is **not** accepted here: a corrective invoice is always created from the invoice it corrects, via `POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`, which is where its rectification type and VeriFactu code (R1–R5) are declared. - **series_id** `string` (uuid): Invoicing series. It must be a series of the invoice's type: a series numbers only documents of its own type (RD 1619/2012, arts. 6.1.a and 7.1.a), otherwise `422 SERIES_INCOMPATIBLE_DOC_TYPE`. If omitted, the company's default series of that type is used; the `SIMPLIFIED` one is created on first use if the company has none, while a missing `STANDARD` default fails with `422 SERIES_DEFAULT_NOT_FOUND`. (example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890") - **operation_date** `string` (date): Date when the operation actually occurred. Optional. Use when invoicing for a past operation (e.g., services delivered last month but invoiced this month). **Must be today or a past date**, and not more than twenty years before today (AEAT does not accept an older one): an older date answers `422 OPERATION_DATE_TOO_OLD`, on creation and again on issue. If omitted, the operation date is assumed to be the same as the issue date (today). The `issue_date` is not an input: BeeL sets it to the day the invoice is issued. To issue an invoice on a future date, create a draft and use `POST /v1/invoices/{invoice_id}/schedule`. (example: "2025-01-10") - **due_date** `string` (date): Payment due date. If not specified, calculated according to payment method. **Must be the same as or after the issue date (today).** (example: "2025-02-14") - **valid_until** `string` (date): Offer validity date. Only rendered on PROFORMA invoices; on any other invoice type the field is inert (accepted and stored, but never shown on the document). Optional and purely informational — nothing is triggered automatically when it passes. Not to be confused with `due_date` (payment due date). (example: "2025-02-28") - **recipient** (required) `Recipient`: Invoice recipient: either a registered customer (`customer_id`) or the recipient's data inline (`legal_name`, `nif`, `address`…), never both. Sending `customer_id` together with any other recipient field returns 422 `RECIPIENT_CUSTOMER_AND_DATA_EXCLUSIVE`, on create and on edit. All fields are optional at schema level, but for an ad-hoc recipient (no customer_id) on non-SIMPLIFIED invoices the API requires legal_name, address and nif (or alternative_id); omitting the address returns 422 RECIPIENT_ADDRESS_REQUIRED. - **lines** (required) `array[object]`: No description - **description** `string`: Description of invoiced concept. Required for NORMAL lines; optional for SUPLIDO lines (may be empty or absent). (example: "Web application development - Sprint 1") - **quantity** (required) `number`: Product/service quantity (can be negative for franchises or discounts) (example: 40) - **unit** `string`: No description (example: "hours") - **unit_price** `number`: Unit price before taxes. `0` is accepted (a discount granted before or simultaneously with the sale, e.g. a free introductory month). Supports up to 4 decimal places for micro-pricing (e.g., €0.0897/unit for labels, packaging). (example: 50) - **total_excluding_tax** `number`: Declared line total excluding taxes (total-declared mode, e.g. 300 units invoiced for exactly 1.00). The taxable base of the line is EXACTLY this amount — it is never recalculated from the unit price. The unit price becomes derived and informational (`total / quantity`, 4 decimals). Each line must carry exactly one of `unit_price`, `total_excluding_tax` or `total_including_tax` (anything else is rejected with `LINE_UNIT_PRICE_XOR_DECLARED_TOTAL`). Incompatible with `discount_percentage` (`LINE_DECLARED_TOTAL_FORBIDS_DISCOUNT`): any discount is already included in the declared total. Can be negative in corrective invoices. (example: 1) - **total_including_tax** `number`: Declared line total including taxes (tax-inclusive total-declared mode): what the customer paid for this line — taxable base + VAT + equivalence surcharge. IRPF withholding is NOT part of it (it is a retention, not price; it is computed on the derived base as usual). The engine works the breakdown backwards from the unrounded base (`base_raw = total / (1 + vat + surcharge)`, DGT V1919-18) so the rounded amounts add up to the declared total exactly (e.g. 100.00 at 21% → 82.64 + 17.36 = 100.00). On exempt or 0% lines it is equivalent to `total_excluding_tax` (base = total, quota 0). Each line must carry exactly one of `unit_price`, `total_excluding_tax` or `total_including_tax` (anything else is rejected with `LINE_UNIT_PRICE_XOR_DECLARED_TOTAL`). Incompatible with `discount_percentage` (`LINE_DECLARED_TOTAL_FORBIDS_DISCOUNT`). Can be negative in corrective invoices. (example: 100) - **discount_percentage** `number`: Discount percentage applied (0-100) (example: 10) - **main_tax**: Main tax of the line: regime (IVA/IGIC/IPSI/OTHER), percentage and regime key. **Mandatory on `NORMAL` lines.** It is never defaulted: omitting it is rejected with `422 LINE_MAIN_TAX_REQUIRED`, and is never filled in from the company's `default_main_tax` — that setting is a UI prefill, not an API default, because which tax a line bears is a fiscal decision that drives the VeriFactu breakdown and the tax printed on the invoice. **Forbidden on `SUPLIDO` lines**, which are payments made on behalf of the client and sit outside VAT (art. 78.Tres.3 LIVA): sending one is rejected with `422 LINE_SUPLIDO_MUST_HAVE_NO_TAX`. That conditional obligation is why the field is not listed under `required`: OpenAPI 3.0 cannot express "required unless `line_type` is `SUPLIDO`". A 0 % under IVA or IPSI is not a rate but the exemption sentinel and needs an `exemption_reason`; see `TaxInfo`. - **equivalence_surcharge_rate**: Equivalence surcharge rate for this line. **Default behaviour:** if omitted and the company has `apply_equivalence_surcharge: true` in its tax configuration, the line inherits the surcharge — and its percentage is a legal function of the line's VAT rate, not the configured default: 21 ↔ 5.2, 10 ↔ 1.4, 5 ↔ 0.62, 4 ↔ 0.5 (the pairs enumerated by `EquivalenceSurchargePercentage`). A company configured with `default_equivalence_surcharge: 5.2` therefore produces 1.4 on a 10% line, not 5.2. **The inheritance also rewrites the line's `regime_key` from `01` to `18`** (special regime for equivalence surcharge). This is deliberate: a surcharge and general regime `01` are fiscally incoherent, so the line comes back as `18` even if `01` was sent. To issue a line **without** surcharge under such a company, send `equivalence_surcharge_rate: 0` explicitly — exactly as with `irpf_rate`: the `01` regime key is then respected and no surcharge is applied. Sending an explicit rate greater than 0 together with `regime_key: "01"` is **not** rejected: the very same rewrite applies and the line comes back as `18`. **Any other regime with a surcharge is rejected** with `422 SURCHARGE_REQUIRES_REGIME`. Only the general regime `01` **rewrites**; REBU (`03`), exports (`02`), OSS (`17`)… never do, because a surcharge under them is fiscally invalid — an error to surface, not a shorthand to normalise. - **irpf_rate**: IRPF withholding rate for this line. **Default behaviour:** if omitted, the line inherits the account's default IRPF rate (configured in the tax profile, e.g. 15%). To issue a line **without** withholding you must send `irpf_rate: 0` explicitly. On SIMPLIFIED invoices (F2) IRPF withholding is **not allowed** (AEAT forbids it on F2): sending an `irpf_rate` other than 0 is **rejected** with `SIMPLIFICADA_FORBIDS_IRPF` — it is not coerced to 0. Omit the field or send `irpf_rate: 0` on F2 lines. On all other invoice types an explicit value is always respected. The rate must be one the issuer can bear (see `WithholdingOptions` in the tax configuration). No entity pays IRPF: a legal person or a permanent establishment (NIF starting with `A`, `B`, `C`, `D`, `F`, `G`, `Q`, `R`, `U` or `W`) only accepts `0`, `19`, `24` and `9.5` (rents in Ceuta and Melilla), a non-resident entity (`N`) `0`, `19` and `24`, and the State, an Autonomous Community or a local entity (`S`, `P`) only `0`; any other rate is rejected with `IRPF_RATE_NOT_FOR_CORPORATE_ISSUER`. `9.5` from an individual is rejected with `IRPF_RATE_ONLY_FOR_CORPORATE_ISSUER`: under IRPF the Ceuta and Melilla reduced rates are `6`, `2.8` and `7.6`. Checked on creation, on edit and again on issue; corrective invoices are not checked: they correct by differences what the original carried. - **exemption_reason** `ExemptionReason`: Tax exemption reason code per the Spanish VAT Law (Ley 37/1992, LIVA), with the VeriFactu code each one is reported as. - `EXENTA_ART_20`: exempt, art. 20 (domestic operations such as medical, educational, cultural and financial services, or housing rentals). E1. - `EXENTA_ART_21`: exempt, art. 21 (exports of goods). E2. - `EXENTA_ART_22`: exempt, art. 22 (operations treated as exports). E3. - `EXENTA_ART_24`: exempt, art. 24 (free zones, warehouses and customs regimes). E4. - `EXENTA_ART_25`: exempt, art. 25 (intra-community supplies of goods). E5. - `EXENTA_ART_26`: exempt, art. 26 (intra-community acquisitions of goods). It exempts the buyer's acquisition, not a supply the seller invoices, so an invoice line that carries it is rejected with `EXEMPTION_NOT_FOR_ISSUED_INVOICE`; a supply to another Member State is `EXENTA_ART_25`. - `NO_SUJETA_ART_7_9`: not subject under art. 7 (such as the transfer of a business as a going concern, art. 7.1º). N1. - `NO_SUJETA_LOCALIZACION`: not subject by the place-of-supply rules (intra-community or non-EU services, arts. 69 and 70). N2. - `ISP_ART_84_2_A` … `ISP_ART_84_2_F`: reverse charge (the invoice states «inversión del sujeto pasivo»), art. 84.Uno.2.º letters a) (supplier not established in Spain), b) (unwrought or semi-finished gold), c) (scrap, waste and recovery materials, plastic, paper, cardboard, glass and textile waste, and semi-finished non-ferrous metal products), d) (greenhouse gas emission allowances), e) (certain real estate supplies: in insolvency proceedings, with the exemption waived, or enforcing a security) and f) (construction or renovation works). S2. - `ISP_ART_84_2_G`: reverse charge of letter g) (silver, platinum, palladium, mobile phones, consoles, laptops and tablets). The law requires these supplies to be invoiced in a special series, so an invoice line that carries it is rejected with `REVERSE_CHARGE_CASE_NOT_SUPPORTED`. - `EXENTA_ART_140`: investment gold exemption, art. 140 bis (usually with `regime_key` `04`). E6. - `REGIMEN_ART_129` (agriculture, livestock and fishing, arts. 124 to 134 bis), `REGIMEN_ART_135` (second-hand goods, art and antiques), `REGIMEN_ART_141` (travel agencies), `REGIMEN_ART_154` (equivalence surcharge) and `REGIMEN_ART_163_DECIES` (cash basis, arts. 163 decies to 163 sexiesdecies): operations of special regimes, which VeriFactu identifies by the regime key rather than by an exemption code. An invoice line that carries one is rejected with `EXEMPTION_REGIME_NOT_SUPPORTED_IN_VERIFACTU`; declare the regime with `regime_key` instead. - `OTRO`: any other provision. Requires the text in `exemption_reason_text`. E6. - **exemption_reason_text** `string`: Custom exemption text. Only used when exemption_reason is OTRO. - **line_type**: Fiscal line type. Defaults to `NORMAL`. Use `SUPLIDO` for payments on behalf of the final client (art. 78.Tres.3 LIVA). Requires `source_invoice_reference`. - **source_invoice_reference** `string`: Reference to the original invoice issued by the third party in the client's name. Required when `line_type=SUPLIDO`. - **source_invoice_ids** `array[string]`: Ids of the issued invoices that make up the SUPLIDO. They may belong to the issuing account or to accounts it manages with VIEW access. Their sum is the amount (never typed). Audit traceability. - **payment_info** `PaymentInfo` - **notes** `string`: No description (example: "Payment by bank transfer. Includes technical support for 30 days.") - **external_ref**: This field was previously named `external_reference`. The old name is still accepted as an alias for backwards compatibility and will be withdrawn in a future major version — send `external_ref`. - **metadata** `InvoiceMetadata`: Your own key/value pairs to cross-reference this invoice with records in your system (order ids, tenants, internal codes). Namespace them to avoid clashing with the system keys BeeL adds on payment-generated invoices. - **options** `InvoiceProcessingOptions`: Controls how the invoice is processed after creation. All fields default to `false` if not specified. VeriFactu is **not** an option here: whether an invoice is registered with AEAT is a fact of the tax identity (NIF x environment), resolved at issue time against the company's regime. See `verifactu.enabled` in the invoice response for what was applied. **Common combinations:** - Draft (default): omit `options` or set all to `false` - Issue immediately: `{ issue_directly: true }` - Issue + wait for PDF: `{ issue_directly: true, wait_for_pdf: true }` - Issue + send email: `{ issue_directly: true, send_automatically: true }` - Full automation: `{ issue_directly: true, wait_for_pdf: true, send_automatically: true, email_config: { ... } }` ## Recipient Invoice recipient: either a registered customer (`customer_id`) or the recipient's data inline (`legal_name`, `nif`, `address`…), never both. Sending `customer_id` together with any other recipient field returns 422 `RECIPIENT_CUSTOMER_AND_DATA_EXCLUSIVE`, on create and on edit. All fields are optional at schema level, but for an ad-hoc recipient (no customer_id) on non-SIMPLIFIED invoices the API requires legal_name, address and nif (or alternative_id); omitting the address returns 422 RECIPIENT_ADDRESS_REQUIRED. - **customer_id** `string` (uuid): UUID of a registered customer. The invoice takes the recipient data stored on that customer. Send it alone: combined with any other recipient field it returns 422 `RECIPIENT_CUSTOMER_AND_DATA_EXCLUSIVE`. To change the recipient's data, edit the customer or send the data inline without `customer_id`. (example: "4f244735-980b-8d9c-80e8-6331fa0b1958") - **legal_name** `string`: Recipient legal name. Required when customer_id is not provided (except for SIMPLIFIED invoices where all fields are optional). (example: "Tech Solutions SL") - **trade_name** `string`: Recipient trade name (optional) (example: "TechSol") - **nif** `string`: Spanish Tax ID (9 alphanumeric characters). Required when customer_id is not provided and alternative_id is absent. Not accepted on SIMPLIFIED invoices: BeeL. requires a STANDARD invoice when the recipient is identified. (example: "B12345674") - **alternative_id**: No description - **address** `Address`: Address you send when you create or update a company, a customer or an onboarding. Addresses you read back are described by their own schema. - **phone** `PhoneInput`: A phone number as this API accepts it: 9 to 20 characters, and only digits, spaces, dashes, parentheses and an optional leading `+`. Every request that takes a phone number uses this schema. It is `Phone` plus the rules enforced on input. A value this schema accepts always satisfies `Phone`, so anything you send here is something a response can return. - **email** `Email`: Email address (minimum valid email is 5 chars, e.g. a@b.co) ## ExemptionReason Tax exemption reason code per the Spanish VAT Law (Ley 37/1992, LIVA), with the VeriFactu code each one is reported as. - `EXENTA_ART_20`: exempt, art. 20 (domestic operations such as medical, educational, cultural and financial services, or housing rentals). E1. - `EXENTA_ART_21`: exempt, art. 21 (exports of goods). E2. - `EXENTA_ART_22`: exempt, art. 22 (operations treated as exports). E3. - `EXENTA_ART_24`: exempt, art. 24 (free zones, warehouses and customs regimes). E4. - `EXENTA_ART_25`: exempt, art. 25 (intra-community supplies of goods). E5. - `EXENTA_ART_26`: exempt, art. 26 (intra-community acquisitions of goods). It exempts the buyer's acquisition, not a supply the seller invoices, so an invoice line that carries it is rejected with `EXEMPTION_NOT_FOR_ISSUED_INVOICE`; a supply to another Member State is `EXENTA_ART_25`. - `NO_SUJETA_ART_7_9`: not subject under art. 7 (such as the transfer of a business as a going concern, art. 7.1º). N1. - `NO_SUJETA_LOCALIZACION`: not subject by the place-of-supply rules (intra-community or non-EU services, arts. 69 and 70). N2. - `ISP_ART_84_2_A` … `ISP_ART_84_2_F`: reverse charge (the invoice states «inversión del sujeto pasivo»), art. 84.Uno.2.º letters a) (supplier not established in Spain), b) (unwrought or semi-finished gold), c) (scrap, waste and recovery materials, plastic, paper, cardboard, glass and textile waste, and semi-finished non-ferrous metal products), d) (greenhouse gas emission allowances), e) (certain real estate supplies: in insolvency proceedings, with the exemption waived, or enforcing a security) and f) (construction or renovation works). S2. - `ISP_ART_84_2_G`: reverse charge of letter g) (silver, platinum, palladium, mobile phones, consoles, laptops and tablets). The law requires these supplies to be invoiced in a special series, so an invoice line that carries it is rejected with `REVERSE_CHARGE_CASE_NOT_SUPPORTED`. - `EXENTA_ART_140`: investment gold exemption, art. 140 bis (usually with `regime_key` `04`). E6. - `REGIMEN_ART_129` (agriculture, livestock and fishing, arts. 124 to 134 bis), `REGIMEN_ART_135` (second-hand goods, art and antiques), `REGIMEN_ART_141` (travel agencies), `REGIMEN_ART_154` (equivalence surcharge) and `REGIMEN_ART_163_DECIES` (cash basis, arts. 163 decies to 163 sexiesdecies): operations of special regimes, which VeriFactu identifies by the regime key rather than by an exemption code. An invoice line that carries one is rejected with `EXEMPTION_REGIME_NOT_SUPPORTED_IN_VERIFACTU`; declare the regime with `regime_key` instead. - `OTRO`: any other provision. Requires the text in `exemption_reason_text`. E6. Type: `string` — one of: EXENTA_ART_20, EXENTA_ART_21, EXENTA_ART_22, EXENTA_ART_24, EXENTA_ART_25, EXENTA_ART_26, EXENTA_ART_140, NO_SUJETA_ART_7_9, NO_SUJETA_LOCALIZACION, ISP_ART_84_2_A, ISP_ART_84_2_B, ISP_ART_84_2_C, ISP_ART_84_2_D, ISP_ART_84_2_E, ISP_ART_84_2_F, ISP_ART_84_2_G, REGIMEN_ART_129, REGIMEN_ART_135, REGIMEN_ART_141, REGIMEN_ART_154, REGIMEN_ART_163_DECIES, OTRO ## PaymentInfo - **method**: Preferred payment method. Omitted, `BANK_TRANSFER` applies. If NONE is selected, no payment information will be shown on the invoice. - **iban** `IBAN`: IBAN (International Bank Account Number). Required when payment method is BANK_TRANSFER. - **swift** `SWIFT`: SWIFT/BIC code - **payment_term_days** `integer`: Payment term in days. When marking an invoice as paid, every field of this object that travels replaces the stored one and every omitted field keeps its current value. (example: 30) ## InvoiceMetadata Your own key/value pairs to cross-reference this invoice with records in your system (order ids, tenants, internal codes). Namespace them to avoid clashing with the system keys BeeL adds on payment-generated invoices. Type: `object` ## InvoiceProcessingOptions Controls how the invoice is processed after creation. All fields default to `false` if not specified. VeriFactu is **not** an option here: whether an invoice is registered with AEAT is a fact of the tax identity (NIF x environment), resolved at issue time against the company's regime. See `verifactu.enabled` in the invoice response for what was applied. **Common combinations:** - Draft (default): omit `options` or set all to `false` - Issue immediately: `{ issue_directly: true }` - Issue + wait for PDF: `{ issue_directly: true, wait_for_pdf: true }` - Issue + send email: `{ issue_directly: true, send_automatically: true }` - Full automation: `{ issue_directly: true, wait_for_pdf: true, send_automatically: true, email_config: { ... } }` - **issue_directly** `boolean`: If `true`, creates the invoice directly as **ISSUED** with a definitive number and PDF. If `false` (default), creates as **DRAFT** without number (editable, no PDF). - **wait_for_pdf** `boolean`: Only applies when `issue_directly` is `true`. If `true`, waits for PDF generation before returning the response (~1-3s). If `false` (default), PDF is generated asynchronously in the background. - **send_automatically** `boolean`: Only applies when `issue_directly` is `true`. If `true`, sends the invoice by email with PDF attachment after issuing. The email is sent asynchronously after the invoice is issued. - **attach_source_invoices** `boolean`: Only applies when `send_automatically` is `true`. If `true`, the email sent after issuing also attaches a ZIP (`suplidos_.zip`) with the PDFs of the source invoices referenced by the invoice's SUPLIDO consolidation lines (`source_invoice_ids`). Each PDF inside the ZIP is named `_.pdf`. Access to sources owned by managed accounts is re-checked with the same rules as issuing, and the request fails synchronously with an actionable error — never a partial ZIP — if the invoice has no consolidation sources (`ATTACH_SOURCE_INVOICES_NO_SOURCES`), a source is not reachable (`ATTACH_SOURCE_INVOICE_UNAVAILABLE`) or a source has no generated PDF (`ATTACH_SOURCE_PDF_MISSING`). The flag belongs to this issuing act only: it is never stored on the invoice. - **email_config**: Only applies when `send_automatically` is `true`. Overrides default email settings. If it names no recipients, the email goes to the customer's `billing_emails`, or to the customer's `email` when there are none. ## SuccessResponse The envelope every successful JSON response of the BeeL. API is wrapped in. There are no bare resources in v1 and none are planned: the payload always hangs off `data`. - A **single resource** is an object in `data`. - A **collection** hangs off a named key inside `data`, together with its `pagination`, also inside `data` — `data: {invoices: [...], pagination: {...}}`. - A collection carries `pagination` unless its operation declares itself a **closed catalogue**: a fixed, bounded list with nothing to page through. The declaration is explicit in the operation; a missing `pagination` is never something to infer. - `GET /v1/accounts` pages by cursor (`data: {accounts: [...], next_cursor}`). It is a documented variant of pagination, not another envelope. Putting the array straight into `data` with `pagination` as its sibling is the shape a v2 would adopt; v1 is not being flipped to it. - **success** (required) `boolean`: No description (example: true) - **data** (required): The payload. An object for a single resource; an object holding the named collection (and its `pagination`) for a listing. Never a bare array at this level in v1. - **meta** `ResponseMeta` ## ResponseMeta - **timestamp** `string` (date-time): No description (example: "2025-01-15T10:30:00Z") - **request_id** `string`: No description (example: "4bf92f3577b34da6a3ce929d0e0e4736") ## Invoice A stored invoice. Being stored is what makes `id`, `created_at` and `updated_at` part of its contract: every one of them always travels. - **invoice_number** `string`: Complete invoice number (series + sequential). **Null for draft invoices** — assigned automatically when issued. (example: "2025/0001") - **series** (required) `SeriesInfo` - **number** `integer`: Sequential number within the series. **Null for draft invoices** — assigned automatically when issued. (example: 1) - **type** (required) `InvoiceType`: - STANDARD: Standard invoice - CORRECTIVE: Corrects or cancels a previous invoice - SIMPLIFIED: Simplified invoice (ticket), for a recipient that is not identified. BeeL. requires a STANDARD invoice when the recipient is identified, at any amount: a SIMPLIFIED invoice whose recipient carries an `nif` or `alternative_id` is rejected with `SIMPLIFIED_INVOICE_FORBIDS_IDENTIFIED_RECIPIENT`. The only amount BeeL enforces is a cap of 3,000€ VAT included (`SIMPLIFIED_INVOICE_EXCEEDS_LEGAL_LIMIT`). The general limit of RD 1619/2012 is 400€ (art. 4.1.a); up to 3,000€ applies only to the activities listed in art. 4.2. BeeL does not check which activity the issuer carries out. - PROFORMA: Commercial document (formal quote) with no fiscal validity. Never enters VeriFactu (no QR, no AEAT submission): `verifactu.enabled` is always `false`, whatever the company's regime. Requires full recipient data, like STANDARD. Cannot be corrective nor reference a rectified invoice. - **status** (required) `InvoiceStatus`: - SCHEDULED: Scheduled invoice to be issued automatically on a future date - DRAFT: Draft invoice not sent yet (modifiable) - ISSUED: Finalized invoice with definitive number but not sent - SENT: Invoice sent to customer - PAID: Invoice paid - OVERDUE: Reserved. No operation sets this status and it is not computed from `due_date`; an unpaid invoice past its due date keeps its status (`ISSUED` or `SENT`). Compare `due_date` with today to find overdue invoices. - RECTIFIED: Partially corrected invoice (one or more PARTIAL corrective invoices) - VOIDED: Cancelled invoice. Reached either through a direct void request or through a TOTAL corrective invoice; `void_cause` tells the two apart. - CONVERTED: Proforma converted into an invoice (terminal; the proforma survives as the record of the accepted quote, linked to the created invoice) - ACTIVE: Active proforma. The single working state of a proforma (non-fiscal document): born numbered (PRO-...) and editable, never reaching the fiscal statuses. It transitions to CONVERTED when turned into an invoice, or to VOIDED when the offer is rejected/withdrawn (POST /v1/invoices/{invoice_id}/void). - EXPIRED: Proforma whose offer validity (`valid_until`) has passed. Derived on read and never stored; the proforma stays convertible and editable. - **issue_date** (required) `string` (date): Invoice issue date. Always set to the current date when the invoice is created. If the operation occurred on a different date, use `operation_date`. (example: "2025-01-15") - **operation_date** `string` (date): Date when the operation actually occurred. Used when invoicing for a past operation. If null, the operation date is the same as the issue date. (example: "2025-01-10") - **due_date** `string` (date): Payment due date (must be the same as or after `issue_date`) (example: "2025-02-14") - **valid_until** `string` (date): Offer validity date. Only rendered on PROFORMA invoices; on any other invoice type the field is inert (accepted and stored, but never shown on the document). Purely informational — nothing is triggered automatically when it passes. Not to be confused with `due_date`, the payment due date. (example: "2025-02-28") - **payment_date** `string` (date): Business date when the payment was received (e.g., the date on the bank statement). Set by the user when marking the invoice as paid. An invoice issued already paid gets its `issue_date`: one whose `total_to_pay` is 0, or one issued from a payment already confirmed by a payment integration. Only present when status is PAID. Contrast with `paid_at`, which is the system timestamp of when the status change was recorded. (example: "2025-01-20") - **sent_at** `string` (date-time): Moment the email provider ACCEPTED the invoice email — **not** the moment it reached the recipient's mailbox. Present when status is SENT or later. What happened afterwards (delivered, bounced, opened) is not a single timestamp: it lives in `sending_history`, one record per email with its own status and timestamp. On a resend, `sent_at` moves to the latest accepted send while `sending_history` keeps every one of them. (example: "2025-01-29T18:45:00Z") - **paid_at** `string` (date-time): System timestamp when the payment was recorded in the system. Automatically set when the invoice status changes to PAID. Contrast with `payment_date`, which is the business date chosen by the user. (example: "2025-02-05T10:30:00Z") - **auto_emit_after** `string` (date): Date when this draft will be auto-emitted if not manually issued. Only present for drafts created from recurring invoices with `draft_in_advance` enabled. (example: "2025-03-20") - **scheduled_for** `string` (date): Date when the invoice should be automatically processed. Only present when status is SCHEDULED. (example: "2025-02-15") - **scheduled_action** `GenerationAction`: Action to perform when processing a scheduled invoice: - DRAFT: Create as draft for manual review - ISSUE_AND_SEND: Issue and send automatically via email - **issuer** (required) `IssuerData` - **recipient** (required) `RecipientData`: Recipient data as stored on the invoice. Only `legal_name` is always present; the other fields appear when the invoice stores them. - **lines** (required) `array[InvoiceLine]`: Invoice lines. Can be empty: drafts may not have lines yet, and a handful of legacy imported invoices were recorded without them. Creating an invoice still requires at least one line. - **totals** (required) `InvoiceTotals` - **payment_info** `PaymentInfo` - **notes** `string`: Additional observations or notes - **replaced_invoice_ids** `array[string]`: Only on a full invoice issued in exchange for simplified invoices: the simplified invoices it replaces, each now `VOIDED` with `void_cause` `EXCHANGED`. With VeriFactu, the invoice is recorded as `F3` identifying them. - **void_cause** `VoidCause`: Why a `VOIDED` invoice reached that status: - VOID_REQUEST: Voided directly via `POST /v1/invoices/{invoice_id}/void`. The original VeriFactu record is cancelled with the tax authority. - TOTAL_CORRECTIVE: Voided as a result of issuing a TOTAL corrective invoice over it. The original VeriFactu record stays untouched; the corrective invoice is reported as a new record instead. - EXCHANGED: A simplified invoice replaced by a full invoice issued in exchange for it (`replaced_invoice_ids` of that invoice). Its VeriFactu record is not cancelled: the exchange invoice is recorded as `F3`, identifying it as replaced. Only present on voided invoices. - **void_reason** `string`: Reason recorded when the invoice was voided (only for voided invoices). - **voided_at** `string` (date-time): System timestamp when the invoice was voided. Automatically set at the moment the void takes place and never supplied by the caller — a void cannot be dated, so the deprecated `void_date` field of the void request has no effect on it. Invoices voided before this field existed carry the day they were voided on with a time of `00:00Z`, because only the day was retained for them. (example: "2025-01-20T09:12:44Z") - **rectified_invoice_id** `string` (uuid): UUID of the invoice being rectified (only for corrective invoices) - **source_proforma_id** `string` (uuid): UUID of the source proforma this invoice was converted from (only for invoices created via `convert-to-invoice`). - **converted_invoice_id** `string` (uuid): UUID of the live (non-deleted) invoice this proforma was converted into — the inverse of `source_proforma_id`, derived at read time (not persisted). Only present on the detail endpoint (`GET /v1/invoices/{invoice_id}`) for a proforma in `CONVERTED` status; never included in list rows. - **rectification_reason** `string`: Reason for rectification (only for corrective invoices) - **recurring_invoice_id** `string` (uuid): UUID of the recurring invoice that generated this invoice (if any) - **recurring_invoice_name** `string`: Name of the recurring invoice (denormalized for display) - **rectification_type** `RectificationType`: Type of rectification applied to a corrective invoice: - TOTAL: Rectifies everything still invoiced on the original, its live correctives included (status → VOIDED) - PARTIAL: Partially corrects the original invoice (status → RECTIFIED) - **rectification_code** `VeriFactuRectificationCode`: Rectification codes according to VeriFactu regulations (AEAT): - R1: Error founded in law and Art. 80 One, Two and Six LIVA - R2: Article 80 Three LIVA (Bankruptcy proceedings) - R3: Article 80 Four LIVA (Uncollectable debts) - R4: Other causes - R5: Corrective of a simplified invoice - ONLY for simplified invoices - **external_ref** `string`: Client-supplied external reference set at creation (order/cart/contract id). (example: "ORD-2025-0042") - **metadata** `object`: Additional metadata in key-value format. Invoices auto-generated from a connected payment platform carry system keys you can filter on: - external_customer_id: Payment-platform customer (e.g. Stripe `cus_…`), present when the payment carried a customer (absent on flows with no customer, e.g. Terminal / payment links without customer collection) - external_payment_id: Canonical payment reference. On Stripe this is always the PaymentIntent id (`pi_…`); the Charge, Stripe Invoice and Checkout Session ids are never used here, so every event of the same payment carries the same value. - payment_intent_id: Stripe PaymentIntent id, when the payment has one - charge_id: Stripe Charge id, when the payment has one - payment_provider: Origin platform (e.g. STRIPE_CONNECT) Plus any keys you set yourself on manually-created invoices (order ids, tenants, …). See the "Filtering by metadata" guide for the full list and query rules. (example: {"external_customer_id":"cus_ULGk8bzIr88aag","external_payment_id":"pi_3NqFGb2eZvKYlo2C0z1234AB","payment_intent_id":"pi_3NqFGb2eZvKYlo2C0z1234AB","charge_id":"ch_3NqFGb2eZvKYlo2C1234CDEF","payment_provider":"STRIPE_CONNECT","external_order_id":"ORD-2025-0042"}) - **send_automatically** `boolean`: Whether the invoice will be automatically sent by email after issuing. Only relevant for DRAFT and SCHEDULED invoices. - **email_config**: Email configuration used when `send_automatically` is true. If it names no recipients, the email goes to the customer's `billing_emails`, or to the customer's `email` when there are none. - **pdf_download_url** `string`: Relative URL of the endpoint that returns the PDF download link. Relative to the API base URL (e.g., https://app.beel.es/api). Note it is a link to a link: calling it returns a pre-signed URL that expires in five minutes. Null while there is no PDF to link to: they are produced asynchronously after issuing, so poll until the field appears. It is also null on a handful of very old invoices that have no downloadable PDF at all. (example: "/v1/companies/7c9e6679-7425-40de-944b-e07fc1f90ae7/invoices/550e8400-e29b-41d4-a716-446655440000/pdf") - **verifactu** `VeriFactu`: **Record of what was applied to this invoice** — not a per-invoice preference. Whether an invoice is registered with the AEAT is a fact of the *taxpayer*: if the issuing tax ID is under the VeriFactu regime in that environment, every one of its invoices is registered; if it is not, none is. That is resolved once, at issue time, against the state of the account at that instant, and what this block reports is the outcome — the receipt of an irreversible decision. It cannot be requested, overridden or changed per invoice. Present on every invoice, whatever its status. **Absent on a proforma**: a proforma is not a fiscal document and is never registered, so there is no outcome to report — read `verifactu` as "not applicable" when the key is missing or carries no value. - **attachments** `array[InvoiceAttachment]`: Files attached to the invoice, reserved for per-invoice attachments. To send the supporting invoices of a SUPLIDO consolidation, use `options.attach_source_invoices` when issuing: they travel as a ZIP attached to the outgoing email, and appear on the email delivery record rather than here. - **sending_history** `array[InvoiceSendRecord]`: Emails through which this invoice was sent, oldest first. Resending appends a record, it never replaces the previous one, and a batch send (one email with several invoices) is recorded in every invoice it carried. Only populated in single-invoice responses (`GET /v1/invoices/{invoice_id}` and the lifecycle endpoints); the list endpoint omits it. - **email_delivery** `InvoiceEmailDeliveryOutcome`: What became of the invoice's automatic email in the act that produced this response. Only present in the response to issuing an invoice (`POST .../invoices/{invoice_id}/issue`). Issuing is a fiscal act and never fails because of the email, so a send the sending policy refuses still answers `200` — this object is how it says so. Without it, a refused send and an invoice that never asked for one looked identical. - **deleted_at** `string` (date-time): No description - **id** (required) `string` (uuid): Unique invoice UUID (example: "550e8400-e29b-41d4-a716-446655440000") - **created_at** (required) `string` (date-time): No description - **updated_at** (required) `string` (date-time): No description ## ErrorResponse Error response shared by all BeeL. APIs. The payload carries **two contracts at once** (additive, non-breaking): - **Legacy** (`success`, `error.{code,message,details}`, `meta`) — kept intact for existing consumers. - **RFC 9457** (`type`, `title`, `detail`, `instance`) — new fields for integrators following Problem Details for HTTP APIs. The `type` URI is the stable, shareable link to the error's documentation page (e.g. `https://docs.beel.es/errors/{code}`). Future migration: the legacy fields will be deprecated via `Deprecation`/`Sunset` headers after a sufficient adoption window, and the response Content-Type will move to `application/problem+json`. - **success** (required) `boolean`: No description (example: false) - **error** (required) `ErrorDetail` - **meta** `ResponseMeta` - **type** `string` (uri): Stable URI that identifies the problem type and where the integrator will find its documentation. (example: "https://docs.beel.es/errors/INVOICE_NO_LINES") - **title** `string`: Short summary of the problem type. Stable between occurrences of the same `type`. (example: "INVOICE_NO_LINES") - **detail** `string`: Specific message for this occurrence, localized according to `Accept-Language` (`es`, `en`, `ca`); defaults to English. Matches the legacy `error.message`. (example: "The invoice must have at least one line") - **instance** `string` (uri-reference): URI that identifies the specific occurrence of the problem — typically the path of the affected resource. (example: "/v1/invoices/abc-123") ## ErrorDetail - **code** (required) `string`: No description (example: "VALIDATION_ERROR") - **message** (required) `string`: No description (example: "The provided data is not valid") - **details** `object`: No description (example: {"field":"specific error message"}) ## Address Address you send when you create or update a company, a customer or an onboarding. Addresses you read back are described by their own schema. - **street** (required) `string`: Full address (street, number, floor, etc.) - Latin characters only (example: "Calle Mayor, 123") - **number** `string`: Street number. Optional: omit it when the address has none, or when `street` already carries the address in full. (example: "123") - **floor** `string`: Floor or level (example: "2º A") - **door** `string`: Door or apartment (example: "A") - **postal_code** (required) `string`: Postal code (5 digits for Spain, free format for other countries) (example: "28001") - **city** (required) `string`: City or town - Latin characters only (example: "Madrid") - **province** `string`: Province or state - Latin characters only. Required for an address in Spain (`country_code` `ES`, or no country at all); optional elsewhere, where many addresses have none. A Spanish address without it is rejected with a `422`. (example: "Madrid") - **country** `string`: Country of the address, as its ISO 3166-1 alpha-2 code (`GB`) or its official name in Spanish, English or Catalan (`Reino Unido`, `United Kingdom`, `Regne Unit`; case and accents are ignored). Anything else, such as `UK`, is rejected with `422 COUNTRY_CODE_REQUIRED`: send `country_code` instead. If it names a different country than `country_code`, `422 COUNTRY_CODE_MISMATCH` (`España` alone yields to a foreign `country_code`: it was the old default). What is stored and returned is always the Spanish name derived from the resulting code, never the text sent. With neither field present, the address is Spanish (`España`). (example: "España") - **country_code** `string`: ISO 3166-1 alpha-2 country code: the canonical field that decides the country of the address. It must be a real country code (`GB`, not `UK`); otherwise `422 COUNTRY_CODE_REQUIRED`. When it is omitted, the code comes from `country` (see there). With neither field present, the address is stored as `ES`. (example: "ES") ## PhoneInput A phone number as this API accepts it: 9 to 20 characters, and only digits, spaces, dashes, parentheses and an optional leading `+`. Every request that takes a phone number uses this schema. It is `Phone` plus the rules enforced on input. A value this schema accepts always satisfies `Phone`, so anything you send here is something a response can return. Type: `string` ## Email Email address (minimum valid email is 5 chars, e.g. a@b.co) Type: `string` (email) ## IBAN IBAN (International Bank Account Number). Required when payment method is BANK_TRANSFER. Type: `string` ## SWIFT SWIFT/BIC code Type: `string` ## InvoiceBase The shape of an invoice, shared by the persisted resource and by the computed preview of one. It does not require the three fields that only a stored row can have — `id`, `created_at` and `updated_at`. Read `Invoice` or `NextOccurrence`, never this one: it is not the payload of any operation. - **invoice_number** `string`: Complete invoice number (series + sequential). **Null for draft invoices** — assigned automatically when issued. (example: "2025/0001") - **series** (required) `SeriesInfo` - **number** `integer`: Sequential number within the series. **Null for draft invoices** — assigned automatically when issued. (example: 1) - **type** (required) `InvoiceType`: - STANDARD: Standard invoice - CORRECTIVE: Corrects or cancels a previous invoice - SIMPLIFIED: Simplified invoice (ticket), for a recipient that is not identified. BeeL. requires a STANDARD invoice when the recipient is identified, at any amount: a SIMPLIFIED invoice whose recipient carries an `nif` or `alternative_id` is rejected with `SIMPLIFIED_INVOICE_FORBIDS_IDENTIFIED_RECIPIENT`. The only amount BeeL enforces is a cap of 3,000€ VAT included (`SIMPLIFIED_INVOICE_EXCEEDS_LEGAL_LIMIT`). The general limit of RD 1619/2012 is 400€ (art. 4.1.a); up to 3,000€ applies only to the activities listed in art. 4.2. BeeL does not check which activity the issuer carries out. - PROFORMA: Commercial document (formal quote) with no fiscal validity. Never enters VeriFactu (no QR, no AEAT submission): `verifactu.enabled` is always `false`, whatever the company's regime. Requires full recipient data, like STANDARD. Cannot be corrective nor reference a rectified invoice. - **status** (required) `InvoiceStatus`: - SCHEDULED: Scheduled invoice to be issued automatically on a future date - DRAFT: Draft invoice not sent yet (modifiable) - ISSUED: Finalized invoice with definitive number but not sent - SENT: Invoice sent to customer - PAID: Invoice paid - OVERDUE: Reserved. No operation sets this status and it is not computed from `due_date`; an unpaid invoice past its due date keeps its status (`ISSUED` or `SENT`). Compare `due_date` with today to find overdue invoices. - RECTIFIED: Partially corrected invoice (one or more PARTIAL corrective invoices) - VOIDED: Cancelled invoice. Reached either through a direct void request or through a TOTAL corrective invoice; `void_cause` tells the two apart. - CONVERTED: Proforma converted into an invoice (terminal; the proforma survives as the record of the accepted quote, linked to the created invoice) - ACTIVE: Active proforma. The single working state of a proforma (non-fiscal document): born numbered (PRO-...) and editable, never reaching the fiscal statuses. It transitions to CONVERTED when turned into an invoice, or to VOIDED when the offer is rejected/withdrawn (POST /v1/invoices/{invoice_id}/void). - EXPIRED: Proforma whose offer validity (`valid_until`) has passed. Derived on read and never stored; the proforma stays convertible and editable. - **issue_date** (required) `string` (date): Invoice issue date. Always set to the current date when the invoice is created. If the operation occurred on a different date, use `operation_date`. (example: "2025-01-15") - **operation_date** `string` (date): Date when the operation actually occurred. Used when invoicing for a past operation. If null, the operation date is the same as the issue date. (example: "2025-01-10") - **due_date** `string` (date): Payment due date (must be the same as or after `issue_date`) (example: "2025-02-14") - **valid_until** `string` (date): Offer validity date. Only rendered on PROFORMA invoices; on any other invoice type the field is inert (accepted and stored, but never shown on the document). Purely informational — nothing is triggered automatically when it passes. Not to be confused with `due_date`, the payment due date. (example: "2025-02-28") - **payment_date** `string` (date): Business date when the payment was received (e.g., the date on the bank statement). Set by the user when marking the invoice as paid. An invoice issued already paid gets its `issue_date`: one whose `total_to_pay` is 0, or one issued from a payment already confirmed by a payment integration. Only present when status is PAID. Contrast with `paid_at`, which is the system timestamp of when the status change was recorded. (example: "2025-01-20") - **sent_at** `string` (date-time): Moment the email provider ACCEPTED the invoice email — **not** the moment it reached the recipient's mailbox. Present when status is SENT or later. What happened afterwards (delivered, bounced, opened) is not a single timestamp: it lives in `sending_history`, one record per email with its own status and timestamp. On a resend, `sent_at` moves to the latest accepted send while `sending_history` keeps every one of them. (example: "2025-01-29T18:45:00Z") - **paid_at** `string` (date-time): System timestamp when the payment was recorded in the system. Automatically set when the invoice status changes to PAID. Contrast with `payment_date`, which is the business date chosen by the user. (example: "2025-02-05T10:30:00Z") - **auto_emit_after** `string` (date): Date when this draft will be auto-emitted if not manually issued. Only present for drafts created from recurring invoices with `draft_in_advance` enabled. (example: "2025-03-20") - **scheduled_for** `string` (date): Date when the invoice should be automatically processed. Only present when status is SCHEDULED. (example: "2025-02-15") - **scheduled_action** `GenerationAction`: Action to perform when processing a scheduled invoice: - DRAFT: Create as draft for manual review - ISSUE_AND_SEND: Issue and send automatically via email - **issuer** (required) `IssuerData` - **recipient** (required) `RecipientData`: Recipient data as stored on the invoice. Only `legal_name` is always present; the other fields appear when the invoice stores them. - **lines** (required) `array[InvoiceLine]`: Invoice lines. Can be empty: drafts may not have lines yet, and a handful of legacy imported invoices were recorded without them. Creating an invoice still requires at least one line. - **totals** (required) `InvoiceTotals` - **payment_info** `PaymentInfo` - **notes** `string`: Additional observations or notes - **replaced_invoice_ids** `array[string]`: Only on a full invoice issued in exchange for simplified invoices: the simplified invoices it replaces, each now `VOIDED` with `void_cause` `EXCHANGED`. With VeriFactu, the invoice is recorded as `F3` identifying them. - **void_cause** `VoidCause`: Why a `VOIDED` invoice reached that status: - VOID_REQUEST: Voided directly via `POST /v1/invoices/{invoice_id}/void`. The original VeriFactu record is cancelled with the tax authority. - TOTAL_CORRECTIVE: Voided as a result of issuing a TOTAL corrective invoice over it. The original VeriFactu record stays untouched; the corrective invoice is reported as a new record instead. - EXCHANGED: A simplified invoice replaced by a full invoice issued in exchange for it (`replaced_invoice_ids` of that invoice). Its VeriFactu record is not cancelled: the exchange invoice is recorded as `F3`, identifying it as replaced. Only present on voided invoices. - **void_reason** `string`: Reason recorded when the invoice was voided (only for voided invoices). - **voided_at** `string` (date-time): System timestamp when the invoice was voided. Automatically set at the moment the void takes place and never supplied by the caller — a void cannot be dated, so the deprecated `void_date` field of the void request has no effect on it. Invoices voided before this field existed carry the day they were voided on with a time of `00:00Z`, because only the day was retained for them. (example: "2025-01-20T09:12:44Z") - **rectified_invoice_id** `string` (uuid): UUID of the invoice being rectified (only for corrective invoices) - **source_proforma_id** `string` (uuid): UUID of the source proforma this invoice was converted from (only for invoices created via `convert-to-invoice`). - **converted_invoice_id** `string` (uuid): UUID of the live (non-deleted) invoice this proforma was converted into — the inverse of `source_proforma_id`, derived at read time (not persisted). Only present on the detail endpoint (`GET /v1/invoices/{invoice_id}`) for a proforma in `CONVERTED` status; never included in list rows. - **rectification_reason** `string`: Reason for rectification (only for corrective invoices) - **recurring_invoice_id** `string` (uuid): UUID of the recurring invoice that generated this invoice (if any) - **recurring_invoice_name** `string`: Name of the recurring invoice (denormalized for display) - **rectification_type** `RectificationType`: Type of rectification applied to a corrective invoice: - TOTAL: Rectifies everything still invoiced on the original, its live correctives included (status → VOIDED) - PARTIAL: Partially corrects the original invoice (status → RECTIFIED) - **rectification_code** `VeriFactuRectificationCode`: Rectification codes according to VeriFactu regulations (AEAT): - R1: Error founded in law and Art. 80 One, Two and Six LIVA - R2: Article 80 Three LIVA (Bankruptcy proceedings) - R3: Article 80 Four LIVA (Uncollectable debts) - R4: Other causes - R5: Corrective of a simplified invoice - ONLY for simplified invoices - **external_ref** `string`: Client-supplied external reference set at creation (order/cart/contract id). (example: "ORD-2025-0042") - **metadata** `object`: Additional metadata in key-value format. Invoices auto-generated from a connected payment platform carry system keys you can filter on: - external_customer_id: Payment-platform customer (e.g. Stripe `cus_…`), present when the payment carried a customer (absent on flows with no customer, e.g. Terminal / payment links without customer collection) - external_payment_id: Canonical payment reference. On Stripe this is always the PaymentIntent id (`pi_…`); the Charge, Stripe Invoice and Checkout Session ids are never used here, so every event of the same payment carries the same value. - payment_intent_id: Stripe PaymentIntent id, when the payment has one - charge_id: Stripe Charge id, when the payment has one - payment_provider: Origin platform (e.g. STRIPE_CONNECT) Plus any keys you set yourself on manually-created invoices (order ids, tenants, …). See the "Filtering by metadata" guide for the full list and query rules. (example: {"external_customer_id":"cus_ULGk8bzIr88aag","external_payment_id":"pi_3NqFGb2eZvKYlo2C0z1234AB","payment_intent_id":"pi_3NqFGb2eZvKYlo2C0z1234AB","charge_id":"ch_3NqFGb2eZvKYlo2C1234CDEF","payment_provider":"STRIPE_CONNECT","external_order_id":"ORD-2025-0042"}) - **send_automatically** `boolean`: Whether the invoice will be automatically sent by email after issuing. Only relevant for DRAFT and SCHEDULED invoices. - **email_config**: Email configuration used when `send_automatically` is true. If it names no recipients, the email goes to the customer's `billing_emails`, or to the customer's `email` when there are none. - **pdf_download_url** `string`: Relative URL of the endpoint that returns the PDF download link. Relative to the API base URL (e.g., https://app.beel.es/api). Note it is a link to a link: calling it returns a pre-signed URL that expires in five minutes. Null while there is no PDF to link to: they are produced asynchronously after issuing, so poll until the field appears. It is also null on a handful of very old invoices that have no downloadable PDF at all. (example: "/v1/companies/7c9e6679-7425-40de-944b-e07fc1f90ae7/invoices/550e8400-e29b-41d4-a716-446655440000/pdf") - **verifactu** `VeriFactu`: **Record of what was applied to this invoice** — not a per-invoice preference. Whether an invoice is registered with the AEAT is a fact of the *taxpayer*: if the issuing tax ID is under the VeriFactu regime in that environment, every one of its invoices is registered; if it is not, none is. That is resolved once, at issue time, against the state of the account at that instant, and what this block reports is the outcome — the receipt of an irreversible decision. It cannot be requested, overridden or changed per invoice. Present on every invoice, whatever its status. **Absent on a proforma**: a proforma is not a fiscal document and is never registered, so there is no outcome to report — read `verifactu` as "not applicable" when the key is missing or carries no value. - **attachments** `array[InvoiceAttachment]`: Files attached to the invoice, reserved for per-invoice attachments. To send the supporting invoices of a SUPLIDO consolidation, use `options.attach_source_invoices` when issuing: they travel as a ZIP attached to the outgoing email, and appear on the email delivery record rather than here. - **sending_history** `array[InvoiceSendRecord]`: Emails through which this invoice was sent, oldest first. Resending appends a record, it never replaces the previous one, and a batch send (one email with several invoices) is recorded in every invoice it carried. Only populated in single-invoice responses (`GET /v1/invoices/{invoice_id}` and the lifecycle endpoints); the list endpoint omits it. - **email_delivery** `InvoiceEmailDeliveryOutcome`: What became of the invoice's automatic email in the act that produced this response. Only present in the response to issuing an invoice (`POST .../invoices/{invoice_id}/issue`). Issuing is a fiscal act and never fails because of the email, so a send the sending policy refuses still answers `200` — this object is how it says so. Without it, a refused send and an invoice that never asked for one looked identical. - **deleted_at** `string` (date-time): No description ## SeriesInfo - **id** (required) `string` (uuid): Invoice series UUID (example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890") - **code** (required) `string`: Alphanumeric series code (example: "FAC") ## InvoiceType - STANDARD: Standard invoice - CORRECTIVE: Corrects or cancels a previous invoice - SIMPLIFIED: Simplified invoice (ticket), for a recipient that is not identified. BeeL. requires a STANDARD invoice when the recipient is identified, at any amount: a SIMPLIFIED invoice whose recipient carries an `nif` or `alternative_id` is rejected with `SIMPLIFIED_INVOICE_FORBIDS_IDENTIFIED_RECIPIENT`. The only amount BeeL enforces is a cap of 3,000€ VAT included (`SIMPLIFIED_INVOICE_EXCEEDS_LEGAL_LIMIT`). The general limit of RD 1619/2012 is 400€ (art. 4.1.a); up to 3,000€ applies only to the activities listed in art. 4.2. BeeL does not check which activity the issuer carries out. - PROFORMA: Commercial document (formal quote) with no fiscal validity. Never enters VeriFactu (no QR, no AEAT submission): `verifactu.enabled` is always `false`, whatever the company's regime. Requires full recipient data, like STANDARD. Cannot be corrective nor reference a rectified invoice. Type: `string` — one of: STANDARD, CORRECTIVE, SIMPLIFIED, PROFORMA ## InvoiceStatus - SCHEDULED: Scheduled invoice to be issued automatically on a future date - DRAFT: Draft invoice not sent yet (modifiable) - ISSUED: Finalized invoice with definitive number but not sent - SENT: Invoice sent to customer - PAID: Invoice paid - OVERDUE: Reserved. No operation sets this status and it is not computed from `due_date`; an unpaid invoice past its due date keeps its status (`ISSUED` or `SENT`). Compare `due_date` with today to find overdue invoices. - RECTIFIED: Partially corrected invoice (one or more PARTIAL corrective invoices) - VOIDED: Cancelled invoice. Reached either through a direct void request or through a TOTAL corrective invoice; `void_cause` tells the two apart. - CONVERTED: Proforma converted into an invoice (terminal; the proforma survives as the record of the accepted quote, linked to the created invoice) - ACTIVE: Active proforma. The single working state of a proforma (non-fiscal document): born numbered (PRO-...) and editable, never reaching the fiscal statuses. It transitions to CONVERTED when turned into an invoice, or to VOIDED when the offer is rejected/withdrawn (POST /v1/invoices/{invoice_id}/void). - EXPIRED: Proforma whose offer validity (`valid_until`) has passed. Derived on read and never stored; the proforma stays convertible and editable. Type: `string` — one of: SCHEDULED, DRAFT, ISSUED, SENT, PAID, OVERDUE, RECTIFIED, VOIDED, CONVERTED, ACTIVE, EXPIRED ## GenerationAction Action to perform when processing a scheduled invoice: - DRAFT: Create as draft for manual review - ISSUE_AND_SEND: Issue and send automatically via email Type: `string` — one of: DRAFT, ISSUE_AND_SEND ## IssuerData - **legal_name** (required) `string`: Issuer legal name (example: "Juan Pérez García") - **trade_name** `string`: Issuer trade name (optional) (example: "JP Web Development") - **nif** (required) `string`: Spanish Tax ID (9 alphanumeric characters). Valid formats: - DNI: 8 digits + letter (e.g., 12345678A) - NIE: X/Y/Z + 7 digits + letter (e.g., X1234567A) - CIF: Letter + 7 digits + digit/letter (e.g., B12345674) (example: "12345678A") - **address**: Issuer address as stored. Optional and absent when the company has not registered its address yet: an address is either complete or it is not there, so no partial address and no placeholder is ever returned in its place. - **phone** `Phone`: A phone number, as the record holds it: digits, spaces, dashes, parentheses and an optional leading `+`, up to 20 characters. This is the schema a **response** carries, and the length above is the only rule it states. It deliberately does not repeat the character rule, because a number can reach a record through a path that predates that rule or never passed through this API at all — a payment provider's customer data, a bulk import. Read the field defensively and do not assume it parses. What a **request** has to satisfy is `PhoneInput`, which adds the rules this API enforces on the way in. - **email** `Email`: Email address (minimum valid email is 5 chars, e.g. a@b.co) - **website** `string`: Issuer website (optional) (example: "https://beel.es") - **logo_url** `string`: Issuer logo URL (optional) - **additional_info** `string`: Additional issuer information (collegiate number, professional registration, etc.) (example: "Nº Colegiado: 12345") ## RecipientData Recipient data as stored on the invoice. Only `legal_name` is always present; the other fields appear when the invoice stores them. - **customer_id** `string` (uuid): Customer UUID in the system (optional) - **legal_name** (required) `string`: Recipient legal name (example: "Empresa SL") - **trade_name** `string`: Recipient trade name (optional) (example: "Empresa") - **nif** `string`: Spanish Tax ID (9 alphanumeric characters), when the invoice identifies its recipient with one. Valid formats: - DNI: 8 digits + letter (e.g., 12345678A) - NIE: X/Y/Z + 7 digits + letter (e.g., X1234567A) - CIF: Letter + 7 digits + digit/letter (e.g., B12345674) (example: "12345678A") - **alternative_id**: No description - **address**: Recipient address as stored (optional for simplified invoices). Read shape: an invoice recorded without recipient address still carries the stamped country code, so no field is guaranteed. - **phone** `Phone`: A phone number, as the record holds it: digits, spaces, dashes, parentheses and an optional leading `+`, up to 20 characters. This is the schema a **response** carries, and the length above is the only rule it states. It deliberately does not repeat the character rule, because a number can reach a record through a path that predates that rule or never passed through this API at all — a payment provider's customer data, a bulk import. Read the field defensively and do not assume it parses. What a **request** has to satisfy is `PhoneInput`, which adds the rules this API enforces on the way in. - **email** `Email`: Email address (minimum valid email is 5 chars, e.g. a@b.co) ## InvoiceLine - **description** `string`: Description of the invoiced concept. Required for NORMAL lines; optional for SUPLIDO lines (may be empty or absent). (example: "Web application development") - **quantity** (required) `number`: Product/service quantity (can be negative in corrective invoices) (example: 40) - **unit** `string`: No description (example: "hours") - **unit_price** (required) `number`: Unit price before taxes (can be negative in corrective invoices). Supports up to 4 decimal places for micro-pricing (e.g., €0.0897/unit for labels, packaging). Final amounts are always rounded to 2 decimals. This range is wider than the `maximum` the request accepts for `unit_price`, and on purpose: on a line priced by declared total the unit price is not sent but derived (total ÷ quantity), so what comes back can exceed what you are allowed to send. (example: 50) - **discount_percentage** `number`: Discount percentage applied (0-100) (example: 10) - **main_tax** `TaxInfo`: Complete tax information with cross-validations: - IVA: real rates 4, 10, 21, and the temporary 2, 5 and 7.5 (see below for 0) - IGIC: 0, 3, 5, 7, 9.5, 15, 20 — here 0 is the real "Tipo Cero" - IPSI: real rates 0.5, 1, 2, 4, 8, 10 (see below for 0) - OTHER: any percentage between 0 and 100 **0 % under IVA and IPSI is not a rate, it is the exemption sentinel.** It is accepted on a line, but only together with an `exemption_reason` (exempt or non-subject operation); on its own it says nothing and the line is rejected. That is why `GET /v1/tax-types` publishes the IVA rates without 0: the legitimate way to a 0 % IVA line is through an exemption reason, which the same response also publishes. IGIC is different — its 0 % is a real legal rate (basic necessities) and needs no reason. **IVA 5 %** (the temporary rate applied from 2022 to electricity, gas and certain foodstuffs) is no longer in force for new operations. AEAT only accepts it on operations dated from 2022-07-01 to 2024-09-30: send the `operation_date` of that period, because without one the issue date decides and a line at 5 % is rejected with `422 VAT_RATE_NOT_ACCEPTED_ON_DATE`. Its equivalence surcharge pair is 0.5 up to 2022-12-31 and 0.62 from 2023-01-01. **IVA 2 % and 7.5 %** (temporary rates of the last quarter of 2024) are accepted only on operations dated from 2024-10-01 to 2024-12-31, with surcharges 0.26 and 1. Exception: when regime_key = "17" (OSS/IOSS) the invoice applies the destination country VAT instead of the Spanish one, so any percentage in the EU range [0, 27] is accepted regardless of the tax type set — including 0 without an exemption reason. - **equivalence_surcharge_rate** `number`: Equivalence surcharge rate the line was issued with. It is what the invoice holds, not what a request accepts (see `EquivalenceSurchargePercentage`): invoices issued with VAT at 5 % before the surcharge was corrected to 0.62 keep the `0.625` they were issued with, because an issued invoice never changes. Their billing record declares 0.62, as the AEAT information note on the new surcharge rates allows. (example: 5.2) - **irpf_rate** `number`: Withholding (IRPF) rate the line holds. It is what the invoice holds, not what a request accepts (see `IrpfPercentage`): a line saved with a rate the table no longer has keeps it, and an issued invoice never changes. (example: 15) - **exemption_reason** `ExemptionReason`: Tax exemption reason code per the Spanish VAT Law (Ley 37/1992, LIVA), with the VeriFactu code each one is reported as. - `EXENTA_ART_20`: exempt, art. 20 (domestic operations such as medical, educational, cultural and financial services, or housing rentals). E1. - `EXENTA_ART_21`: exempt, art. 21 (exports of goods). E2. - `EXENTA_ART_22`: exempt, art. 22 (operations treated as exports). E3. - `EXENTA_ART_24`: exempt, art. 24 (free zones, warehouses and customs regimes). E4. - `EXENTA_ART_25`: exempt, art. 25 (intra-community supplies of goods). E5. - `EXENTA_ART_26`: exempt, art. 26 (intra-community acquisitions of goods). It exempts the buyer's acquisition, not a supply the seller invoices, so an invoice line that carries it is rejected with `EXEMPTION_NOT_FOR_ISSUED_INVOICE`; a supply to another Member State is `EXENTA_ART_25`. - `NO_SUJETA_ART_7_9`: not subject under art. 7 (such as the transfer of a business as a going concern, art. 7.1º). N1. - `NO_SUJETA_LOCALIZACION`: not subject by the place-of-supply rules (intra-community or non-EU services, arts. 69 and 70). N2. - `ISP_ART_84_2_A` … `ISP_ART_84_2_F`: reverse charge (the invoice states «inversión del sujeto pasivo»), art. 84.Uno.2.º letters a) (supplier not established in Spain), b) (unwrought or semi-finished gold), c) (scrap, waste and recovery materials, plastic, paper, cardboard, glass and textile waste, and semi-finished non-ferrous metal products), d) (greenhouse gas emission allowances), e) (certain real estate supplies: in insolvency proceedings, with the exemption waived, or enforcing a security) and f) (construction or renovation works). S2. - `ISP_ART_84_2_G`: reverse charge of letter g) (silver, platinum, palladium, mobile phones, consoles, laptops and tablets). The law requires these supplies to be invoiced in a special series, so an invoice line that carries it is rejected with `REVERSE_CHARGE_CASE_NOT_SUPPORTED`. - `EXENTA_ART_140`: investment gold exemption, art. 140 bis (usually with `regime_key` `04`). E6. - `REGIMEN_ART_129` (agriculture, livestock and fishing, arts. 124 to 134 bis), `REGIMEN_ART_135` (second-hand goods, art and antiques), `REGIMEN_ART_141` (travel agencies), `REGIMEN_ART_154` (equivalence surcharge) and `REGIMEN_ART_163_DECIES` (cash basis, arts. 163 decies to 163 sexiesdecies): operations of special regimes, which VeriFactu identifies by the regime key rather than by an exemption code. An invoice line that carries one is rejected with `EXEMPTION_REGIME_NOT_SUPPORTED_IN_VERIFACTU`; declare the regime with `regime_key` instead. - `OTRO`: any other provision. Requires the text in `exemption_reason_text`. E6. - **exemption_reason_text** `string`: Custom exemption text. Only used when exemption_reason is OTRO. - **taxable_base** `number`: Line taxable base (after discount, can be negative in corrective invoices) (example: 1800) - **line_total** (required) `number`: Line total with taxes (can be negative in corrective invoices) (example: 2178) - **pricing_mode** `string`: How the line amount was entered. `UNIT_PRICE` = classic mode: the amount is derived from `unit_price` (`quantity × unit_price × (1 − discount / 100)`). `TOTAL_EXCLUDING_TAX` = total-declared mode: `total_excluding_tax` is the exact taxable base and `unit_price` is derived and informational (`total / quantity`, 4 decimals). `TOTAL_INCLUDING_TAX` = tax-inclusive total-declared mode: `total_including_tax` is what the customer paid (taxable base + VAT + equivalence surcharge) and the engine works the breakdown backwards so the rounded amounts add up to the declared total exactly. — one of: UNIT_PRICE, TOTAL_EXCLUDING_TAX, TOTAL_INCLUDING_TAX - **total_excluding_tax** `number`: Declared line total excluding taxes. Only present on lines with `pricing_mode = TOTAL_EXCLUDING_TAX`. Unlike `line_total`, it never includes taxes nor subtracts IRPF withholding. (example: 1) - **total_including_tax** `number`: Declared line total including taxes (taxable base + VAT + equivalence surcharge; IRPF withholding is never subtracted). Only present on lines with `pricing_mode = TOTAL_INCLUDING_TAX`. The invariant `taxable_base + VAT + surcharge = total_including_tax` holds exactly. (example: 100) - **line_type**: Fiscal line type. - **NORMAL**: standard line; contributes to the taxable base and VAT. - **SUPLIDO**: payment made on behalf of the final client (art. 78.Tres.3 LIVA); excluded from the taxable base, VAT and VeriFactu. - **source_invoice_reference** `string`: Reference to the original invoice issued by the third party in the client's name. Required when line_type=SUPLIDO. - **source_invoice_ids** `array[string]`: Ids of the issued invoices that make up the SUPLIDO. They may belong to the issuing account or to accounts it manages with VIEW access. Their sum is the disbursement amount (never typed by hand). Audit traceability. Only present on lines with line_type=SUPLIDO. ## InvoiceTotals - **taxable_base** (required) `number`: Total taxable base (can be negative in corrective invoices) (example: 2000) - **total_discounts** `number`: Total discounts applied (can be negative in corrective invoices) (example: 0) - **vat_breakdown** `array[object]`: No description - **type** (required) `number`: No description (example: 21) - **base** (required) `number`: No description (example: 2000) - **amount** (required) `number`: No description (example: 420) - **regime_key** `string`: VeriFactu regime key of the rows grouped here. Rows are grouped by (tax type, rate, regime key), so an invoice mixing general-regime and equivalence-surcharge lines at the same rate yields TWO rows at `type: 21` that only this field tells apart (`01` vs `18`). Index by `(type, regime_key)`, never by `type` alone. (example: "18") - **total_vat** (required) `number`: Total indirect tax (IVA, IGIC, IPSI and other rates), not only VAT. Can be negative in corrective invoices. (example: 420) - **surcharge_breakdown** `array[object]`: No description - **type** (required) `number`: No description - **base** (required) `number`: No description - **amount** (required) `number`: No description - **total_equivalence_surcharge** (required) `number`: Total equivalence surcharge (can be negative in corrective invoices) (example: 0) - **irpf_breakdown** `array[object]`: No description - **type** (required) `number`: No description - **base** (required) `number`: No description - **amount** (required) `number`: No description - **total_irpf** (required) `number`: Total personal income tax withheld (can be negative in corrective invoices) (example: 300) - **invoice_total** (required) `number`: Total amount to pay (base + VAT + RE - IRPF, can be negative in corrective invoices) (example: 2120) - **total_disbursements** `number`: Sum of SUPLIDO lines (payments on behalf of the client, art. 78.Tres.3 LIVA). Excluded from the taxable base, VAT and VeriFactu. (example: 0) - **total_to_pay** `number`: Total amount paid by the client = `invoice_total` + `total_disbursements`. This is the amount on the PDF and the actual charge. When there are no disbursements (suplidos) it matches `invoice_total`. (example: 2120) ## VoidCause Why a `VOIDED` invoice reached that status: - VOID_REQUEST: Voided directly via `POST /v1/invoices/{invoice_id}/void`. The original VeriFactu record is cancelled with the tax authority. - TOTAL_CORRECTIVE: Voided as a result of issuing a TOTAL corrective invoice over it. The original VeriFactu record stays untouched; the corrective invoice is reported as a new record instead. - EXCHANGED: A simplified invoice replaced by a full invoice issued in exchange for it (`replaced_invoice_ids` of that invoice). Its VeriFactu record is not cancelled: the exchange invoice is recorded as `F3`, identifying it as replaced. Only present on voided invoices. Type: `string` — one of: VOID_REQUEST, TOTAL_CORRECTIVE, EXCHANGED ## RectificationType Type of rectification applied to a corrective invoice: - TOTAL: Rectifies everything still invoiced on the original, its live correctives included (status → VOIDED) - PARTIAL: Partially corrects the original invoice (status → RECTIFIED) Type: `string` — one of: TOTAL, PARTIAL ## VeriFactuRectificationCode Rectification codes according to VeriFactu regulations (AEAT): - R1: Error founded in law and Art. 80 One, Two and Six LIVA - R2: Article 80 Three LIVA (Bankruptcy proceedings) - R3: Article 80 Four LIVA (Uncollectable debts) - R4: Other causes - R5: Corrective of a simplified invoice - ONLY for simplified invoices Type: `string` — one of: R1, R2, R3, R4, R5 ## VeriFactu **Record of what was applied to this invoice** — not a per-invoice preference. Whether an invoice is registered with the AEAT is a fact of the *taxpayer*: if the issuing tax ID is under the VeriFactu regime in that environment, every one of its invoices is registered; if it is not, none is. That is resolved once, at issue time, against the state of the account at that instant, and what this block reports is the outcome — the receipt of an irreversible decision. It cannot be requested, overridden or changed per invoice. Present on every invoice, whatever its status. **Absent on a proforma**: a proforma is not a fiscal document and is never registered, so there is no outcome to report — read `verifactu` as "not applicable" when the key is missing or carries no value. - **enabled** `boolean`: Whether this invoice was registered with the AEAT under VeriFactu. Read-only: it records the regime of the issuing tax ID at the moment of issuance. - **invoice_hash** `string`: SHA-256 hash of the registration record, as VeriFactu defines it. Present from the moment the registration is submitted, while `submission_status` is still `PENDING`, and kept whatever the AEAT answers. (example: "3A5B7C9D1E2F3A4B5C6D7E8F9A0B1C2D3E4F5A6B7C8D9E0F1A2B3C4D5E6F7A8B") - **registration_number** `string`: Identifier (UUID) of this record in the VeriFactu submission, assigned when it is submitted. It is not an AEAT code: quote it when you ask BeeL about the record. (example: "4f8c2a1e-9b3d-4e7a-8c5f-1d2e3f4a5b6c") - **qr_url** `string`: AEAT verification URL encoded in the invoice QR code. Present from the moment the registration is submitted, while `submission_status` is still `PENDING`. (example: "https://www2.agenciatributaria.gob.es/wlpl/TIKE-CONT/ValidarQR?nif=B12345674&numserie=A%2F2025%2F0042&fecha=20-01-2025&importe=1590.00") - **qr_base64** `string`: QR code as base64-encoded PNG for embedding in custom PDFs. Present from the moment the registration is submitted, while `submission_status` is still `PENDING`; it does not wait for the AEAT to accept the record. (example: "iVBORw0KGgoAAAANSUhEUgAAAMgAAADI...") - **registered_at** `string` (date-time): VeriFactu registration date and time - **submission_status** `VeriFactuSubmissionStatus`: Submission status of an invoice's VeriFactu record to AEAT. Single vocabulary for the whole axis: the same values are published in `verifactu.submission_status` of an invoice and accepted by the `verifactu_status` filter of `GET /v1/invoices`, so a value read from an invoice can be fed straight back into the filter. * `PENDING` — queued, AEAT has not answered yet. A temporary AEAT server error also stays `PENDING`: BeeL. retries it automatically, and it only becomes `REJECTED` if the retries run out. * `ACCEPTED` — accepted by AEAT (with or without non-blocking warnings). * `VOIDED` — a cancellation record was accepted by AEAT. * `REJECTED` — rejected by AEAT, or the submission was rejected by the provider before reaching AEAT (see `error_code` / `error_message`). * `NOT_SUBMITTED` — the invoice is issued with VeriFactu enabled but has no live record: the submission fell through (lost event, exhausted retries) and AEAT does not know the invoice exists. Transient right after issuing (the async submission may still be in flight); if it persists, the registration needs to be re-driven. Drafts and scheduled invoices have no submission to describe yet and omit the field. Invoices with `verifactu.enabled = false` are outside this axis and are selected with the `verifactu_enabled` filter. - **skip_reason**: Why this invoice was not submitted to AEAT, when a submission was expected and omitted. Null in every other case, including invoices that are not subject to VeriFactu at all. - **error_code** `string`: Error code returned by AEAT. Present when the AEAT reported a remark or an error on the record. (example: "3000") - **error_message** `string`: Human-readable reason for the outcome. When the AEAT reported a remark or an error on the record, it is the AEAT's own description. When BeeL. decided the outcome (the submission was rejected before reaching the AEAT, or BeeL. stopped waiting for a final answer), it is a message written by BeeL., in the language of the request. (example: "Factura ya existe en el sistema") ## InvoiceAttachment A file attached to the invoice. - **id** `string` (uuid): No description - **name** `string`: No description - **url** `string`: No description - **type** `string`: No description ## InvoiceSendRecord One email through which an invoice was sent, as recorded in the delivery read-model. Batch sends (one email carrying several invoices) produce one record in each of the invoices they carry. - **id** (required) `string` (uuid): Id of the delivery record (same id as in `GET /v1/emails`). - **recipients** (required) `array[string]`: Recipient addresses (To) - **cc** `array[string]`: Carbon-copy addresses (CC) - **subject** `string`: No description - **status** (required) `EmailDeliveryStatus`: Status of an email. The history records every email the system decided to send, not only the ones that went out: an email stopped by policy is listed as REJECTED rather than omitted. - QUEUED: authorised and recorded, not dispatched yet - REJECTED: stopped by policy and never sent (terminal, not retried). In test environments invoices may only be emailed to the account owner's own address (`+tag` aliases included), so a message addressed elsewhere lands here - SENT: successfully sent to the provider - FAILED: sending failed - DELIVERED / BOUNCED / OPENED: reported by the provider's webhooks - **sent_at** `string` (date-time): Moment the email provider ACCEPTED the message — not the moment it reached the mailbox. Later outcomes (delivered, bounced, opened) are reflected in `status` as the provider reports them. Absent while there is no such moment: the history records decisions, and a `QUEUED` record has not been dispatched yet, a `REJECTED` one never will be, and a `FAILED` one never got that far. Read `status` to tell those apart; do not read an absent `sent_at` as "sent long ago". It is omitted, never sent as `null`. (example: "2025-01-29T18:45:00Z") - **external_message_id** `string`: Message id at the email provider, when available. - **error** `string`: Why the email did not go out, present only when `status` is `FAILED` or `REJECTED`. A short explanation in the language of the request, meant to be shown to a person; do not parse it; branch on `status` instead. ## InvoiceEmailDeliveryOutcome What became of the invoice's automatic email in the act that produced this response. Only present in the response to issuing an invoice (`POST .../invoices/{invoice_id}/issue`). Issuing is a fiscal act and never fails because of the email, so a send the sending policy refuses still answers `200` — this object is how it says so. Without it, a refused send and an invoice that never asked for one looked identical. - **status** (required) `string`: - `SENT` — the email was authorised and accepted for delivery. Delivery itself is asynchronous; follow it in `sending_history`. - `REJECTED` — the sending policy refused it. Nothing was queued and nothing will be retried; the refusal is recorded in the delivery ledger. - `NOT_REQUESTED` — the invoice does not send automatically. — one of: SENT, REJECTED, NOT_REQUESTED (example: "REJECTED") - **reason** `string`: Translation key explaining a `REJECTED` outcome, deliberately generic. Null for the other statuses. (example: "error.email.envio_no_permitido") ## Phone A phone number, as the record holds it: digits, spaces, dashes, parentheses and an optional leading `+`, up to 20 characters. This is the schema a **response** carries, and the length above is the only rule it states. It deliberately does not repeat the character rule, because a number can reach a record through a path that predates that rule or never passed through this API at all — a payment provider's customer data, a bulk import. Read the field defensively and do not assume it parses. What a **request** has to satisfy is `PhoneInput`, which adds the rules this API enforces on the way in. Type: `string` ## TaxInfo Complete tax information with cross-validations: - IVA: real rates 4, 10, 21, and the temporary 2, 5 and 7.5 (see below for 0) - IGIC: 0, 3, 5, 7, 9.5, 15, 20 — here 0 is the real "Tipo Cero" - IPSI: real rates 0.5, 1, 2, 4, 8, 10 (see below for 0) - OTHER: any percentage between 0 and 100 **0 % under IVA and IPSI is not a rate, it is the exemption sentinel.** It is accepted on a line, but only together with an `exemption_reason` (exempt or non-subject operation); on its own it says nothing and the line is rejected. That is why `GET /v1/tax-types` publishes the IVA rates without 0: the legitimate way to a 0 % IVA line is through an exemption reason, which the same response also publishes. IGIC is different — its 0 % is a real legal rate (basic necessities) and needs no reason. **IVA 5 %** (the temporary rate applied from 2022 to electricity, gas and certain foodstuffs) is no longer in force for new operations. AEAT only accepts it on operations dated from 2022-07-01 to 2024-09-30: send the `operation_date` of that period, because without one the issue date decides and a line at 5 % is rejected with `422 VAT_RATE_NOT_ACCEPTED_ON_DATE`. Its equivalence surcharge pair is 0.5 up to 2022-12-31 and 0.62 from 2023-01-01. **IVA 2 % and 7.5 %** (temporary rates of the last quarter of 2024) are accepted only on operations dated from 2024-10-01 to 2024-12-31, with surcharges 0.26 and 1. Exception: when regime_key = "17" (OSS/IOSS) the invoice applies the destination country VAT instead of the Spanish one, so any percentage in the EU range [0, 27] is accepted regardless of the tax type set — including 0 without an exemption reason. - **type** (required) `TaxType`: Tax type by territory: - IVA: Iberian Peninsula and Balearic Islands (4%, 10%, 21%; 2%, 5% and 7.5% only on operations of their period) - IGIC: Canary Islands (0%, 3%, 5%, 7%, 9.5%, 15%, 20%) - IPSI: Ceuta and Melilla (0.5%, 1%, 2%, 4%, 8%, 10%) - OTHER: Configurable 0%-100% Under IVA and IPSI, 0% is not one of these rates: it is the exemption/non-subject sentinel and always travels with an `exemption_reason`. IGIC's 0% is a real rate. See `TaxInfo` for the full rules. - **percentage** (required) `number`: Tax percentage (example: 21) - **regime_key** `RegimeKey`: Regime key according to VeriFactu regulations. Omitted, `01` (general regime) applies: - 01: General regime operation - 02: Export (IVA and IGIC; not IPSI, whose AEAT list is `01, 08, 11, 18, 19, 20`) - 03: Used goods, art, antiques (not accepted, see below) - 04: Investment gold - 05: Travel agencies - 06: Group of entities (not accepted, see below) - 07: Cash basis - 08: Operation subject to another indirect tax — IPSI or IGIC on an IVA line, IPSI or IVA on an IGIC line. It is **not** the general regime of IGIC, which is `01`. - 09: Mediating agencies - 10: Third-party collections - 11: Local rental - 14: VAT pending in certifications (not accepted, see below) - 15: VAT pending successive tract - 17: OSS and IOSS - 18: Equivalence surcharge - 19: REAGYP - 20: Simplified regime **What AEAT requires with each key** (Validaciones VERI*FACTU 3.1.3.15.6), checked on IVA and IGIC lines before the invoice is numbered. Otherwise the request is rejected with `422` and the code in brackets: - `04`: only reverse charge (an `ISP_ART_84_2_*` reason) or an exemption (`REGIME_KEY_CLASSIFICATION_NOT_ACCEPTED`). - `08`: only `exemption_reason: NO_SUJETA_LOCALIZACION`, at 0 % (`REGIME_KEY_CLASSIFICATION_NOT_ACCEPTED`). - `10`: only `exemption_reason: NO_SUJETA_ART_7_9`, on a `STANDARD` invoice whose recipient has a `nif` (`REGIME_KEY_CLASSIFICATION_NOT_ACCEPTED`, `REGIME_KEY_REQUIRES_STANDARD_INVOICE`, `REGIME_KEY_REQUIRES_RECIPIENT_NIF`). - `11` (IVA): a subject line only at 21 %, and no reverse charge (`REGIME_KEY_REQUIRES_VAT_RATE`, `REGIME_KEY_CLASSIFICATION_NOT_ACCEPTED`). - `06` and `14` are not accepted (`REGIME_KEY_NOT_SUPPORTED`): AEAT requires with them data the invoice does not carry (a cost-based taxable base; an operation date after the issue date and a public-administration recipient). - `03` (used goods) is not accepted (`REGIME_KEY_NOT_SUPPORTED`): under it the invoice must not show the tax separately (RD 1619/2012, art. 16.2.c), and it always does. The corrective of an invoice that already carried `03` keeps it. - `05` (travel agencies) and `07` (cash basis) are accepted, and the invoice PDF carries the mention of their regime (RD 1619/2012, art. 6.1 n and p). `07`: no reverse charge, no non-subject reason and, of the exemptions, only art. 20 or `OTRO` (`REGIME_KEY_CLASSIFICATION_NOT_ACCEPTED`). `GET /v1/tax-types` only offers the keys that are accepted. **One exception to "a key you send is the key you get":** when the line ends up carrying an equivalence surcharge — whether you sent `equivalence_surcharge_rate` or it was inherited from the company's tax configuration — a `01` is rewritten to `18`, because a surcharge under the general regime is fiscally incoherent. Send `equivalence_surcharge_rate: 0` explicitly to keep `01`. See `equivalence_surcharge_rate` in the invoice line for the full rules. ## VeriFactuSubmissionStatus Submission status of an invoice's VeriFactu record to AEAT. Single vocabulary for the whole axis: the same values are published in `verifactu.submission_status` of an invoice and accepted by the `verifactu_status` filter of `GET /v1/invoices`, so a value read from an invoice can be fed straight back into the filter. * `PENDING` — queued, AEAT has not answered yet. A temporary AEAT server error also stays `PENDING`: BeeL. retries it automatically, and it only becomes `REJECTED` if the retries run out. * `ACCEPTED` — accepted by AEAT (with or without non-blocking warnings). * `VOIDED` — a cancellation record was accepted by AEAT. * `REJECTED` — rejected by AEAT, or the submission was rejected by the provider before reaching AEAT (see `error_code` / `error_message`). * `NOT_SUBMITTED` — the invoice is issued with VeriFactu enabled but has no live record: the submission fell through (lost event, exhausted retries) and AEAT does not know the invoice exists. Transient right after issuing (the async submission may still be in flight); if it persists, the registration needs to be re-driven. Drafts and scheduled invoices have no submission to describe yet and omit the field. Invoices with `verifactu.enabled = false` are outside this axis and are selected with the `verifactu_enabled` filter. Type: `string` — one of: PENDING, ACCEPTED, VOIDED, REJECTED, NOT_SUBMITTED ## EmailDeliveryStatus Status of an email. The history records every email the system decided to send, not only the ones that went out: an email stopped by policy is listed as REJECTED rather than omitted. - QUEUED: authorised and recorded, not dispatched yet - REJECTED: stopped by policy and never sent (terminal, not retried). In test environments invoices may only be emailed to the account owner's own address (`+tag` aliases included), so a message addressed elsewhere lands here - SENT: successfully sent to the provider - FAILED: sending failed - DELIVERED / BOUNCED / OPENED: reported by the provider's webhooks Type: `string` — one of: QUEUED, REJECTED, SENT, FAILED, DELIVERED, BOUNCED, OPENED ## TaxType Tax type by territory: - IVA: Iberian Peninsula and Balearic Islands (4%, 10%, 21%; 2%, 5% and 7.5% only on operations of their period) - IGIC: Canary Islands (0%, 3%, 5%, 7%, 9.5%, 15%, 20%) - IPSI: Ceuta and Melilla (0.5%, 1%, 2%, 4%, 8%, 10%) - OTHER: Configurable 0%-100% Under IVA and IPSI, 0% is not one of these rates: it is the exemption/non-subject sentinel and always travels with an `exemption_reason`. IGIC's 0% is a real rate. See `TaxInfo` for the full rules. Type: `string` — one of: IVA, IGIC, IPSI, OTHER ## RegimeKey Regime key according to VeriFactu regulations. Omitted, `01` (general regime) applies: - 01: General regime operation - 02: Export (IVA and IGIC; not IPSI, whose AEAT list is `01, 08, 11, 18, 19, 20`) - 03: Used goods, art, antiques (not accepted, see below) - 04: Investment gold - 05: Travel agencies - 06: Group of entities (not accepted, see below) - 07: Cash basis - 08: Operation subject to another indirect tax — IPSI or IGIC on an IVA line, IPSI or IVA on an IGIC line. It is **not** the general regime of IGIC, which is `01`. - 09: Mediating agencies - 10: Third-party collections - 11: Local rental - 14: VAT pending in certifications (not accepted, see below) - 15: VAT pending successive tract - 17: OSS and IOSS - 18: Equivalence surcharge - 19: REAGYP - 20: Simplified regime **What AEAT requires with each key** (Validaciones VERI*FACTU 3.1.3.15.6), checked on IVA and IGIC lines before the invoice is numbered. Otherwise the request is rejected with `422` and the code in brackets: - `04`: only reverse charge (an `ISP_ART_84_2_*` reason) or an exemption (`REGIME_KEY_CLASSIFICATION_NOT_ACCEPTED`). - `08`: only `exemption_reason: NO_SUJETA_LOCALIZACION`, at 0 % (`REGIME_KEY_CLASSIFICATION_NOT_ACCEPTED`). - `10`: only `exemption_reason: NO_SUJETA_ART_7_9`, on a `STANDARD` invoice whose recipient has a `nif` (`REGIME_KEY_CLASSIFICATION_NOT_ACCEPTED`, `REGIME_KEY_REQUIRES_STANDARD_INVOICE`, `REGIME_KEY_REQUIRES_RECIPIENT_NIF`). - `11` (IVA): a subject line only at 21 %, and no reverse charge (`REGIME_KEY_REQUIRES_VAT_RATE`, `REGIME_KEY_CLASSIFICATION_NOT_ACCEPTED`). - `06` and `14` are not accepted (`REGIME_KEY_NOT_SUPPORTED`): AEAT requires with them data the invoice does not carry (a cost-based taxable base; an operation date after the issue date and a public-administration recipient). - `03` (used goods) is not accepted (`REGIME_KEY_NOT_SUPPORTED`): under it the invoice must not show the tax separately (RD 1619/2012, art. 16.2.c), and it always does. The corrective of an invoice that already carried `03` keeps it. - `05` (travel agencies) and `07` (cash basis) are accepted, and the invoice PDF carries the mention of their regime (RD 1619/2012, art. 6.1 n and p). `07`: no reverse charge, no non-subject reason and, of the exemptions, only art. 20 or `OTRO` (`REGIME_KEY_CLASSIFICATION_NOT_ACCEPTED`). `GET /v1/tax-types` only offers the keys that are accepted. **One exception to "a key you send is the key you get":** when the line ends up carrying an equivalence surcharge — whether you sent `equivalence_surcharge_rate` or it was inherited from the company's tax configuration — a `01` is rewritten to `18`, because a surcharge under the general regime is fiscally incoherent. Send `equivalence_surcharge_rate: 0` explicitly to keep `01`. See `equivalence_surcharge_rate` in the invoice line for the full rules. Type: `string` — one of: 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 14, 15, 17, 18, 19, 20 --- Full OpenAPI spec: https://docs.beel.es/api/openapi