Verifactu: FAQs to know before mandatory compliance for software developers.

Currently, various tax regulations coexist in Spain, with similar objectives but different scopes of application:

Verifactu: This is a system promoted by the Spanish Tax Agency (AEAT) at the national level. It requires all invoicing-capable software operating in Spain to meet specific technical requirements starting on July 29, 2025. Beginning in 2026, invoicing records from companies and self-employed individuals must be automatically sent to the AEAT. It applies to businesses with tax residence in Spain and an annual turnover of less than 6 million euros.

SII (Immediate Supply of Information): This tax regulation applies to companies with a turnover above 6 million euros, VAT groups, or those registered in REDEME. It is a parallel system already in force, requiring near real-time submission of VAT ledger entries. However, compliance with SII does not imply that you must also comply with Verifactu. In other words, the two systems are mutually exclusive. If you already comply with SII, you do not need to implement Verifactu as well. Conversely, if a taxpayer adopts Verifactu in a given fiscal year and later exceeds the 6 million euro threshold, they are not required to switch to SII immediately. Transition to SII, if applicable, will only be mandatory starting the following fiscal year.

TicketBAI: This is the mandatory tax regulation in the Basque Country (Álava, Gipuzkoa, and Bizkaia), which establishes its own electronic invoicing system. Companies that already comply with TicketBAI are also not required to adopt Verifactu.

FACE: This is the platform used to send electronic invoices to public administrations. It will remain active and will not be discontinued with the introduction of Verifactu. Both systems can coexist without issue.

In summary:

• If you already comply with SII or TicketBAI, you do not need to comply with Verifactu.
• Verifactu will apply to the remaining taxpayers under national jurisdiction, who must use invoicing software adapted to Verifactu’s technical requirements.
• FACE will remain the valid channel for invoices addressed to public administrations.

Verifactu will be mandatory for any company or self-employed individual who issues invoices within the Spanish VAT territory. However, the regulation includes some exemptions:

• Companies under SII: They do not have to duplicate their data submission through Verifactu.
• Companies under the Special Scheme of the Surcharge or the REAGYP (Agriculture, Livestock, and Fisheries): They are exempt from issuing invoices, except in specific cases. In those cases where invoices must be issued, they must meet Verifactu requirements.
• Taxpayers already under TicketBAI: If they comply with that system, they do not need to adopt Verifactu.

In addition, mandatory invoice submission to the AEAT will begin in phases:

• From January 1, 2027, for legal entities (companies)

  From July 1, 2027, for natural persons (self-employed individuals)

Until these dates, it is possible to submit information voluntarily and without any penalties from the AEAT in the event of errors. This is strongly recommended in order to validate processes before the obligation comes into effect. This has been officially confirmed by the AEAT in their latest FAQ release.

The Spanish Tax Agency has made a dedicated portal available to developers, companies, and freelancers, containing all the technical documentation related to Verifactu. There you’ll find:

• Functional requirements for software
• The structure of the verifiable invoicing record (format, fields, validations)
• How to generate the CSV code and QR code
• The official FAQs for developers, updated periodically

🔗 You can access the official documentation directly here: 👉 AEAT Developer Site 👉 Latest FAQs published by the AEAT regarding Verifactu

Yes. Invoices issued to private individuals (natural persons without a declared Tax ID), such as receipts from a store or gas station, are also subject to Verifactu.

One key point to keep in mind: each ticket, even if the customer is not identified, must generate its own individual invoicing record and comply with all technical requirements—QR code, CSV, hash, etc.

Since Verifactu mode requires an internet connection, the AEAT does foresee exceptional situations where connectivity is limited or unavailable (for a limited time). In these cases:

• The invoice must be generated locally in compliance with Verifactu, including the QR and CSV, and the record must indicate that an incident occurred.
• The transmission to the AEAT can take place later, once the connection is restored.
• The key is that the invoice must be technically compliant from the start, even if it is synchronized later.

Lack of internet connection does not exempt compliance with the technical requirements, but it does allow for some flexibility in transmission. With our Verifactu API, you’re covered: SIGN ES detects the outage and automatically resumes record transmission when the connection is restored, so your customers can continue issuing compliant invoices without interrupting their activity.

If your point of sale does not have a stable internet connection, it may be worth considering the Non-Verifactu transmission mode, though this may involve other technical complexities.

Yes. Machines that issue tickets—such as ticket dispensers, vending machines, or self-service kiosks—must comply with Verifactu as long as they are required to issue simplified invoices.

Even older machines (e.g. push-button machines without connectivity) must be adapted to meet the regulation or replaced with compliant solutions.

When the AEAT rejects a record submitted in Verifactu mode, three scenarios may occur depending on the validations performed:

1. Total rejection of the submission: The entire submission is rejected when there are structural errors (e.g. malformed XML tags) or syntactic errors in the header. In such cases, none of the records are processed and a SoapFault response is returned indicating the technical error.

2. Partial acceptance: If some records are valid and others are not, a partial acceptance occurs. The valid records are accepted, and the invalid ones are rejected, with a detailed explanation for each. Rejection errors may include:

   • Syntactic validations (format, length, values from dropdowns, etc.)
   • Business rule validations (e.g. field relationships that do not meet defined rules)
   • In this case, the taxpayer must correct only the invalid records and resubmit them, provided that they don’t require a corrective or voided invoice.

