Spain VeriFactu: What the New E-invoicing Regime Means for Software Vendors

Spain's e-invoicing landscape is more complex than most EU countries because it's running two parallel regimes. There's the Peppol-based B2B mandate for large companies, and then there's VeriFactu — a completely different concept that applies to billing software rather than individual transactions. If you build software that generates invoices used by Spanish businesses, VeriFactu affects you directly.

Understanding VeriFactu requires clearing up a common misconception: this is not about transmitting a structured XML invoice to a buyer or to a clearance platform. It's about making invoice records tamper-proof and optionally registering them with the Spanish tax authority (AEAT — Agencia Estatal de Administración Tributaria).

What VeriFactu Actually Is

VeriFactu stands for "Verificación Facturas" — invoice verification. The regime comes from the Verifactu Regulation (Real Decreto 1007/2023 and the accompanying technical specification from AEAT), which mandates that any billing software used by Spanish taxpayers must:

1. Generate a cryptographic fingerprint (Huella) for each invoice record
2. Chain each invoice's Huella to the previous invoice's Huella, creating a tamper-evident ledger
3. Include a QR code on the human-readable invoice that allows AEAT to verify the record
4. Optionally (but strongly incentivized) send the invoice record to AEAT's VERI*FACTU system in real time

The key insight: the Huella is the compliance artifact, not the XML delivery. A business can choose not to submit to AEAT in real time (non-Verifactu mode), but then faces stricter audit requirements. Businesses that register invoices with AEAT in real time get the "Verifactu" status and simplified audit obligations.

The Hash Chain Explained

Each invoice generates a Huella calculated as a SHA-256 hash of a concatenated string of invoice fields: the NIF (tax ID) of the issuer, the invoice series and number, the invoice date, the gross amount, and — critically — the Huella of the immediately preceding invoice from the same issuer.

This creates a chain. You cannot retroactively insert, modify, or delete an invoice without breaking the chain for every subsequent invoice. That's the tamper-evidence model.

The first invoice in a series uses a sentinel value (a zero hash) as the "previous Huella." After that, each invoice depends on the prior one.

AEAT can verify any invoice's authenticity by:

1. Scanning the QR code on the invoice
2. Looking up the record in their VERI*FACTU system (if submitted in real time)
3. Reconstructing the hash from the invoice fields and checking it matches

The QR Code and CSV

Every VeriFactu-compliant invoice must include:

• A QR code that encodes a URL pointing to AEAT's verification portal, with the invoice's NIF, series/number, date, amount, and Huella as query parameters
• A CSV (Código Seguro de Verificación) — a short alphanumeric code derived from the Huella that serves as a human-readable verification reference

The QR code format is specified by AEAT and must include the following URL structure:

https://www2.agenciatributaria.gob.es/wlpl/TIKE-CONT/ValidarQR?nif=...&numserie=...&fecha=...&importe=...&huella=...

Both the QR and CSV must appear on any printed or PDF representation of the invoice. They are not transmitted to the buyer separately — they're embedded in the invoice document itself.

What This Means for Software Vendors

If you build billing software, ERP connectors, or invoicing tools used by Spanish businesses, your software is now in scope. The obligation is on the software to implement the hash chain correctly — not on the individual business to bolt it on afterward.

Specifically, your software must:

• Maintain a persistent, ordered log of invoice records (series + sequence)
• Compute the SHA-256 Huella correctly per AEAT's field concatenation spec
• Generate compliant QR codes and CSVs for inclusion in invoice output
• Optionally submit records to AEAT's VERI*FACTU web service in real time
• Handle AEAT's response (accepted, rejected, or queued) and surface errors

The spec is detailed and the hash computation must be exact — a single field ordering or encoding error produces a different hash, and AEAT's verification will fail.

The Submission Flow (Real-Time Mode)

For businesses opting into real-time AEAT submission (which most should, given the audit trade-off), the flow is:

1. Invoice is created in your system
2. Hash chain is computed (Huella for this invoice based on invoice fields + previous Huella)
3. QR code and CSV are generated
4. An XML record is submitted to AEAT's VERI*FACTU endpoint via SOAP or REST (AEAT supports both)
5. AEAT returns a status: accepted (CSV confirmed), rejected (with error codes), or queued for processing
6. The invoice is only legally final once AEAT has accepted it (in real-time mode)

Rejection reasons are encoded — AEAT returns specific error codes for issues like duplicate invoice numbers, malformed Huellas, or invalid NIF formats.

How Clearvo Handles This

Clearvo's API abstracts the entire cryptographic layer. When you submit a Spanish invoice to Clearvo:

• We maintain the hash chain state for each issuer NIF and invoice series
• We compute the Huella and chain it to the previous invoice automatically
• We generate the QR code and CSV values and return them in the API response for you to embed in your invoice output
• We submit the record to AEAT's VERI*FACTU system and return the acceptance status
• We handle AEAT's async response model and surface normalized status codes

You don't implement SHA-256 concatenation logic. You don't manage the hash chain ledger. You don't write a SOAP client for AEAT's submission endpoint. You call the Clearvo API, pass invoice fields, and receive back the QR code URL, CSV, Huella, and submission status.

For software vendors adding VeriFactu support to an existing product, this is the difference between a multi-week compliance engineering project and a one-day API integration.

VeriFactu is a genuinely novel compliance model — it's closer to an audit log registration system than a traditional e-invoicing mandate. Getting the hash chain wrong isn't a cosmetic issue; it breaks AEAT verification for every subsequent invoice in the series. If you're building for Spanish businesses, the cryptographic correctness requirement is non-trivial. That's what Clearvo is built to handle.