Spain mandate
Spain does not have one invoicing mandate — it has several, built up over a decade and run by different authorities. Before integrating, it is worth knowing which one applies to you, because they impose different obligations and only one of them is covered by this API.
What this API covers. A-Cube implements VERI*FACTU only. The other Spanish regimes described further down — Crea y Crece, TicketBAI, SII, Facturae/FACe — are outside the scope of the ES API today. They are summarised here so you can place your own obligations correctly; support for some of them may be added later.
VERI*FACTU
VERI*FACTU is the regime that governs billing software. It is the Spanish answer to invoice manipulation: rather than regulating how invoices are exchanged, it regulates the system that produces them, and requires that system to leave a trail that cannot be altered after the fact.
It is a fiscalization and e-reporting regime, not an e-invoicing one. Nothing is delivered to your customer through it. You keep sending the invoice to the buyer however you already do — PDF, email, paper, your own portal — while a parallel fiscal record of that invoice goes to the Agencia Estatal de Administración Tributaria (AEAT).
What the regime requires
- A billing record for every invoice. Each issued invoice produces a registro de facturación de alta; cancelling one produces a registro de anulación.
- A hash chain. Every record carries a huella computed over its own contents and the previous record's hash, so removing or editing an invoice after the fact breaks the chain visibly.
- A QR code on the invoice. The printed or electronic invoice must carry a QR that resolves to the AEAT verification service, letting the recipient check that the invoice was really declared.
- A "factura verificable" legend, when the records are actually sent to AEAT.
The two modes
The regulation allows a compliant system (Sistema Informático de Facturación, SIF) to work in either of two modes:
- VERI*FACTU — each record is transmitted to AEAT as the invoice is issued. Records that reach AEAT carry a presumption of compliance, and the taxpayer is relieved of keeping the local anti-tamper event log.
- non-VERI*FACTU — records stay in the taxpayer's own system, protected by a digital signature, the hash chain and an event log, and are produced on demand during an inspection.
A-Cube operates in VERI*FACTU mode, as a system of remisión de registros de facturación: it builds the records and sends them to AEAT on the legal entity's behalf, so an integrated company issues verifiable invoices without running its own compliant software.
Certification
There is no AEAT certification to obtain. Instead, whoever produces the invoicing software issues a signed declaración responsable stating that the system meets the regulation, and keeps it available for the tax authority. If you resell or white-label an invoicing product built on this API, that declaration is yours to publish — AEAT provides a template.
Who is in scope, and when
The obligation is phased in, and the dates have been pushed back more than once. In outline: it reaches companies first and self-employed taxpayers later, and taxpayers who already report through SII or TicketBAI are outside it — they satisfy the anti-fraud requirement through those systems instead.
Confirm your own start date with AEAT or your tax advisor before relying on it. The entry-into-force dates have moved repeatedly and are set outside this documentation.
- AEAT VERI*FACTU portal: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu.html
- Boletín Oficial del Estado (BOE): https://www.boe.es/
The legal chain
- Ley 11/2021 — the anti-fraud law requiring billing software to guarantee the integrity, preservation, traceability and inalterability of invoicing records.
- Real Decreto 1007/2023 — the VERI*FACTU Regulation, which defines SIF requirements and the two compliance modes. Subsequently amended, including the timetable.
- Orden HAC/1177/2024 — the technical specification: record layout, hash chaining, the QR code and the ValidarQR verification service.
The rest of the Spanish landscape
These regimes are not implemented by this API. They are listed so you can tell them apart from VERI*FACTU — they are frequently confused with it, and with each other.
Crea y Crece — B2B e-invoicing
Ley 18/2022 introduces mandatory structured e-invoicing between businesses established in Spain, together with an obligation to report invoice status (accepted, rejected, paid). Its stated purpose is to attack late payment, not fraud. Invoices will be exchanged through a free public AEAT platform or through interoperable private platforms, using EN 16931-compliant formats.
This is the regime that is genuinely e-invoicing, and it is a separate track from VERI*FACTU: one regulates the software and the reporting to the tax agency, the other regulates how invoices move between businesses. Its implementing decree and ministerial order set the timetable — check the current position before planning around it.
Facturae and FACe — B2G
Facturae is Spain's national XML invoice format, mandatory for invoicing public administrations, submitted through the FACe platform. This API uses Facturae 3.2.2 as its input format — see Formats — but does not submit anything to FACe. B2G delivery remains a separate obligation, and a supplier invoicing a public body may have to satisfy both it and VERI*FACTU.
TicketBAI — Basque Country
The Basque provinces of Álava, Bizkaia and Gipuzkoa have their own fiscal autonomy and their own anti-fraud system, TicketBAI: certified software, a signed XML per invoice sent to the provincial authority, a QR and an identifier on the invoice. Taxpayers under TicketBAI are outside VERI*FACTU. Navarra has announced a comparable system of its own.
SII — near-real-time VAT reporting
Suministro Inmediato de Información requires large taxpayers, VAT groups and monthly-refund registrants to report VAT ledger data to AEAT within a few days. It has been in force since 2017 and is a separate, pre-existing obligation: VERI*FACTU does not replace it, and taxpayers under SII are outside VERI*FACTU.
What this means for your integration
If your taxpayers fall under VERI*FACTU, registering them as legal entities and issuing through this API covers the regime end to end: A-Cube builds each billing record, chains it, reports it to AEAT and returns the QR for you to print.
You register the taxpayer once with
POST /legal-entities. From then on,
reporting happens automatically as part of the issuing flow — there is no separate
"report to AEAT" call — and you track the outcome through the
invoice status.
If they fall under TicketBAI or SII instead, they are outside VERI*FACTU and this API does not yet serve their obligation. And whatever regime applies, delivering the invoice to the buyer remains yours — see Introduction for where A-Cube starts and stops.