Verifactu in Odoo: a complete guide to getting compliant

To make Odoo comply with Verifactu you need a module that creates an invoicing record with a chained hash and a QR code for every invoice, and either sends it to the Spanish tax agency (AEAT) in the VERI*FACTU mode or stores it signed in the non-submission mode. Odoo Enterprise has an official module from version 17; on Community the usual route is the OCA module, available for versions 15 to 18. This guide helps you choose a path and carry it out without surprises.

Last reviewed: 2 November 2026. Legal dates in force: 1 January 2027 (corporate income tax payers) and 1 July 2027 (everyone else). On 5 October 2026 the Ministry of Finance announced its intention to postpone to October 2028; this is announced, pending publication, and until it appears in the BOE the 2027 dates apply. Details in Verifactu: 2027 deadlines, the 2028 announcement and penalties.

What Verifactu is, in plain words

Verifactu is the common name for Spain's regulation on computerised invoicing systems, approved by Royal Decree 1007/2023 as a development of Law 11/2021 on tax fraud prevention (the "Anti-Fraud Law"). The aim is that invoicing software cannot alter invoices after the fact without leaving a trace.

The regulation requires the system to guarantee the integrity, retention, accessibility, legibility, traceability and inalterability of the records. In practice that means four things.

What it requires

1. Invoicing record. Every issued invoice creates a registration record; every cancellation creates a cancellation record.
2. Chained hash. Each record carries a hash calculated from the previous record. Changing an old one breaks the chain.
3. QR code on the invoice, so the recipient can check its validity.
4. Responsible declaration by the software producer stating that the system meets the regulation.

An invoicing record, conceptually

To understand what the module does, picture a record as a card created automatically when you validate an invoice. Conceptually it holds, among other data:

Data (conceptual)	What it is for
Issuer's tax ID (NIF)	Identifies who the invoice belongs to.
Invoice number and date	Place the invoice within your series and calendar.
Amounts and taxes	Summary of what was invoiced, with the VAT (or IGIC) breakdown.
Record type	Registration or cancellation.
Hash of the previous record	The link joining this record to the previous one.
Own hash	Calculated from the data above; it is what seals the record.
Generation date and time	Show when it was created.

The idea is simple: each record's hash depends on the previous one. If someone changed an amount from three months ago, every later hash would stop matching. The exact list of fields and the technical format are set by the regulation and handled by the module; you do not calculate them by hand, but it helps to understand why the system behaves as it does.

The two modes

Mode	What the system does	Details
VERI*FACTU	Sends every record to the AEAT automatically when the invoice is issued.	The invoice may carry the legend "VERI*FACTU" / "Factura verificable en la sede electrónica de la AEAT".
Non-VERI*FACTU (no submission)	Stores the records with an electronic signature and an event log, and hands them over if the AEAT requests them.	No continuous submission, but stricter requirements on signing and events.

You pick the mode when configuring the system. For most small and mid-sized companies on Odoo, automatic submission (VERI*FACTU) is the most direct option, since the module handles sending and retries.

Who it applies to

It applies to businesses and professionals who use a computer system to invoice in Spain's common tax territory, the Canary Islands (where IGIC replaces VAT), Ceuta and Melilla. Excluded are taxpayers who keep their books through the SII (Immediate Supply of Information) and taxpayers of the Basque Country (TicketBAI / Batuz) and Navarre (own regime) when they are taxed there.

If you are in the SII or a foral territory, Verifactu does not apply to those operations. If you have a mixed situation, ask your tax advisor.

Dates, briefly

• 1 January 2027: corporate income tax payers.
• 1 July 2027: all other obliged taxpayers, such as self-employed people under personal income tax.
• Postponement to October 2028: announced on 5 October 2026, pending publication in the BOE.

These dates come from Royal Decree-law 15/2025. Full detail, including penalties, is in the deadlines and penalties guide.

The real options in Odoo

There are three families of solutions. Mixing them up is the most common mistake.

1. Official Odoo Enterprise module

Odoo provides l10n_es_edi_verifactu (invoices) and l10n_es_edi_verifactu_pos (point of sale), available from Odoo Enterprise 17, and also in 18 and 19. They start in test mode by default and require a digital certificate configured in Accounting. See the Odoo documentation for the Spanish localization.

This is the simplest path if you already run Enterprise 17 or later. It exists only in Enterprise.

2. OCA module for Community

The Odoo Community Association maintains l10n_es_verifactu_oca (AGPL-3) in OCA/l10n-spain. It exists on branches 15.0, 16.0, 17.0 and 18.0; it does not exist yet on 19.0. On 16.0 there are also variants: l10n_es_verifactu_oca_oss, a point-of-sale module (l10n_es_verifactu_pos_oca) and an IGIC variant (l10n_es_igic_verifactu_oca, on that branch only). The manifests do not declare a maturity status; PyPI publishes the 16.0 version as beta, and on the other branches the module is under active development, so always test it on a copy first. More in the Verifactu on Odoo Community guide.

3. Paid third-party modules

The Odoo app store lists third-party modules, some with the technical name l10n_es_verifactu and an OPL-1 licence. They are not the official module l10n_es_edi_verifactu, even if the names look alike. Before buying, ask who maintains it, for which versions, whether it comes with a responsible declaration and how it follows regulatory changes.

