Skip to main content
Blog

Verifactu: what it requires from freelancers and SMEs, and from when

What Verifactu is, who is covered by it, from what date, and what has to change in the way you invoice if you are a freelancer or a small business in Spain.

6 min read

Verifactu is not a new app or a one-off procedure: it is a change in the rules for how the software you use to invoice has to behave. If you issue invoices with a management program, a template connected to a database or any "computerised invoicing system" (SIF in Spanish), it affects you directly, whether you are a freelancer or a small business.

What Verifactu is (and what it is not)

Verifactu is the popular name for the Regulation governing the requirements for computerised invoicing systems (Royal Decree 1007/2023, which develops article 29.2.j of Law 11/2021 on measures to prevent and combat tax fraud). Its aim is simple to state and quite a bit more laborious to meet: that no invoicing software can be used to hide, alter or delete sales after they have been recorded.

It is not a new VAT scheme and it does not replace mandatory business-to-business e-invoicing (that is a different regulation, with its own timetable). Verifactu governs the software, not the format of the invoice you hand to your customer.

Who is covered and from when

The obligation reaches practically anyone or any company that invoices using a computer program: freelancers, SMEs, professionals and companies. The original timetable in the Regulation (RD 1007/2023) set 1 January 2026 for companies subject to Corporate Income Tax and 1 July 2026 for freelancers and other taxpayers, but at the end of 2025 an extension was approved that pushes it back:

  • 1 January 2027: mandatory for companies (S.L., S.A., etc.).
  • 1 July 2027: mandatory for freelancers and individual professionals.

These are the dates in force at the time of writing, but the timetable has already moved once: if you are reading this later, confirm on the Spanish Tax Agency's electronic office that there has been no new postponement before making any timing decision.

What your invoicing software has to comply with

This is the important part if you are not the one programming: responsibility for the software complying is not only the vendor's, it also falls on whoever uses it. Software compliant with Verifactu has to guarantee:

  • Integrity: an invoicing record that has already been generated cannot be modified or deleted.
  • Retention: records are kept accessible for the legal period (at least 4 years).
  • Accessibility and legibility: the Tax Agency has to be able to access the records when it requires them.
  • Traceability: each invoice is chained to the previous one through a fingerprint (hash), so that any later alteration breaks the chain and is detectable.
  • Tamper-resistance: every system event (invoices, cancellations, start-up or shutdown events) is recorded, not just the "good" invoices.

The tamper-resistant invoicing record

In practice, each invoice generates a record with a set of fixed data and a hash that depends on the content of the previous invoice. Simplified, a record looks like this:

{
  "invoiceNumber": "2026-0142",
  "issueDate": "2026-07-10",
  "totalAmount": 484.0,
  "previousHash": "3f9a2c...",
  "currentHash": "8e21b0...",
  "generatedAt": "2026-07-10T09:15:32+02:00"
}

You do not need to generate this by hand or understand the cryptography behind it: it is your invoicing software that must do it automatically. What you do need to know is that a spreadsheet or a Word document with an invoice template does not comply with this under any circumstances, even if it works for invoicing today.

The QR code and the verification phrase

Invoices issued with a Verifactu system must include a QR code and, when the system has opted into the real-time submission mode, the phrase "Invoice verifiable at the AEAT electronic office". Any recipient can scan the QR and check that the invoice exists and matches what was declared.

Verifactu (voluntary) versus "non-Verifactu"

The regulation provides for two modes:

  1. Verifactu mode: the system sends each invoicing record to the AEAT at the moment it is generated. This is the recommended mode because it simplifies inspection and reduces the risk of discrepancies.
  2. Non-Verifactu mode: the system does not send the records in real time, but must keep them with the same integrity guarantees and be ready to submit them if the AEAT requests them.

In both cases the software has to meet the same technical requirements; what changes is whether submission is immediate or on request.

Who is left out: the SII

Companies already required to use the Immediate Supply of Information (SII) —basically large companies and groups that already submit their VAT records to the AEAT in real time— are outside Verifactu, because they already meet an equivalent level of control by another route. If your company is not on the SII, this exception does not apply to you.

What you have to do if you are a freelancer or a small business

  1. Confirm with your invoicing software supplier (or with whoever develops it for you) that their product is adapted to the regulation and in which mode it operates.
  2. If you invoice with spreadsheets or homemade tools, it is time to migrate to a compliant system: there is no way to adapt a spreadsheet to these requirements.
  3. Check that the invoices you issue already include the QR code and, where applicable, the verification phrase.
  4. Keep evidence that your supplier has confirmed the system's compliance to you: if something goes wrong, the responsibility is not only theirs.

What happens if you do not comply

Law 11/2021 classes as a serious infringement both producing or marketing non-compliant invoicing software (so-called "dual-use software", which allows keeping parallel accounts) and using it knowing that it does not comply. The penalty provided is a fixed fine of up to €50,000 per financial year in which the non-compliant software was used. It is not a symbolic figure.

How I see it from a software development point of view

Verifactu is, at heart, an architecture problem: immutable records, chained by hash, with full event traceability. It is exactly the kind of requirement that has to be solved well the first time, because a design flaw here is not just any bug, it is a breach with an associated penalty. If your website or your management application issues invoices and you are not sure whether your current supplier complies, it is one of the first points I review in the free assessment.

And because the timetable has already moved once and may move again, it is not something to review once and forget: it is exactly the kind of ongoing compliance that a monthly maintenance plan keeps an eye on month by month, not just at launch.


Who takes care of this on your website month to month?

Monthly maintenance includes keeping an eye on exactly this kind of legal and technical compliance, not just making sure the site stays up.