Veri*Factu Compliant Software: What Changes for Builds

Veri*Factu is not a new invoice template or a checkbox in an accounting menu. It is a set of technical requirements, baked into Spain's antifraud law (Ley 11/2021), that dictate how any computerized invoicing system has to record, chain, and (depending on the mode chosen) report every invoice it issues. If you're scoping a custom POS, CRM, or ERP build for a business operating in Spain, this is now an architectural constraint, not a feature to bolt on after launch.

What Veri*Factu actually requires at the software level

At its core, Veri*Factu requires that every invoice a system generates is cryptographically linked to the one before it, forming an unbroken chain. Each record carries a QR code that lets anyone, including a tax inspector, verify the invoice against the chain. The system has to retain these records for a minimum of four years, and it has to be built so that no one, not the business owner, not an employee, not a developer with database access, can quietly edit or delete a past invoice without breaking the visible chain.

That last point is the one people underestimate. A chain that's provably unbroken from the first invoice is a very different engineering problem than "store invoices in a database and don't delete rows." It means the invoicing logic has to generate the hash link at the moment of creation, store it immutably, and expose it in a verifiable format from day one. Retrofitting this into a system that's already been issuing invoices for two years is awkward at best: the chain either starts mid-stream (which an auditor will notice) or the historical data has to be reconstructed, which defeats the point of tamper-proofing in the first place.

Two modes, same underlying mechanics

The regulation allows two operating modes. In VeriFactu mode, the system submits invoice records to the AEAT in near real time as they're issued. In non-VeriFactu mode, the system keeps the same tamper-proof, chained records locally and makes them available to the tax authority on request instead of transmitting automatically. Both modes need the same chaining, QR generation, and retention logic underneath; the difference is purely about where the data ends up and when. A system designed properly from the start can usually support either mode with a configuration change, not a rebuild.

No government certification, but a real declaration of responsibility

One detail that trips people up: the Spanish Tax Agency does not formally certify or approve invoicing software. There's no stamp of approval to look for on a box or a pricing page. What the law actually requires is a declaración responsable, a signed statement (from the software provider, or from the business itself if it built the system) confirming the system meets the technical requirements. That shifts the liability conversation. If a system doesn't behave compliantly in practice, the declaration doesn't protect anyone, and penalties under Article 201 bis of Ley 11/2021 can apply to the business using the software and, depending on the circumstances, the provider that supplied it.

Why off-the-shelf and imported platforms quietly fall short

Plenty of POS and invoicing platforms sold internationally were built for markets with no equivalent requirement, and Veri*Factu compliance gets added as a regional module, sometimes well after the platform's core architecture was already locked in. The result is often a compliance layer sitting on top of an invoicing engine that wasn't designed with immutable chaining in mind, which shows up as gaps around edited orders, voided tickets, or split bills, exactly the scenarios a restaurant or retail business deals with every day. For a restaurant specifically, where a single table's bill might get modified, merged, or partially refunded multiple times before it's closed, this is where a bolted-on compliance module tends to break down. We've written separately about off-the-shelf vs. custom restaurant software in general; Veri*Factu is now a concrete, specific reason that comparison matters.

What this means if you're scoping a system now

If you're building or replacing a POS, invoicing, or ERP system for a business operating in Spain, VeriFactu needs to be a requirement in the first conversation about architecture, not a line item added during testing. That means deciding early whether the business needs VeriFactu mode (real-time AEAT submission) or non-Veri*Factu mode (local tamper-proof records), designing the invoice chain and QR generation into the data model from the first invoice the system will ever issue, and planning for the four-year retention requirement in how records are stored and backed up. This is exactly the kind of decision that belongs in a custom software scoping phase, where the workflow, including how invoices actually get created, edited, and closed in daily use, gets mapped before a single screen gets designed. For restaurants specifically, it's also part of how we think about Restaurant Management System builds, since table billing is where invoice chaining gets tested hardest.

Why a nearby studio tends to catch this earlier

This is less about proximity for its own sake and more about what a studio actually tracks day to day. A team building and maintaining software for Spanish businesses runs into Veri*Factu as a routine part of scoping any invoicing-adjacent system, because clients ask about it, deadlines get discussed in local accounting and legal circles, and the requirement shows up in real projects before it shows up in a headline. A remote generalist vendor, especially one based outside Spain and working from a general feature list, typically has no reason to know this regulation exists until a client calls after failing an audit. We've made this point before in the context of what changes when a software studio is actually local to the region, and Veri*Factu is a concrete example of what that proximity is actually for: not faster meetings, but fewer surprises at audit time.

A note on timing

The deadlines around Veri*Factu have moved more than once since the regulation was first announced, with software providers facing an earlier obligation than businesses themselves, and business-side deadlines reported at different points as 2026 and then 2027 depending on entity type. Rather than anchor a build plan to a specific date that may shift again, the more reliable approach is to architect the system as if the requirement is already live: chained records, QR codes, and proper retention from the first invoice. If the deadline moves again, a correctly built system doesn't need to change. If it doesn't move, there's no scramble. For businesses that also deal with cross-border billing into Gibraltar, this sits alongside the VAT and currency questions covered in building software for businesses operating across Spain and Gibraltar, since both are regional realities that shape how an invoicing system has to be built, not just what it has to display.