VeriFactu vs non-VeriFactu: which to choose in 2027

What is VeriFactu and what is non-VeriFactu?

Spanish Royal Decree 1007/2023 establishes two operating modes within the same regulatory framework, both fully legal from 2027 onwards. The essential difference is how the invoicing software interacts with the Spanish tax authority (AEAT).

In VeriFactu mode, each invoice issued generates an invoicing record that the SIF sends automatically and in real time to the AEAT electronic site. The administration acknowledges receipt, assigns an identifier and the invoice carries the literal mention "VERI*FACTU" together with the tax QR code. The taxpayer delegates custody of the fiscal record to AEAT.

In non-VeriFactu mode, the SIF does not transmit each invoice. Instead, it stores records locally, chained via SHA-256 hash and electronically signed with XAdES, for 10 years. AEAT can request them at any time (audit, inspection, verification) and the response must be produced as XML conformant to Order HAC/1177/2024.

Both modes require the mandatory tax QR on every invoice, the chained hash and full preservation. Both are governed by RD 1007/2023 and its technical development, Order HAC/1177/2024. The choice rests with the taxpayer (through their software), not with AEAT.

Full comparison table

Summary of the nine key technical requirements that differentiate Spain's two anti-fraud invoicing modes under RD 1007/2023 and Order HAC/1177/2024.

Source: RD 1007/2023 and Order HAC/1177/2024. Informational only; does not replace individualised tax advice.

When to choose VeriFactu

AEAT explicitly recommends VeriFactu as the default mode, and most certified software on the market ships it as the initial configuration. It is operationally the simpler choice because the very act of submitting to the electronic site acts as evidence: the taxpayer does not need to custody the full chain of records to defend themselves in case of inspection.

The ideal profile for VeriFactu includes:

• ·Self-employed and professionals with low or medium volume (fewer than 50,000 invoices/year) and cloud-based invoicing.
• ·Retail, hospitality and small-commerce SMEs already issuing tickets with a connected POS and willing to delegate fiscal custody.
• ·Service companies (consultancies, agencies, advisory firms) with regular invoicing and stable connectivity.
• ·Tax advisory firms managing multiple clients who want to audit compliance directly from the AEAT site instead of requesting backups.
• ·B2C-facing sectors where the citizen can verify the invoice by scanning the QR against the AEAT site — a transparency and brand image gain.

VeriFactu reduces the evidential burden on the taxpayer: if AEAT already holds the record, there is no need to defend the hash chain in case of dispute. In exchange, it requires stable connectivity during issuance (with a tolerance margin for retransmission if a temporary outage occurs).

When to choose non-VeriFactu

Non-VeriFactu is not an exception or a "softer" alternative: it is a technically more demanding mode that keeps the records physically under the taxpayer's control, but imposes mandatory XAdES signature and full custody for 10 years. It makes sense in specific scenarios.

Profiles where non-VeriFactu fits better:

• ·High volume (>1M invoices/year): massive real-time submissions can saturate the link or introduce unacceptable latency in large retail POS. Deferred local registration is more efficient.
• ·Environments without stable connectivity: construction sites, transport, travelling events, rural or industrial installations with frequent outages. Non-VeriFactu allows offline operation and hash-chain integrity without forced retransmission.
• ·Highly sensitive data: private healthcare, law firms or defence, where the taxpayer wants to minimise the volume of information transmitted in real time to administrative systems, sticking to the legal minimum.
• ·Companies with internal data sovereignty policies: multinational groups that require fiscal records to reside on their own infrastructure before any transmission to a third party, including AEAT.

Important: non-VeriFactu does not exempt you from complying with RD 1007/2023. If AEAT requests the records, they must be delivered intact, chained and signed, in the XML format set out in Order HAC/1177/2024, within the established deadline. Failure to deliver is equivalent to not having registered at all.

VeriFactu vs SII: how they differ

VeriFactu is commonly confused with SII (Immediate Supply of VAT Information, Spain's real-time VAT ledger system), but they are two distinct systems with different scopes of application.

SII is a system of real-time VAT books in force since 2017 for large companies (turnover > 6M EUR), VAT groups, REDEME (monthly VAT refund register) and the special travel-agency regime. It submits the books of issued and received invoices — not the full invoice — within 4 working days.

VeriFactu, by contrast, is a system of chained invoice records with QR and hash that covers the remaining universe: self-employed, SMEs and mid-sized companies not within SII. It applies from 2027 and submits each invoicing record (not the VAT ledger) in real time at issuance, not afterwards.

Companies inside SII are exempt from VeriFactu. This is established in art. 3 of RD 1007/2023. SII already covers the information that VeriFactu seeks, so AEAT avoids duplication. If your company moves from SII to the general regime (for example by falling below the 6M EUR threshold), you must switch to VeriFactu or non-VeriFactu from the exit date.

Can I change modes later?

Yes. RD 1007/2023 does not set the mode as an irreversible decision: the taxpayer can move from non-VeriFactu to VeriFactu (or vice versa) whenever they choose. AEAT does not require prior communication: the SIF's behaviour itself declares the mode in use (if a record reaches the AEAT site, it is VeriFactu; if it does not, it is non-VeriFactu).

That said, the switch has technical and audit implications. When moving from non-VeriFactu to VeriFactu you must:

• 1.Close the current hash chain with a final XAdES-signed record.
• 2.Generate a new initial VeriFactu record that links to the previous one by hash.
• 3.Start submitting to AEAT in real time from the next invoice onwards.
• 4.Keep prior non-VeriFactu records for the required 10 years, accessible in XML format.

With Dokuflex, the mode switch is a configuration toggle: no data migration or re-issuance is required. The chained hash is preserved across modes and previous records remain auditable. This matters because, depending on the operational scenario, a company may start in non-VeriFactu for an internal pilot and move to VeriFactu in production, or the reverse if it discovers connectivity limitations.

Sanctions for choosing the wrong mode (Law 11/2021, LGT art. 201 bis)

Choosing the wrong mode — or, worse, operating without complying with either — exposes you to specific penalties introduced by Spain's Law 11/2021 on anti-fraud measures, which added article 201 bis to the General Tax Law (LGT).

The principal amounts are:

• ·Manufacturers and resellers of non-homologated SIF software: fixed fine of 150,000 EUR per fiscal year and computer system.
• ·Users (taxpayers) operating with a non-compliant SIF: fixed fine of 50,000 EUR per fiscal year.
• ·Keeping double accounting or falsifying records: proportional fine of 2% of annual turnover, with a 1,000 EUR floor.
• ·Missing chained hash, QR or mandatory mention on the invoice: 150 EUR per non-compliant invoice, with an aggregate cap.

The most common error expected by tax-law commentary is operating in VeriFactu mode and silently stopping transmission (through misconfiguration, prolonged network outage or SIF crash) without resuming submission. AEAT can detect this automatically: a break in the record flow triggers an alert and opens a sanctions procedure. That is why it is critical for the SIF to provide automatic retransmission and monitoring of submission errors.

Decision by taxpayer profile

Guidance checklist by taxpayer type. Does not substitute individualised assessment by your tax advisor.