Decision table: your situation, what to do

Your situation	Recommended path
Odoo 17, 18 or 19 Enterprise	Official module. Configure, test, activate.
Odoo 17 or 18 Community	OCA module on the 17.0 or 18.0 branch, tested on a copy; or migrate if you prefer the official module.
Odoo 19 Community	No OCA module for 19.0 yet. Options: wait for it, move to Enterprise, or evaluate third-party.
Odoo 15 or 16 Community	OCA module on its branch (15.0 or 16.0). Test on a copy.
Odoo 16 Enterprise	The official module is 17+. Options: migrate to 17 or later, or evaluate with your partner the OCA route (a Community module) or third-party.
Odoo 12 to 14	No official or community route. Backport or third-party module (risky), or migrate.
You are in the SII or a foral territory	Verifactu probably does not apply. Confirm with your advisor.
You are in the Canary Islands with IGIC	Same paths; the OCA IGIC variant exists only on 16.0. See the Canary Islands guide.

For the full per-version table, see Does your Odoo version work for Verifactu?

What changes in your day-to-day

The module does more than send data: it changes some invoicing habits. Your team should know them before go-live.

• Validated invoices are not deleted or edited. If you make a mistake, you correct it with a credit note (rectifying invoice) or a cancellation, each of which creates its own record. People used to "resetting to draft" a posted invoice will need to change habit.
• Credit notes and cancellations have their own flow. Each creates a record and is sent just like a registration. Know which one to use in each case and write it into your internal procedure.
• Numbering must be consistent. Series must be sequential and properly configured in the journals. Parallel series or manual numbering are a source of problems.
• The QR code appears on the invoice. Check that your PDF templates show it legibly and that it is not lost when you customise the layout.
• Watch the submissions. In VERI*FACTU mode, someone must review rejected or pending records. A failed submission is not a disaster, but a person must own it.
• Source data matters. Correct tax IDs for customers and your company, properly configured taxes and consistent fiscal positions avoid rejections.

Step-by-step adaptation checklist

1. Inventory. Note your Odoo version, edition (Community or Enterprise), invoicing modules, point of sale if used, and custom developments touching invoices or sequences.
2. Confirm it applies. Check the SII, territory and applicable date with your advisor.
3. Choose a path. Official, OCA, third-party or migration, using the table above.
4. Create a test copy. Never install a fiscal module straight into production. Work on a copy of the database.
5. Install and configure the module. Company, VAT (or IGIC) regime, mode (VERI*FACTU or no submission) and invoice templates with the QR code.
6. Digital certificate. Load the certificate that signs communications and check its validity and expiry.
7. Journals. Check that every sales journal that issues invoices is flagged for Verifactu. An unflagged journal is a frequent failure.
8. Test against the AEAT test environment. Issue registrations, cancellations, credit notes and invoices with different taxes; confirm the responses are correct.
9. Edge cases. Foreign customers, withholdings, equivalence surcharge, discounts, credit notes and connection errors with retries.
10. Training and procedure. Define what to do if submission fails and who reviews rejections.
11. Go-live. Switch to production on an agreed date, ideally at the start of a period, and watch the first days.

How to choose a partner or provider

If you will not do it yourself, the choice of implementer weighs as much as the choice of module. Questions worth asking:

• Which Odoo versions and editions have they already adapted, and can they explain how?
• Do they always work on a test copy and use the AEAT test environment?
• Do they explain the difference between the official module, the OCA one and third-party ones, or do they sell only one?
• Who takes on maintenance when Odoo or the rules change, and at what cost?
• If the module is community-built, can they review the open issues in the repository and judge whether they affect you?
• Do they provide the producer's responsible declaration, or tell you clearly who issues it?
• Do they give a realistic test plan and timeline, and make clear what is out of scope?
• What support do they offer on critical days, such as month-end or quarter-end?
• Are they honest when the answer is "migrate" or "we do not do this"?

Be wary of anyone promising an "AEAT certification" or guaranteeing deadlines without having seen your installation.

Common mistakes

• Mixing up modules. Installing a store module believing it is the official one.
• Trusting a version without testing it. A community module under active development can be fine, but needs thorough testing and follow-up of its issues.
• Unflagged journals or parallel invoice series that bypass the module.
• Leaving test mode on in the official module when going live.
• Waiting until the last minute. Testing, certificate and training take weeks.
• Believing an "AEAT certification" exists. It does not; there is a producer's responsible declaration.
• Editing validated invoices with scripts or direct database changes, which breaks the hash chain.
• Not training the team on credit notes and cancellations.

Can we help?

If you would rather not do this blind, uKodeIT reviews your version, modules and invoicing, and proposes the most sensible route: adaptation with the official module or the OCA one, or a migration if it pays off. See how we work on the Verifactu for Odoo service page, browse our implementations or get in touch.

Related guides

• Verifactu on Odoo Community: the OCA module and alternatives
• Does your Odoo version work for Verifactu? (12 to 19)
• Verifactu: 2027 deadlines, the 2028 announcement and penalties
• Verifactu in the Canary Islands with IGIC and Odoo