Verifacto, non‑Verifacto, SII and the new reality for retailers and POS vendors
Spain’s new fiscalization program is often discussed as a future problem. The official go‑live dates for taxpayers are now set in 2027: January 1, 2027 for corporate income taxpayers and July 1, 2027 for individual professionals. That sounds far away. But the risk for retailers is not the calendar. The risk is the shape of the system: Spain is moving to software-based control where the point of sale becomes a compliance device, and where “we’ll handle it later” is exactly how projects fail.
In practice, the compliance clock has already started for the ecosystem around retailers. Spain’s timeline includes a deadline from July 2025 for invoicing software providers and manufacturers to meet the requirements if they offer fiscalization-capable solutions. In other words, the market is expected to be ready before most retailers feel the pressure. That gap, vendors forced to comply and retailers tempted to delay, creates a dangerous moment. It can produce rushed rollouts, “quick fixes” at the receipt layer, and fragmented implementations across stores and countries.
The smarter way to read Spain is this: Verifacto is not only a national rule set. It is a preview of the next phase of European fiscal enforcement, where software integrity and traceability are treated as operational fundamentals, not as after‑the‑fact reporting. For global retailers, Spain is becoming another country where the POS must prove what happened, when it happened, and that nobody changed it afterwards.
To understand why this is different, you first need to understand that there is no single “Spain” in fiscalization. Mainland Spain is moving to Verifacto. The Basque Country already operates its own model, TicketBAI, and Navarra is treated as a special territory with its own system under development. The deciding factor is not where the store is physically located but where the taxpayer’s tax domicile is registered, because that determines which regime applies.
Then there is SII, Spain’s Immediate Supply of Information regime, which continues to sit next to Verifacto. It is not a “nice to have.” Companies with annual turnover above a threshold (and other conditions) are required to use SII, and the scope is described as exclusive: taxpayers in SII are not obliged to fulfil Verifacto, and some businesses can even register voluntarily in SII to avoid Verifacto requirements. For retailers, this matters because the first strategic question is not “How do we implement Verifacto?” It is “Which regime applies to us, and where?”
Once you are in the Verifacto world, the system expects every sale to be recorded in a standardized way. The software must generate an invoice or receipt record for each issued invoice or receipt, and it must support the capacity to send these records to the tax administration. Those records follow predefined data and format rules, including XML structures described in technical documentation. In plain terms: Spain is setting a shared language for fiscal events, and your POS must speak it.
That brings us to the most misunderstood part of the story: Spain is designed around two operating modes. The first is Verifacto mode, where records can be sent in real time and continuously to the tax authority. The second is non‑Verifacto mode, where the system still creates the records, but they are not transmitted in real time. That second mode sounds easier. It is not. It shifts the burden from connectivity to evidence, and it turns audits into a technical exercise where your system must survive deep inspection.
The compliance logic is straightforward. Verifacto mode is meant to prevent manipulation by making the record verifiable at the authority level. Non‑Verifacto mode must compensate by enforcing stronger controls inside the retailer’s own system. This is why non‑Verifacto introduces additional security expectations, including electronic signing and the ability to demonstrate that records were not altered or deleted. Whichever mode you choose, the philosophy is the same: integrity, traceability and immutability are not optional features. They are the point.
From an engineering perspective, the core anti‑fraud objectives are clearly stated: prevent invoice manipulation, eliminate dual‑use software, and ensure transparency and traceability. Technically, that translates into systems where data cannot be altered, records cannot be deleted, sales records are chained in a predefined way, and the whole system avoids functionality that would allow users, on site or remotely, to hide original data. Spain is effectively saying: if your software can rewrite reality, it is no longer allowed.
Retailers will feel these requirements in the “last meter” of commerce: the receipt.
Spain expects security and control features to be present on receipts and invoices. A QR code must be included, enabling customers to scan and check the validity of receipts. A fingerprint or hash must also be presented on receipts for both Verifacto and non‑Verifacto modes, and in non‑Verifacto mode the receipt record is expected to be electronically signed. This is a key design decision: Spain turns a humble receipt into a verifiable artifact.
For retailers, this changes day‑to‑day operations more than many realize. It affects how refunds are handled, how voids are performed, and how corrective receipts are issued, because the regulations describe different fiscal document types and the circumstances under which they can be used. It also affects how e‑receipts are delivered, because the format can be paper or digital, and the verification elements need to exist either way. If you are running unified commerce across channels, the “receipt” becomes a shared compliance object across store, online and customer service.
Now comes the part that sounds simple but is operationally heavy: certification. Spain is described as a self‑declaration or verification procedure. The tax authority will not certify or test the sales software. Instead, a special “responsible declaration” must be completed and kept as proof that requirements are met. The content is predefined in detail and must be visible in the computer system itself and at the place where the system is used. It includes data such as the system name, an identified code, version information, whether the system is Verifacto or non‑Verifacto, and the tax certification number of the producer.
If this feels like a light-touch approach, don’t be fooled. Self‑declaration is not leniency. It is a shift in liability. Spain is telling taxpayers and software providers: you declare compliance now; we verify later, and we do it with the power of inspection.
Tax authorities can perform on‑site inspections, appearing at any location where the system is used. They can demand full system access, including usernames, passwords and security keys. They can download, copy or print records to check compliance. They can also demand compliance data directly from software producers. This is the enforcement model: audits move from “show us your accounting” to “open your system.”
Penalties also follow the same logic. They can be imposed on businesses for using software that does not meet requirements, for using dual‑use software, or for any detected alteration of receipts. But software producers are also in scope. If producers place non‑compliant software on the market or enable alteration or manipulation of billing or sales data, they too can face penalties. The message is clear: compliance is no longer a retailer-only problem. It is a supply‑chain problem across POS vendors, integrators, and even internal development teams.
What does all of this mean for retail strategy?
First, Spain will reward architecture, not heroics. The teams that treat Verifacto as a “receipt change” will struggle. The teams that treat it as a transaction integrity layer, shared across POS, e‑commerce and back office, will move faster and with less risk.
Second, the Verifacto vs non‑Verifacto decision should be framed as a risk trade‑off, not as a technical preference. Real‑time transmission creates dependency on connectivity and on consistent data pipelines. Non‑Verifacto reduces transmission requirements but increases audit exposure and demands stronger evidence of integrity inside your environment. Either way, you must plan for operational monitoring, because compliance failures in this model are not quiet. They are visible in records, in chains, and eventually in inspections.
Third, global retailers should use Spain to strengthen their “compliance engineering” discipline. Verifacto forces teams to implement deterministic controls: consistent record generation, standardized XML outputs, secure storage, hash chaining, signing (where required), and controlled workflows for corrections and returns. These are not one‑off tasks. They are capabilities that will be reused in other countries as fiscalization expands.
Finally, POS vendors and retailers with in‑house POS development should recognize what Spain signals about the market. Fiscal capability is becoming a product feature, not a country add‑on. Software will be judged by its ability to prove integrity under inspection, and by the seriousness of the producer’s compliance posture. In that world, “we can patch it later” is not a plan. It is a liability.
Spain’s deadline is 2027. But Spain’s fiscal future is already here. The retailers who treat Verifacto as a design problem, integrity by default, evidence by default, audit readiness by default, will turn a compliance mandate into a competitive advantage. The ones who wait will discover, too late, that the hardest part is not sending data. It is defending truth inside your systems.
Source:
Fiscal Solutions webinar transcript “Spain’s Fiscalization: Where Are We Now?” (Feb 19, 2026).