Verifactu for your online store: what the delay to 2027 changes
If you sell online from Spain, somebody has probably tried to sell you a plugin "approved by the Spanish tax agency" so you could meet the Verifactu deadline before July 2026. That deadline no longer exists, and neither does that seal: the Agencia Tributaria does not approve, certify or publish a list of authorised invoicing software.
The two facts are worth separating, because the first buys you time and the second tells you what to ask before you sign anything.
The delay is a new calendar, not an amnesty
Royal Decree-Law 15/2025 of 2 December rewrote the fourth final provision of Royal Decree 1007/2023 and pushed the invoicing-software regulation (RRSIF, which everyone calls "Verifactu") back by a full year. The wording in the official gazette is unambiguous: taxpayers under article 3.1.a) must have their systems adapted before 1 January 2027, everyone else before 1 July 2027.
| Who | Deadline | Previously |
|---|---|---|
| Corporate income tax payers (art. 3.1.a) | 1 January 2027 | 1 January 2026 |
| All other obliged parties under art. 3.1 (including self-employed on IRPF) | 1 July 2027 | 1 July 2026 |
The AEAT information note adds the detail most people miss: the time remaining before those dates is a testing period. You may keep issuing invoices with an old, non-adapted system until your obligation starts, and you may test sending records in VERI*FACTU mode without being locked into it. The rule that keeps you in the system until the end of the calendar year only starts to apply once you are actually obliged.
In practice: you have between five and seventeen months, depending on how you are taxed. Enough time to choose well, and far too little to leave it alone.
Before you buy anything, check whether the rules apply to you
The AEAT summarises the scope with what it calls the "rule of the four NOs". The regulation reaches you if you issue invoices while established in Spanish territory and all four conditions hold at once:
- You do not invoice exclusively by hand, without any software.
- You are not enrolled, compulsorily or voluntarily, in the Immediate Supply of Information regime (SII).
- Your tax domicile is not in the Basque historical territories or in Navarre.
- You do not hold a valid non-application ruling.
The second point removes a fair number of mid-sized online stores in one stroke: anyone in the SII — through turnover above €6,010,121.04, membership of a VAT group, registration in REDEME, or voluntary enrolment — falls outside the RRSIF. The third affects businesses taxed in the foral territories, where TicketBAI applies instead of Verifactu. And it is worth knowing that the Canary Islands, Ceuta and Melilla are inside the scope, with references to VAT read as references to IGIC or IPSI.
If you are unsure which box you are in, that is a fifteen-minute conversation with your tax adviser, not a decision for your developer.
Your online store is not automatically an invoicing system
This is where the most expensive misreading happens. The regulation does not govern online stores; it governs invoicing software systems (SIF), and the AEAT defines an SIF by what it does, not by where it runs. It applies "only to those used to issue invoices (including simplified invoices)", and expressly not to systems that issue other kinds of documents evidencing a delivery of goods or a supply of services.
So the order confirmation, the delivery note, the "thanks for your purchase" email and the document many platforms call a receipt do not turn your site into an SIF. What turns it into one is your site generating what the rules consider an invoice, full or simplified.
The first technical question is therefore not "does my store comply with Verifactu?" but which part of my architecture actually issues the invoice? There are usually four answers, and they lead to different places:
| Where the invoice is generated | Who has to adapt |
|---|---|
| External invoicing software (SaaS) that receives orders from the store | The SaaS vendor — your job is choosing well |
| An invoicing plugin or module installed in the store | Whoever produces that plugin |
| Custom code written for your project | You, as the producer (see below) |
| Your accountant, from an order export | The accountant, with their own SIF |
Without that answer, any adaptation quote you are given is a made-up number.
"Approved by the tax agency" means nothing
Article 13 of the RRSIF sets up self-certification, not administrative approval. It says so plainly: "it shall fall to the person or entity producing the software system to certify, by means of a declaración responsable, that the system complies" with the General Tax Act and with the regulation.
It then adds three obligations that work well as a vendor checklist:
- The declaration must appear in writing and visibly inside the software itself, in each of its versions, and be available to the customer at the point of purchase.
- The producer or reseller must keep and preserve the declarations for every version produced.
- Both the customer and the tax administration can demand to see it.
Two questions follow, and both deserve a written answer before you sign: where do I see the declaración responsable inside the product? and do you issue a new one with every release? A serious vendor answers in an email. One who shows you an "AEAT certified" badge is describing something that does not exist.
If your site invoices with custom code, you are the producer
This is the point almost no article about Verifactu and e-commerce mentions, and the one that costs the most.
Article 3.2 of the RRSIF also applies to "the producers and marketers of the software systems" in matters relating to their production activity. Article 13 assigns the declaración responsable to the producing party. If the module that issues your invoices was written by your team, or written by an agency for your project and lives only in your store, there is no external manufacturer behind it to sign on your behalf.
The consequences sit in article 201 bis of the General Tax Act, and the AEAT restates them in its FAQ:
- €150,000 for each financial year in which sales occurred, per distinct type of system, for manufacturing, producing or marketing non-compliant systems.
- €1,000 per system marketed without the required certification.
- €50,000 per financial year for merely holding non-certified systems when certification is required.
On that last one the AEAT has offered a useful qualification: keeping the old program purely as a historical archive may not breach the rule if you can show it can no longer issue invoices, normally by uninstalling it. The recommended route, it says, is to export the records and not keep the system at all.
None of this makes custom development a bad idea. The AEAT itself lists it as one of the valid ways out, alongside updating your current program, switching manufacturer, or using the agency's free invoicing application. It means custom development moves a formal responsibility onto your company that a SaaS vendor would otherwise carry, and that this responsibility belongs in the contract with whoever builds it: who signs the declaration, what happens at each release, who stores it.
Verifactu and mandatory B2B e-invoicing are two different laws
They get confused constantly, because they arrive together and both concern invoices. They are not the same thing.
Verifactu governs how your software must behave when it issues an invoice: a chained hash, an invoicing record, a QR code, and transmission to the AEAT if you choose that mode. Mandatory business-to-business e-invoicing governs the format and the channel by which that invoice travels to your customer.
The second one left limbo on 31 March 2026 with the publication of Royal Decree 238/2026, which implements Law 18/2022 (the "Crea y Crece" act). Its effective application is deferred: twelve months for businesses with turnover above €8 million, and twenty-four months for everyone else, counted from the entry into force of a ministerial order that has not yet been published.
This deserves saying bluntly, because specific 2027 and 2028 dates are circulating as though they were settled: until that ministerial order is published, there is no fixed date for mandatory B2B e-invoicing. What is settled is the mechanism, and that the AEAT will build a free public solution available at least two months before the first effective application.
What to do over the next few months
- Inventory where invoices are issued. Not where orders are created — where something the rules treat as an invoice, including a simplified one, is issued. Include the store, the physical point of sale if you have one, the ERP, and the spreadsheet somebody is still using.
- Apply the rule of the four NOs with your tax adviser and settle your date: 1 January or 1 July 2027.
- Ask every software vendor in writing for the declaración responsable, and ask about their versioning policy.
- Decide the architecture. If invoicing is not a differentiator for your business, an adapted SaaS product receiving orders from the store is almost always cheaper than maintaining your own SIF. If you invoice in a way no standard product covers, take on custom development knowing you are the one signing the declaration.
- Use the testing period. Trying the record submission now, with no obligation and no lock-in, is the cheapest way to find your integration problems.
The concrete step for this week is the first one. Open a document, write one line for every system that emits an invoice from your company, and note who manufactures that software next to it. Any line left without a manufacturer's name tells you what your first conversation is.
This article is informational and does not replace tax advice. The dates and amounts cited were verified against the BOE and the Agencia Tributaria's electronic office on 31 July 2026; reconfirm them before acting, because this calendar has already moved twice.
At Dynasty DX we work on the part that is genuinely ours: the store architecture, the integration between the e-commerce platform and whatever system issues the invoices, and the technical contract that defines who is responsible for what. If you want a second look at how your setup is put together, tell us about it. You can also read our Kit Digital guide for SMEs or see how we approach e-commerce projects.
