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. 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 |
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 and Enabling VeriFactu for a NIF.
How issuance maps to VeriFactu
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
Pick the right invoice type
F1, F2 and R1–R5 explained.
Standard vs simplified
No identified recipient on a simplified invoice, the 3,000 € cap, and what BeeL. enforces.
Corrective invoices
R1–R5 reasons, PARTIAL vs TOTAL, and worked examples for each scenario.
Classify each line correctly
Subject / not subject / exempt, with the S1, S2, N1, N2, E1–E6 cheat sheet.
Customer & territory scenarios
International customers
B2B intra-EU, B2C with OSS, exports, services to non-EU clients.
Territorial taxes
IVA, IGIC (Canary Islands), IPSI (Ceuta & Melilla) — when to use each.
Equivalence surcharge
Equivalence surcharge on B2B retailer lines.
Regime keys
The regime_key catalogue — OSS, criterio de caja, and more.
Operations
Enabling VeriFactu for a NIF
The configuration ladder, the representation, and the blockers that stop issuing.
Testing in sandbox
Always on, AEAT's test environment, no representation to sign.
Submission states
What each VeriFactu status means, when BeeL. keeps checking, when you must act.
Handling AEAT rejections
Reading REJECTED and accepted-with-errors, what to do per code, and reconciliation.
Auto-submit policy
The exact conditions under which BeeL. sends an invoice to AEAT for you.
Cancel vs amend
Void vs subsanación vs corrective invoice — pick the right operation.
QR code and the invoice PDF
When the QR exists, why the PDF waits for it, and rendering your own.