# Overview

How BeeL. handles VeriFactu compliance — what BeeL. does for you, what you control, and where to learn each scenario.

VERI\*FACTU is the modality of the RD 1007/2023 in which a billing system submits every billing record (*registro de facturación*) to AEAT as it is generated (article 16). BeeL. works only in that modality: for each invoice issued through it, BeeL. generates the record, computes and chains its hash and submits it. You decide **which kind of invoice** to issue and **for whom**, and BeeL. maps the rest.

This section is the *when-to-use-what* guide. The endpoint reference for the VeriFactu and Invoicing APIs lives in the [API Reference](/verifactu/getCompanyVeriFactuConfiguration). Here we explain the fiscal decisions behind each request.

## At a glance

| | |
|---|---|
| **Who the RD 1007/2023 applies to** | The taxpayers listed in its article 3.1 who use a billing system — Corporate Tax payers, self-employed people with an economic activity, and others — with the exclusions of articles 3.3 and 4. For the Basque Country and Navarre, it applies to taxpayers with their fiscal domicile in common territory (article 1.3) |
| **When** | The regulation requires adapted billing systems before **2027-01-01** for Corporate Tax payers and before **2027-07-01** for the rest (RD-ley 15/2025). VERI\*FACTU is one of the two modalities it allows |
| **What BeeL. does** | Generates, chains and submits the billing record of each invoice issued through it |
| **What you choose** | `type` (STANDARD / SIMPLIFIED / CORRECTIVE), `rectification_code` (R1–R5) for correctives, `exemption_reason` per line, recipient identification |
| **What BeeL. never does** | Recalculate the totals you sent — your numbers are the fiscal truth |

<Callout type="info">
  **The NIF decides, not the invoice.** Whether an issued invoice goes to AEAT is resolved at issue time from the issuing NIF: if the NIF is under the VeriFactu regime in that environment, every invoice it issues is registered; if it is not, none is. There is no per-invoice, per-series or per-connection switch. See [Auto-submit policy](/verifactu/auto-submit) and [Enabling VeriFactu for a NIF](/verifactu/enabling-verifactu).
</Callout>

> **Rules that apply here:** [DAT-011 · Adapted billing systems are mandatory from 1 January 2027 or 1 July 2027](/rules/dates#dat-011)

## How issuance maps to VeriFactu

```text
1. You POST /invoices or /invoices/{id}/issue
2. BeeL validates the invoice (NIF, totals, tipo factura)
3. BeeL emits the invoice locally (assigns number, freezes totals)
4. If the NIF is under the VeriFactu regime → BeeL submits a registro de facturación
5. AEAT responds (PENDING → ACCEPTED or REJECTED; a later cancellation lands on VOIDED)
6. BeeL exposes the resulting status on the invoice (and via webhooks)
```

## Where to start

<Cards>
  <Card title="Pick the right invoice type" href="/verifactu/invoice-types">
    F1, F2 and R1–R5 explained.
  </Card>
  <Card title="Standard vs simplified" href="/verifactu/simplified-vs-standard">
    No identified recipient on a simplified invoice, the 3,000 € cap, and what BeeL. enforces.
  </Card>
  <Card title="Corrective invoices" href="/verifactu/corrective-invoices">
    R1–R5 reasons, PARTIAL vs TOTAL, and worked examples for each scenario.
  </Card>
  <Card title="Classify each line correctly" href="/verifactu/tax-classification">
    Subject / not subject / exempt, with the S1, S2, N1, N2, E1–E6 cheat sheet.
  </Card>
</Cards>

### Customer & territory scenarios

<Cards>
  <Card title="International customers" href="/verifactu/international-customers">
    B2B intra-EU, B2C with OSS, exports, services to non-EU clients.
  </Card>
  <Card title="Territorial taxes" href="/verifactu/territorial-taxes">
    IVA, IGIC (Canary Islands), IPSI (Ceuta & Melilla) — when to use each.
  </Card>
  <Card title="Equivalence surcharge" href="/verifactu/equivalence-surcharge">
    Equivalence surcharge on B2B retailer lines.
  </Card>
  <Card title="Regime keys" href="/verifactu/regime-keys">
    The `regime_key` catalogue — OSS, criterio de caja, and more.
  </Card>
</Cards>

### Operations

<Cards>
  <Card title="Enabling VeriFactu for a NIF" href="/verifactu/enabling-verifactu">
    The configuration ladder, the representation, and the blockers that stop issuing.
  </Card>
  <Card title="Testing in sandbox" href="/verifactu/testing-in-sandbox">
    Always on, AEAT's test environment, no representation to sign.
  </Card>
  <Card title="Submission states" href="/verifactu/submission-states">
    What each VeriFactu status means, when BeeL. keeps checking, when you must act.
  </Card>
  <Card title="Handling AEAT rejections" href="/verifactu/handling-rejections">
    Reading `REJECTED` and accepted-with-errors, what to do per code, and reconciliation.
  </Card>
  <Card title="Auto-submit policy" href="/verifactu/auto-submit">
    The exact conditions under which BeeL. sends an invoice to AEAT for you.
  </Card>
  <Card title="Cancel vs amend" href="/verifactu/cancel-and-fix">
    Void vs *subsanación* vs corrective invoice — pick the right operation.
  </Card>
  <Card title="QR code and the invoice PDF" href="/verifactu/qr-and-pdf">
    When the QR exists, why the PDF waits for it, and rendering your own.
  </Card>
</Cards>

### Reference

<Cards>
  <Card title="Examples cookbook" href="/verifactu/examples-cookbook">
    Runnable curl + JSON for every common AEAT scenario — F1/F2, multi-IVA, intra-EU, exports, RE, ISP, correctives R1–R5.
  </Card>
  <Card title="What AEAT receives" href="/verifactu/what-aeat-receives">
    The description, total, number and recipient BeeL. sends for your invoice — and why the total can differ.
  </Card>
</Cards>

---

Full OpenAPI spec: https://docs.beel.es/api/openapi