VeriFactu in Odoo: what it is, 2027 deadlines and the real state in Community, Enterprise and OCA

What VeriFactu is and why it affects you if you invoice with Odoo

VeriFactu is the framework the AEAT has built on top of the Regulation approved by Real Decreto 1007/2023, of 5 December (the so-called RRSIF, the Regulation on Requirements for Invoicing Software Systems). In short: if you use a program to issue invoices, that program has to guarantee that the invoicing records cannot be tampered with behind the scenes. The rule frames this as unalterability and traceability.

Once generated and recorded, they cannot be altered without the software system detecting it.

And regarding the chaining between records (which in practice Odoo implements with a hash that links each invoice to the previous one):

Chained in such a way that their trail can be verified by following their sequence of creation.

On the invoice, this translates into two visible elements you have surely already seen on other merchants' receipts: a QR code and, if the system submits the records to the Agency, a specific legend.

'Factura verificable en la sede electrónica de la AEAT' o 'VERI*FACTU'.

Two modes: VERI*FACTU and NO VERI*FACTU

The Regulation does not require you to send everything to the Tax Agency in real time. The AEAT recognises two valid ways to comply:

There are two valid modes to comply with the regulation, the VERI*FACTU mode and the mode of keeping the invoicing records in the issuing System (NO VERI*FACTU mode).

• ▸VERI*FACTU mode: each record is automatically submitted to the AEAT at the moment of invoicing. In return, the system is presumed compliant and does not need an electronic signature for each record (hash chaining is enough). It is the simplest to operate and the one implemented today by both the Odoo module and the OCA one.
• ▸NO VERI*FACTU mode: you do not send anything continuously, but in return the system must electronically sign the records and keep an event log with reinforced security requirements, preserving it available to the AEAT. It is technically more demanding.

Who it applies to and who is left out

It applies, broadly, to entrepreneurs and professionals established in Spanish territory who use a software system to issue invoices. But there are important exclusions that avoid overlaps with other already existing regimes.

Excluded: those already in SII

This Regulation shall not apply to taxpayers who keep the record books under the terms established in section 6 of article 62 of the Value Added Tax Regulation.

In other words, if you are already in the Immediate Supply of Information (SII) for VAT, you do not also have to implement VeriFactu.

Excluded: foral territories

their tax domicile in the Historical Territories of the Autonomous Community of the Basque Country or of the Foral Community of Navarre.

The Basque Country has its own system (TicketBAI) and Navarre its foral regime, so they fall outside the state RRSIF.

Dates: the postponement to 2027 (and why you should not get complacent)

This is the most delicate point and where the most outdated information circulates. The original 2025 calendar was extended by Real Decreto-ley 15/2025, of 2 December. The current deadlines according to the AEAT are:

• ▸Corporate Income Tax taxpayers: must have their systems adapted before 1 January 2027.
• ▸The rest of the taxpayers subject to the obligation (self-employed and others): before 1 July 2027.

Watch out for a date that has indeed arrived and is already in force: the one affecting software manufacturers and marketers. Orden HAC/1177/2024, which develops the technical specifications, set a deadline for producers to offer an adapted product.

the maximum period of nine months in which the manufacturers and marketers of invoicing systems...must market products adapted to the regulation.

In other words: even though your obligation as a user is for 2027, your software should already be ready. The honest recommendation is not to wait until December 2026 to touch the invoicing system in production.

State in Odoo: what it ships out of the box

Here is good news that is often told badly. Odoo's VeriFactu support lives in the l10n_es_edi_verifactu module, and that module was incorporated into Odoo's Community repository (the addons/ tree of odoo/odoo), not into the private Enterprise repository. The original proposal targeted the 17.0 branch.

svfu-odoo wants to merge 3 commits into odoo:17.0.

There is also a sibling module for the POS, l10n_es_edi_verifactu_pos, because the rule also reaches point-of-sale orders, not just invoices. Odoo's official documentation describes how it works: when the invoice is confirmed a document is generated and it can be sent to the AEAT, with a QR on the PDF. By default it starts in testing mode.

By default, Veri*Factu is in testing mode.

The fact that the module is in Community means that, in principle, you do not need an Enterprise licence just to be able to issue in VERI*FACTU mode from the Invoicing app. Honest nuance: Odoo Enterprise by definition includes everything in Community, and advanced accounting (full tax reports, reconciliation, etc.) remains Enterprise. What matters here is that the VeriFactu engine itself is not a paid module exclusive to Enterprise.

State in OCA: the community-driven alternative

The community (OCA) maintains its own module, l10n_es_verifactu_oca, within the OCA/l10n-spain repository, with an AGPL-3 licence and developed by well-known houses of the Spanish ecosystem (Aures Tic, ForgeFlow, Tecnativa, Factor Libre, among others). It implements the VERI*FACTU mode: it generates the submission record when validating the invoice and submits them to the AEAT via SOAP, with certificate management.

Two important warnings about its maturity and availability, verified on GitHub itself:

• ▸Development status: Beta. The README explicitly marks it as maturity Beta, which under OCA's criteria means functional but still stabilising. It is worth testing it thoroughly before production.
• ▸Versions: it is published for 14.0, 15.0, 16.0, 17.0 and 18.0. At the time of this check, the module's directory for 19.0 in OCA/l10n-spain returns 404, meaning there is not yet a version for Odoo 19.

Community vs Enterprise vs OCA: how to decide

A practical summary for whoever has to choose a path:

• ▸If you are on Odoo 17 or 18 (or heading to 19) and want official support maintained by Odoo S.A.: the standard l10n_es_edi_verifactu module (+ _pos for POS) is the starting option, and it is in Community.
• ▸If you work with a 100% OCA / AGPL stack and are on 14–18: l10n_es_verifactu_oca is a living alternative, but count on it being Beta and plan real tests with a certificate.
• ▸If your Odoo is 19 and you want the OCA module: it does not exist yet today; either you use Odoo's standard module, or you wait for the OCA port.
• ▸If you are already in SII, TicketBAI or are foral: do not install VeriFactu, it does not apply to you.

In all cases, the real work is not 'installing a module'. It is: registering the correct certificate, starting in the AEAT's testing environment, validating the hash chaining with no gaps, reviewing fiscal positions and tax codes, checking the QR on the branded PDF, and only then going to production.

How we help you at skanndar

At skanndar we work with Odoo in Spain for real, both Community and Enterprise, and with OCA modules. If you need an honest audit of whether your installation will reach the 2027 deadlines without surprises, or support to get VeriFactu working and verified end-to-end (certificate, testing mode, move to production and QR on your invoices), write to us. We will tell you clearly what your Odoo ships out of the box and what needs to be added, without selling you licences you do not need.