Invoicing · Compliance
Will your custom system comply with Verifactu?
The Verifactu date has been postponed twice and now sits a year and a half behind the original. Expecting it to move again is reasonable, and it is the first objection we get. Here is the argument for not waiting anyway: the obligation has not been repealed, only moved, and the work required to meet it is work that is usually worth doing on its own. The people with a problem are those invoicing from a custom build, a store wired to an ERP, or an integration somebody wrote years ago — where no vendor is responsible for adapting it.
Start by separating two things that get mixed together in almost every conversation, because they are two different rules, with two different dates, and complying with one does not comply with the other.
| Obligation | What it governs | From when |
|---|---|---|
| Verifactu (Law 11/2021, anti-fraud) | How the program issuing the invoice behaves: chained record, signature, immutability | 1 January 2027 for corporate income tax payers · 1 July 2027 for the rest (RDL 15/2025) |
| B2B e-invoicing (Law 18/2022, Crea y Crece) | How invoices are exchanged between businesses | Its own timetable: the clock runs from the entry into force of the ministerial order for the public platform (RD 238/2026) |
Worth keeping them apart, because they run on different tracks. Verifactu has its dates in the BOE. B2B e-invoicing has a timetable of its own: the regulation was approved as Real Decreto 238/2026, and the compliance clock runs from the entry into force of the ministerial order developing the public invoicing platform. Its clock is started by that order, not by Verifactu. You will see sites quoting a specific B2B date; check where that order has got to before believing it, and confirm with your accountant when you plan.
Verifactu: who has a problem and who does not
If you invoice from a package you bought or rent — Holded, Sage, A3, your accountant’s module — you need do nothing. The vendor is obliged to adapt it and will, because their entire business depends on it.
The useful question is not “does my package comply?”. It is “does any invoice leave my business through something that is not that package?”. In a connected system the answer is usually yes, and usually in more than one place.
- The online store issuing the receipt or simplified invoice at checkout, without going through the ERP.
- The ERP invoicing orders automatically when the warehouse confirms dispatch.
- The integration generating credit notes and corrections when something is returned.
- The custom build that invoices subscriptions or monthly fees.
- The spreadsheet with macros somebody set up, still alive because it works.
Each of those is an invoicing system as far as the regulation is concerned, whether you call it one or not. And none of them has a vendor behind it obliged to adapt it.
Four questions to tell whether your system complies with Verifactu
You do not need to be technical to put these four to whoever maintains your system. If they cannot answer them, that is the answer.
- Does it generate an invoicing record for every invoice, as well as the invoice? They are two different things. The record is what the rule governs.
- Is that record chained to the previous one? Chaining is what makes deleting an invoice from the middle visible.
- Is it signed, and with what? Without a signature there is no way to show the record has not been touched afterwards.
- What happens exactly when an invoice is cancelled or corrected? This is where older builds fail: many delete the row and renumber, which is precisely what the rule exists to prevent.
The question is not whether your package complies. It is whether any invoice leaves through something that is not your package.
The cheap way out is rarely a rewrite
If your system does not comply, the normal reaction is to ask somebody to adapt it. That is usually the expensive option. Adapting a custom build means constructing the chained record, the signature and the immutability, testing it, and — the part nobody mentions — carrying on maintaining it every time the rules move. That responsibility stays with you permanently.
The alternative usually costs less and ages better: let the invoice be issued by software that already complies — Holded, Sage, A3, whatever your accountant uses — and have your system feed it the data. The vendor is obliged to keep it current because their whole business depends on it. You stop having a regulatory problem and start having an integration problem, which is far cheaper and does not change every time the tax agency publishes something.
The work then is not compliance, it is plumbing: store orders and warehouse dispatches reaching the software on their own, migrating the series and the history without breaking the accounts for the year, and switching off the old points of issue. That last one is always forgotten and it is half the risk: an old system quietly still invoicing leaves you non-compliant anyway.
Why we are the ones writing this
Because we have spent years inside systems that invoice. The Eolas Prints store is wired to the ERP and the warehouse and issues invoices into 235 countries and territories and 112 currencies, with taxes and duties resolved per country. Build that and you learn quickly that “the invoice” is not born in one place: it is born in several, and one of them will surprise you.
We do not sell invoicing packages and we take no commission for recommending one. We review where your invoices are born today, tell you in writing what has to move, and integrate it if you want. The review costs €1,900, the integration starts at €4,500, and the report is yours even if somebody else does the work.
Verifactu has slipped twice: why not wait for the third?
It is the sensible objection and it belongs up front rather than buried. The original date was July 2025. Real Decreto 254/2025 moved it to January 2026 for corporate income tax payers, and Real Decreto-ley 15/2025 moved it again to January 2027. The first moved the date by 6 months; the second has moved it by 18 against the original. A year and a half of cumulative delay across two postponements, and the second was ratified in Congress by 179 votes to 168.
| Norm | Corporate income tax payers | All other obligated taxpayers |
|---|---|---|
| RD 1007/2023, the original | 1 July 2025 | 1 July 2025 |
| RD 254/2025, first postponement | 1 January 2026 | 1 July 2026 |
| RDL 15/2025, second postponement | 1 January 2027 | 1 July 2027 |
Against the original July 2025 date, the first postponement moved it 6 months for corporate income tax payers and the second has moved it 18.
Months of delay against the original date · corporate income tax payers · RD 1007/2023, RD 254/2025 and RDL 15/2025
With that record, betting on a third postponement is reasonable. Betting on the obligation disappearing is less so: neither extension repealed it, both only moved it, and Law 11/2021 underneath is still there. What has moved is when, not whether.
But the real argument is a different one, and it is the one that decides. If the only thing pushing you is the date, waiting is rational. If the work required to comply is work you needed anyway, the date stops mattering so much: moving invoicing onto software that already complies and connecting it to the store, the ERP and the warehouse removes copying data by hand, reconciling series, and answering a customer by looking in three places. You collect that in month one, whatever gets postponed.
If only the date is pushing you, waiting is rational. If you needed the work anyway, the date stops deciding.
And one practical detail no postponement fixes: when the date does land, every supplier capable of this work hits the same peak in the same quarter. That already happened in the weeks before each of the two previous extensions. Arriving with the work done — or at least the review done and the quote agreed — is the difference between choosing a supplier and taking whoever is free.
Frequently asked questions
When does Verifactu become mandatory?
1 January 2027 for corporate income tax payers and 1 July 2027 for all other obligated taxpayers, under Real Decreto-ley 15/2025, published in the BOE on 3 December 2025. Mandatory business-to-business e-invoicing is a separate obligation on its own track: its regulation was approved as RD 238/2026 and the clock runs from the entry into force of the ministerial order developing the public platform. Confirm with your accountant before planning.
Does Verifactu apply to a custom build?
Yes. The regulation governs any computer system that issues invoices, whether you sell it or had it built for yourself. The practical difference is that an off-the-shelf package has a vendor obliged to adapt it, and a custom build has nobody: if nobody adapts it, in January 2027 it carries on issuing invoices in a way that is no longer valid.
My online store invoices and my ERP does too. Which one has to comply?
Both, if both issue invoices or invoicing records. In a connected system it is common for the store to issue the receipt at checkout and the ERP to issue the invoice when the order is picked, with nobody having written down which one governs. Knowing where each invoice is born is the first job, before touching anything.
What is the difference between Verifactu and mandatory e-invoicing?
Verifactu governs how the program issuing the invoice behaves: a chained record, signed and immutable. Mandatory e-invoicing governs how the invoice is exchanged between businesses. They are two separate rules with two separate dates, and complying with one does not comply with the other.
What does it cost to bring a custom system up to Verifactu?
It is usually cheaper not to adapt it: move the issuing to software that already complies and integrate it with what you have. Our review costs €1,900 and ends in a report on where your invoices are born and what has to move; the integration starts at €4,500 and is quoted fixed from there. Adapting the custom build is the other option, and it is worth looking at knowing that the regulatory maintenance stays with you.