SIF and VERI*FACTU in Spain

The uncomfortable part of VERI*FACTU is not the QR code. It is the habit change behind it.

For many freelancers and small businesses in Spain, invoicing has been treated as a monthly admin task: issue the invoice, send it, save the PDF, pass everything to the gestoría. The SIF rules move attention to the system that creates the invoice record in the first place. The question is no longer only whether the invoice looks right. It is whether the software that supports your invoicing can generate, preserve, trace and, where applicable, send the required records correctly.

This article keeps to the official sources: the AEAT pages on SIF and VERI*FACTU, the AEAT general guidance, the AEAT explanation of compliance modalities, and Royal Decree 1007/2023 as published in the BOE.

What SIF and VERI*FACTU change in practice

SIF stands for sistemas informaticos de facturacion: the computer systems or software used to support invoicing processes. Royal Decree 1007/2023 regulates the requirements those systems must meet when they are used by businesses and professionals in the scope of the regulation.

The aim is specific. The system must guarantee the integrity, conservation, accessibility, legibility, traceability and inalterability of billing records. In plain English: the invoice record should not be something that can be silently changed, deleted or replaced later.

AEAT also makes one useful clarification: the regulation does not materially change the underlying obligation to issue invoices. The existing invoicing rules still apply. The SIF rules focus on how the invoicing system works and on the records generated around each invoice.

For the person issuing invoices day to day, the visible changes are likely to include:

invoices and simplified invoices must include a QR code once the rules apply to the issuer;
in VERI*FACTU mode, invoices may also include the wording that identifies them as verifiable;
the software must generate billing records connected to each invoice;
corrections should be handled through later records, not by silently altering the original record;
the business needs to know which compliance mode its invoicing system uses.

That last point matters. “My software says it is ready” is not enough. You need to understand what “ready” means.

Who should pay attention

The BOE text applies the regulation to taxpayers using invoicing systems, even if they only use those systems for part of their activity. The groups listed include Corporate Income Tax taxpayers, Personal Income Tax taxpayers carrying out economic activities, and Non-Resident Income Tax taxpayers obtaining income through a permanent establishment.

For TaxFactory’s usual audience, that means many companies and many self-employed professionals should review their invoicing setup. There are exclusions and special cases in the regulation, so the right first step is not panic. It is classification.

Ask three practical questions:

Do you issue invoices or simplified invoices for your activity?
Do you use software, an online platform, an ERP, a POS system, or any other digital tool to support that invoicing?
Are you relying on that tool to generate, store, correct or export invoice information?

If the answer is yes, your preparation should start now, even if your provider says the technical adaptation is in progress.

The two compliance modes

AEAT describes two valid compliance modes: VERIFACTU and NO VERIFACTU.

Under the VERI*FACTU mode, the billing records are sent to the AEAT electronic headquarters immediately after they are produced. The purpose is to avoid later alteration and ensure conservation. In this mode, the customer can use the QR code to consult the invoice through the AEAT electronic headquarters and check its fiscal quality.

Under the NO VERI*FACTU mode, the records are not sent to AEAT when they are produced. That does not mean “less compliance”. AEAT explains that this mode has additional security requirements, including an electronic signature generated by the issuing system and the keeping and conservation of a system event log.

So the choice is not between “regulated” and “not regulated”. Both modes are regulated. The operational difference is where the burden sits:

VERI*FACTU puts more emphasis on immediate electronic remittance to AEAT.
NO VERI*FACTU puts more emphasis on local security, signature and event-log requirements.

Small operators should also note AEAT’s free invoicing form. AEAT presents it as a route for small operators who do not need their own invoicing system. The AEAT guidance describes limitations: it only admits complete invoices because it requires full customer identification, and it does not admit invoices with multiple recipients.

Dates to plan around

The consolidated BOE text states that Corporate Income Tax taxpayers referred to in article 3.1.a must have their invoicing systems adapted before 1 January 2027. The rest of the taxpayers mentioned in article 3.1 must have the systems operational before 1 July 2027.

Those dates should shape the preparation calendar. For a small company, the practical deadline is not the legal date itself. It is the last safe date to issue invoices without improvising, retraining staff or discovering that exports, numbering, corrections or customer data are not being handled correctly.

A conservative plan would separate the work into four checks:

Confirm whether your current invoicing tool is a SIF and whether it will support VERIFACTU, NO VERIFACTU, or both.
Ask the provider how the system will generate registration and cancellation records.
Review how corrections and cancellations are handled, especially if your team currently edits invoices after issue.
Decide how the new QR and, where applicable, VERI*FACTU wording will appear on invoice templates.

The key is to test before the obligation is live for you. A compliant system that nobody in the business knows how to use is still an operational risk.

What to ask your invoicing software provider

The safest questions are specific. Avoid asking only whether the software “will comply”. Ask how.

Send your provider a short checklist:

Which mode will the software support: VERIFACTU, NO VERIFACTU, or both?
Will it generate billing records automatically at the right moment in the invoicing process?
How will it calculate and preserve the hash or required traceability elements?
If using NO VERI*FACTU, how will the system handle the electronic signature and event log?
How will invoice cancellations be recorded?
Will invoice templates include the QR code required by AEAT guidance?
Can the system export and transmit billing records if required?
What changes, if any, will users notice when issuing invoices, correcting invoices or duplicating drafts?

This is also the moment to clean up small habits that cause bigger problems later: shared logins, draft invoices reused as templates, manual numbering outside the invoicing tool, PDFs created separately from the accounting record, or late corrections made by overwriting old data.

The regulation is built around traceability. Your process should be too.

A preparation checklist for freelancers and small businesses

Start with your invoice flow, not with the regulation text. Write down how an invoice is created today, from customer data to final PDF. Include who touches it, which tool creates it, where it is stored, and how it is corrected.

Then review these points:

Confirm your taxpayer profile with your advisor.
Identify every tool that can create invoices, simplified invoices or invoice-like records.
Remove duplicate invoicing paths where possible.
Check whether your provider has published its SIF or VERI*FACTU adaptation plan.
Decide whether your future process will use VERIFACTU mode or NO VERIFACTU mode.
Review invoice numbering, series and cancellation habits.
Make sure customer identification data is complete where your invoicing process requires it.
Keep evidence of provider communications and configuration decisions.
Train anyone who issues invoices before the first live deadline.
Run a sample invoice flow once your provider enables the adapted system.

For very low-volume businesses, the AEAT free invoicing form may be worth reviewing. But it should not be assumed to fit every case. AEAT’s own guidance says it is limited to complete invoices and does not allow multiple recipients.

What not to assume

Do not assume VERI*FACTU is the same thing as electronic invoicing. AEAT states that billing records are not invoices, and they are not electronic invoices. A business may issue a paper invoice or a structured electronic invoice, while still producing the required billing record.

Do not assume NO VERI*FACTU means “offline and simple”. AEAT describes additional security requirements for that mode.

Do not assume the QR code alone makes the system compliant. The QR code is the visible part. The record generation, preservation, traceability and correction logic are the part your business needs to verify with its provider.

Do not wait until the final month to test. The legal change may be technical, but the friction will be operational: invoice templates, user permissions, corrections, exports, customer data and staff habits.