Verifactu and a custom ERP: what the software has to do

If your company issues its invoices with a program, whether a commercial product or a custom-built ERP, that program has to comply with Spain's regulation on invoicing software, which everyone calls Verifactu (RD 1007/2023, BOE). In practice it means four things: one record per invoice, chained to the previous one with a hash; a QR code on the invoice; no way to change what has been recorded without leaving a trace; and a compliance statement (declaración responsable) signed by whoever programmed the system. If the ERP is custom, that "whoever" is not a large vendor: it is the company or the person who built it.

This is not tax advice: for your specific case, check with your accountant.

What the official gazette says and what the Ministry has announced

The regulation as currently in force requires companies paying corporate tax to have an adapted system before 1 January 2027, and everyone else, sole traders included, before 1 July 2027 (RD 1007/2023, fourth final provision, BOE). Those dates were set by the latest postponement (Royal Decree-law 15/2025, BOE).

On 5 October 2026, the Ministry of Finance published a note announcing the planned postponement of the pending obligations to October 2028, to line them up with mandatory e-invoicing for businesses invoicing up to 8 million euros a year (Ministerio de Hacienda, 2026). As of today, no rule published in the BOE puts it into effect: until one is, the binding dates are the 2027 ones.

The same note says something more useful for anyone adapting a program: the requirements of integrity, preservation, accessibility, legibility, traceability and unalterability will stay "in substantially equivalent terms" (Ministerio de Hacienda, 2026). The date may move. What the software has to do will not.

What the program has to do with every invoice

The regulation requires that, at the same time as each invoice is issued or just before, the system automatically creates an issuance record (RD 1007/2023, art. 9, BOE). That record holds the invoice data (issuer, recipient, number and series, date, tax bases, rates and amounts, total), the identification of the system that issued it, the exact date and time, and a reference to the previous record with part of its hash (art. 10).

The hash is a cryptographic fingerprint. The ministerial order implementing the regulation sets the algorithm, SHA-256, and which fields go into it: issuer tax ID, number and series, date, invoice type, total tax, total amount, the previous record's hash and the moment it is generated (Order HAC/1177/2024, BOE). Since each hash includes the previous one, the records form a chain: if someone changes one, everything after it stops adding up.

An invoice issued by mistake is not deleted. The system creates a cancellation record, which also joins the chain (art. 11). And any correction is made with new records, never by rewriting an old one (art. 8).

The printed or PDF invoice also carries a QR code with the issuer's tax ID, series and number, date and total amount, which the recipient can scan to check it on the Tax Agency's website (Order HAC/1177/2024, BOE).

Invoice issued

Issuance record with hash

Is it sent to the Tax Agency?

VERI*FACTU mode

no

Signature and event log

Two ways to comply: send it or keep it signed

The regulation lets you choose between two operating modes, and the technical difference is large.

VERI*FACTU mode. The program sends every record to the Tax Agency automatically and continuously (RD 1007/2023, arts. 15 and 16, BOE). In return, it is presumed to meet the integrity and traceability requirements, it only has to compute the hash (no electronic signature), and the invoice carries the phrase "Factura verificable en la sede electrónica de la AEAT" or "VERI*FACTU". Each submission is an XML message sent over the internet and authenticated with an electronic certificate; between submissions the program waits as long as the Tax Agency says, starting at 60 seconds, and bundles at most 1,000 records per message (Order HAC/1177/2024, BOE). If the connection fails, it has to keep the records and retry.

Non-submission mode. The program keeps the records, but then each one has to be signed with a qualified electronic certificate (XAdES format) and the system has to keep an event log: start and stop of this mode, integrity checks, backup restores and exports, with a summary at least every 6 hours of operation (Order HAC/1177/2024, BOE).

For a custom ERP, the choice changes the work. With submission, you have to build the connection to the Tax Agency and the retry handling. Without it, you have to handle signing, safeguard the certificate and maintain the event log. Decide it before the design, not at the end.

If your ERP is custom, who is the producer

This is the point most often missed. The regulation does not only bind whoever invoices: it also binds whoever produces the invoicing software (RD 1007/2023, art. 3.2, BOE). The producer certifies that the system complies through a compliance statement, which has to appear in writing and visibly in the program itself, in every version (art. 13).

The Tax Agency applies it to custom cases like this (AEAT, FAQ on the compliance statement):

• Every system in operation needs its own statement, even if only one company uses it.
• If the company programmed it with its own staff, the company is the producer.
• If it commissioned the development or an extension from someone else, that third party is the producer and certifies it.
• If a vendor modifies a program certified by someone else, the original certification no longer covers the modified part.

And the producer's deadline is a different one. Producers had to offer adapted products within nine months of the implementing order coming into force (RD 1007/2023, fourth final provision, BOE), and that order came into force on 29 October 2024 (Order HAC/1177/2024, BOE).

The penalties differ too. Holding a system that should be certified and is not carries a fine of 50,000 euros per financial year; producing it, 150,000 euros per financial year and per type of system (General Tax Law, art. 201 bis, BOE).

What does not work: an invoice you can edit

Most custom management software treats an invoice like any other piece of data: it is created, edited and, if needed, deleted. That model runs straight into the regulation, which requires that recorded data cannot be altered without the system detecting it, and that corrections are made with new records (RD 1007/2023, art. 8, BOE).

In design terms, that means:

• Append-only records. The invoicing records table does not allow updates or deletes, and the application has no screen that tries to.
• Corrective invoices and cancellations as new documents, never as changes to the original invoice.
• Numbering and hash computed in the same step as issuance, so no invoice is ever issued outside the chain.
• Readable export of the records throughout the retention period (art. 8).

If the ERP already exists and has an "edit invoice" button, adapting it is not a matter of adding a QR code to the PDF. It means changing the data model of the invoicing module.

Sometimes the most sensible way out is for the ERP not to issue invoices at all. It prepares the data and the invoice is issued by an invoicing program certified by its vendor. Mind the limits: the Tax Agency considers that even a spreadsheet becomes an invoicing system if, besides issuing invoices, it generates record books or other outputs (AEAT, FAQ on scope). Where the line falls in your case is a question for your accountant.

What to ask whoever maintains your program

We write this from the inside. Optimio issues its own invoices with a program we wrote ourselves, in production since 17 October 2026 and running in VERI*FACTU mode: every invoice creates its record with a chained hash, carries its QR code and is sent to the Tax Agency the moment it is issued. The first one came back from the Tax Agency marked "Correcto" (accepted). Invoices are never edited: anything that needs fixing goes into a corrective invoice. Because we built it and we use it, we are both producer and user, compliance statement included. These are the questions we would ask any vendor, starting with ourselves:

1. Who signs the compliance statement for this version, and where do I see it inside the program? If nobody can answer, the system is not certified.
2. Does it run in VERI*FACTU mode or without submission? In the second case, who safeguards the certificate used to sign the records?
3. Can an invoice be edited or deleted once issued? If the answer is yes, the data model has to change.
4. What happens if the connection to the Tax Agency drops mid-morning? The program has to keep invoicing and send later.
5. If a third party has touched the invoicing module, who certifies that part?
6. How do I export the records if I change vendor? They must be deliverable in readable form for the whole retention period.

If your program needs adapting, how we do it is explained in custom VERI*FACTU invoicing. How a custom program fits alongside the one that does the accounting is covered in how to automate processes in a small business, and the kinds of projects we take on are in services.