Spain runs its invoicing on three rulebooks, not one. Royal Decree 1619/2012 fixes what every invoice must contain. Verifactu (RD 1007/2023) stamps security marks onto it from January 2027. And the Crea y Crece mandate (RD 238/2026) repackages those same fields as structured data: EN 16931 semantics, written in UBL 2.5 syntax.
Key Takeaways
- Article 6 of RD 1619/2012 lists the mandatory fields for a full invoice; Article 7 covers the shorter simplified invoice set.
- Verifactu adds a QR code to every software-issued invoice from 1 January 2027 for companies and 1 July 2027 for the self-employed.
- Domestic B2B e-invoices must follow the EN 16931 semantic model; Spain's public platform (SPFE) accepts UBL 2.5 syntax only.
- Crea y Crece deadlines start 12 and 24 months after the SPFE Ministerial Order enters into force, projected as October 2027 and October 2028.
- A field missing today becomes an automatic SPFE rejection later, so clean invoice data is the cheapest compliance fix available.
The mandatory e-invoice fields in Spain are the data elements every invoice must carry to be valid for VAT purposes. Article 6 of Royal Decree 1619/2012 lists them for a full invoice (factura completa). Article 7 lists the shorter set for a simplified invoice (factura simplificada).
The content rules have not changed with digitalisation. What has changed is enforcement. On paper, a missing field surfaced only during an inspection, sometimes years later. In the structured world, the field either exists in the XML or it does not, and the receiving system knows instantly.
Three regimes now touch the same invoice:
In simple terms, we can say that RD 1619/2012 decides what to say, Verifactu decides how to prove it was said, and Crea y Crece decides how to transmit it.
At a minimum, the AEAT expects every full invoice to carry the following fields:
The complete legal list sits in Articles 6 and 7 of Royal Decree 1619/2012, available on the BOE, and the AEAT's e-Office carries practical invoicing guidance.
A full invoice is required for all B2B transactions and whenever the recipient needs to deduct input VAT. Article 6 of RD 1619/2012 sets out the Spain full invoice mandatory fields:
One field trips people up more than any other: the operation date. Software defaults it to the issue date, and nobody checks. If goods shipped in March and the invoice went out in April, the invoice needs both dates. Inspectors look for this because it affects the VAT accrual period.
IRPF withholding deserves a mention too. When a professional invoices a Spanish business, the invoice shows the retention (generally 15%, or 7% for new professionals during their first year of activity and the following two years, as well as in certain other cases prescribed by law). RD 1619/2012 does not technically list it as a mandatory field, but the recipient needs it to file Form 111, so in practice it is non-negotiable.
Simplified invoices exist for low-value transactions: up to €400 including VAT as a general rule, or up to €3,000 for specific sectors such as retail, hospitality and passenger transport. Article 7 of RD 1619/2012 sets the Spain simplified invoice fields:
Compare the two lists and the gap is obvious: the customer does not appear anywhere, and neither does a separate VAT breakdown. That is deliberate. The format exists to keep small sales quick, which is exactly why sole traders, who account for more than half of Spain's registered businesses, run on it daily.
But there is a catch, and it costs buyers real money. A standard simplified invoice does not support VAT deduction. If the customer wants to deduct the input VAT, the supplier must issue a "qualified" simplified invoice that adds the customer's NIF, address, and the VAT amount broken down separately. A restaurant ticket without the company's NIF on it is a sunk cost, not a deductible expense. Finance teams reviewing expense claims see this every single month.
Worth knowing for the road ahead: simplified invoices sit outside the Crea y Crece B2B mandate. Verifactu, however, applies to them fully. Every simplified invoice issued through software will carry a QR code from 2027.
Field | Full invoice | Simplified invoice |
| Invoice number and series | Mandatory | Mandatory |
| Issue date | Mandatory | Mandatory |
| Operation date (if different) | Mandatory | Mandatory |
| Supplier name and NIF | Mandatory | Mandatory |
| Supplier address | Mandatory | Not required |
| Customer name and address | Mandatory | Not required (unless qualified) |
| Customer NIF | Mandatory for B2B, reverse charge, intra-EU | Only if buyer needs VAT deduction |
| Description of goods or services | Detailed, with unit price and discounts | Identification of the supply |
| Taxable base per VAT rate | Mandatory | Not required |
| VAT rate | Mandatory | Mandatory (or "IVA incluido") |
| VAT amount shown separately | Mandatory | Only on qualified simplified invoices |
| Total consideration | Standard practice | Mandatory |
| Exemption or reverse charge legend | Mandatory where applicable | Where applicable |
| Verifactu QR code (from 2027) | Mandatory | Mandatory |
EN 16931 is the European semantic standard for e-invoices, developed by CEN under Directive 2014/55/EU. It defines roughly 170 business terms (BTs), each with an identifier and a cardinality. The mandatory core includes the invoice number (BT-1), issue date (BT-2), invoice type code (BT-3), currency (BT-5), seller name (BT-27) and country, buyer name (BT-44), the document totals, a VAT breakdown per category, and at least one invoice line carrying quantity, unit, net amount, item name, net price and a VAT category code (BT-151).
Map that against Article 6 of RD 1619/2012 and the overlap is almost complete. The Spain EN 16931 invoice fields are, in essence, the Spanish mandatory fields wearing European identifiers. BT-1 is the número de factura. BT-118, the VAT category code, even has dedicated codes for Spanish territories: L for Canary Islands IGIC and M for Ceuta and Melilla IPSI.
The 2017 version of EN 16931 could not express several things Spanish invoicing law demands: corrective invoices under Article 15 of the invoicing regulation, IRPF withholdings, amounts advanced on behalf of a client (suplidos), and the equivalence surcharge (recargo de equivalencia). This gap is precisely why Spain waited for the revised standard.
That revision arrived as EN 16931-1:2026. It expands the semantic model to support more complex B2B invoicing scenarios and forms the basis for the UBL 2.5 implementation adopted for Spain's B2B e-invoicing framework. AEAT anchored the Spanish system to this version because it natively supports the national cases, without bolting on workarounds.
Royal Decree 238/2026, published in the BOE on 31 March 2026 and in force since 20 April 2026, operationalises the Crea y Crece mandate. Its effective application is deferred until the Ministerial Order governing the SPFE enters into force. Once that Ministerial Order is published, compliance deadlines run as follows: 12 months for businesses whose turnover exceeded €8 million in the prior calendar year, and 24 months for all other businesses and professionals.
As of the date of this document, the Ministerial Order had not yet been published in the BOE; the October 2027 and October 2028 dates cited in some sources are projections based on an assumed Ministerial Order entry into force of 1 October 2026 and will shift if that date changes.
The Spain Crea y Crece e-invoice data requirements work at two levels.
At the semantic level, every B2B e-invoice must conform to EN 16931. Private exchange platforms can move invoices in UBL, CII, EDIFACT or Facturae between themselves.
At the public level, the rules narrow sharply. The Solución Pública de Facturación Electrónica (SPFE), the AEAT-run platform that acts as universal repository, works exclusively in UBL.
Even when two businesses exchange invoices through private platforms, a faithful copy (copia fiel) in UBL must land in the SPFE at the moment of issuance. Facturae, despite being Spain's own B2G format, cannot be used for submissions to the public solution.
The Spain SPFE UBL e-invoice required elements go beyond the European core:
One design choice deserves attention because it shifts risk onto the issuer. Validation is two-layered: OASIS XSD schemas check the UBL structure, and Schematron rules (updated to the EN 16931 2026 version) check the business logic.
Both run at intake, and AEAT will not offer a production validation service. If the file fails, it bounces. Businesses must embed both validation layers in their own outbound pipeline. Anyone planning to "test against the live system" is planning to fail publicly.
A caveat, because accuracy matters more than tidiness: the Ministerial Order was still in draft as of mid-2026, with public consultation closed on 8 May 2026. The technical baseline of UBL 2.5 on EN 16931:2026 comes from AEAT's own developer documentation published on 1 June 2026. Details can still shift before the BOE publication.
Verifactu changes nothing in the list of mandatory content fields. RD 1619/2012 still governs what the invoice says. What Verifactu regulates is the software that produces it, and it leaves two visible marks on every invoice, full and simplified alike:
A QR code. Mandatory on every invoice issued through a computerised invoicing system (SIF). The customer, or an AEAT inspector, scans it to verify the invoice against the tax agency's records.
The legend "VERI*FACTU" or "Factura verificable en la sede electrónica de la AEAT". This appears when the system operates in Verifactu mode, meaning invoice records are transmitted to AEAT in real time. Systems in non-transmission mode keep signed local records and carry the QR without the legend.
Under the surface, each invoice generates a billing record protected by a chained SHA-256 hash (the huella). Every record's fingerprint includes the previous one. Delete or alter an old invoice and the chain breaks visibly. That is the whole anti-fraud mechanism in one sentence.
The deadlines moved twice, so ignore anything citing 2026. These dates mark when the Verifactu software rules apply, meaning the point from which invoices must be issued through compliant systems. Royal Decree-law 15/2025 fixed them: 1 January 2027 for Corporate Tax payers, 1 July 2027 for the self-employed and everyone else. Businesses already reporting through SII are exempt, and the Basque Country and Navarra follow their own regional systems instead, such as TicketBAI.
The judgement call worth making early: Verifactu and Crea y Crece are separate obligations that most B2B businesses will carry simultaneously. Complying with one does not satisfy the other. A single software decision should cover both, because retrofitting a Verifactu-only system for UBL 2.5 in 2027 is the expensive path.
The Spain B2B e-invoice mandatory content fields checklist has not really grown. What has grown is the number of systems that check it. RD 1619/2012 defines the fields. Verifactu adds a QR code and a hash chain from January 2027. The Crea y Crece framework transmits those same fields as EN 16931 data in UBL 2.5. Its compliance deadlines begin 12 months after the SPFE Ministerial Order enters into force, currently projected as October 2027 but not yet confirmed in the BOE.
The businesses that will sail through are the ones treating this as a data quality project, not a formatting project. Clean master data (correct NIFs, complete addresses, proper series management, accurate operation dates) passes every validation layer that is coming. Messy data fails all of them, just faster than before.