3. Accepted with errors (admissible errors): Some errors are considered "admissible" by the AEAT. These records are accepted but flagged as “Accepted with errors,” including a description of the issue. Even so, the errors should be corrected if the issuer wants them to be properly reflected, by submitting a new replacement record (correction).

In all cases, the SIF (Invoicing Software System) must retain the original records exactly as they were generated, even if they contain errors. It is not permitted to modify already generated records. All corrections must be submitted as new records—whether a correction, annulment, or rectification. Rejected records will not be considered officially submitted to the AEAT until they are accepted.

Yes. Even if your activity is sporadic—for example, if a private individual rents out a warehouse and issues just one invoice per month—that invoice must comply with Verifactu.

The important factor is not how often you issue invoices, but whether you are using invoicing software to do so. If you generate invoices manually (e.g. using Word or Excel without invoicing functionality), you will not be meeting the technical requirements and could face fines from the AEAT.

The Responsible Declaration is a document through which the manufacturer or developer of invoicing software certifies that their product complies with all the technical and functional requirements established by the Verifactu regulation.

This document:

• Does not need to be submitted to the Spanish Tax Agency (AEAT) as a mandatory requirement, but it must be written and visibly included within the invoicing software, accessible to both the customer and the reseller at the time the product is acquired.
• Is a legally binding statement, meaning the developer assumes responsibility in the event of false claims or non-compliance.

In short: the Responsible Declaration certifies that the software complies with Verifactu without needing prior official certification. It can be considered a form of self-certification.

Regarding format, the AEAT has recently published a model for the Responsible Declaration, specifying the required content.

At fiskaly, we already have a ready-to-use template for our customers to complete and integrate into their software. If you're interested, feel free to contact us and we’ll send it to you.

Yes. The AEAT has clarified that the Responsible Declaration must clearly specify the version of the software it refers to.

This ensures that each version delivered to customers is explicitly linked to a specific Responsible Declaration and allows for traceability in case of future audits or inspections. Therefore, if your software evolves or is updated, each new version must be accompanied by a new Responsible Declaration.

Having a Responsible Declaration does not automatically exempt the developer from penalties. It is a mandatory requirement, but if it is found that the software does not truly comply with Verifactu, there may be legal consequences for the developer.

That said, having a properly issued declaration and maintaining traceability of compliance provides significant legal support in the event of an audit or inspection.

For the digital certificate needed to send records to the AEAT:

• A qualified electronic certificate is required that either identifies the taxpayer directly or is linked via an authorization granted by the taxpayer.
• A valid certificate for either a natural or legal person, issued by a recognized certification authority, is sufficient for signing the records submitted to the AEAT.

In our Verifactu API, this process can be automated to reduce the complexity of certificate management for the client. Since we are officially recognized as a Social Collaborator of the AEAT, we can sign transactions using only our own digital certificate—signing the files and submitting the invoicing records on behalf of the taxpayer.

All we need is for the taxpayer to grant us authorization by signing the Social Collaboration Annex.

In principle, no. Delivery notes are not subject to Verifactu, since they are not invoices nor documents with fiscal validity—they serve merely as proof of delivery. The same goes for proforma invoices, quotes, or pre-invoices: they do not qualify as official billing records.

However, the AEAT stipulates that any document generated by a SIF, even if it is not a “real” invoice, must be stored in an unalterable way. This includes delivery notes, proformas, quotes, or drafts issued by the system. The goal is to ensure that every transaction is logged permanently and can be traced, even if it ultimately doesn’t result in an issued invoice.

If your company is covered by the SII (Immediate Supply of Information system), you are not required to comply with Verifactu for your sales invoices. Therefore, it is not mandatory to include the QR code on those invoices.

In this case, you can continue generating invoices as you currently do under the SII framework, and there is no need to include either the QR code or the CSV, as your communication channel with the AEAT is different.

Yes. July 29, 2025, is the deadline for all Billing Information Systems (SIFs) that are commercialized, updated, or delivered to be already compliant with Verifactu.

This applies to:

• All invoicing software sold to new clients
• Software updates delivered to existing clients
• Any new software version deployed in production in Spain

In other words, it is not enough to have the software ready by January 2026 (when the obligation begins for businesses). Starting July 29, 2025, it will not be allowed to distribute or deploy any software that does not meet Verifactu’s technical standards—even if the mandatory submission to the AEAT begins later (January or July 2026, depending on the taxpayer type).

No. From July 29, 2025, any new customer receiving your software must get it fully adapted to Verifactu, with all required features active.

This means:

• The software must include generation of the structured XML record, QR code, CSV, and chained hash
• The Verifactu functionality cannot be disabled or delayed as if it were optional

Even if the customer is not required to submit data to the AEAT until 2026, the system must be ready to do so from the start.

Yes. If a company internally develops its own Billing Information System, it is subject to the same technical obligations as a commercial software developer. This means:

• The software must comply with all Verifactu requirements
• A Responsible Declaration must be issued internally, confirming the system meets the regulation
• The company must ensure traceability, data integrity, and valid record generation

However, take note: the deadlines change in this case. Companies using in-house software (not commercialized) are not required to comply before July 29, 2025. Their deadlines are:

• January 1, 2026, for legal entities
• July 1, 2026, for individuals (self-employed)

In short: the software must comply just the same, but the compliance deadline depends on whether it is sold commercially or only used internally.