What your software must do for VeriFactu: the requirements, one by one

Where the requirements come from

From two pieces of legislation that have to be read together. Real Decreto 1007/2023 (Royal Decree) approves the Reglamento (the Regulation) and says what must be guaranteed; Orden HAC/1177/2024 (Ministerial Order) goes into the detail and says how: formats, algorithms, millimetres. Everything below comes from there.

1. The six adjectives of Article 8

Article 8 is the backbone. It requires the system to guarantee the integrity, preservation, accessibility, legibility, traceability and unalterability of the invoicing records. It sounds like a statement of intent, but paragraph 2 makes it concrete, and that is where it bites:

• 8.2.a) — once generated and recorded, the data cannot be altered without the system detecting it. Hiding or deleting a record counts as alteration, just as changing its data does. Any correction is made with an additional, later record, keeping the original.
• 8.2.b) — the records must be chained, so that their trail can be verified by following the order in which they were created, from the first to the last.

How to check: ask for a demo of what happens when you try to correct an invoice that has already been issued. If the program lets you edit it and save, it does not comply. It should take you to a corrective invoice or a cancellation.

2. The issuance record: when it is created and what it contains

Article 9 sets the moment: the registro de facturación de alta (invoice issuance record) is generated at the same time as, or immediately before, each invoice is issued. It is not an overnight batch job or a button someone presses at the end of the month.

Article 10 lists its content: tax ID of the issuer and of the recipient, number and series, dates, invoice type, breakdown of tax bases and tax amounts, the hash of the previous record, the identification of the invoicing system that generates it and the timestamp, among others. Eighteen items in all, lettered a) to q) (the Spanish alphabet includes ñ).

How to check: ask whether the record is created within the same transaction as the invoice. If the invoice can end up issued while the record fails separately, you have a gap: two different truths about the same document.

3. The hash: SHA-256 and the chain

Article 12 of the Regulation requires a hash (huella) to be added to issuance and cancellation records. Orden HAC/1177/2024, in its Article 13, specifies exactly which fields go into the calculation for each type of record, and its annex allows only one algorithm: SHA-256.

Each record includes part of the hash of the one before it. That builds a chain: if someone tampered with a record in the middle, every later hash would stop matching. It is the mechanism that makes the unalterability required by Article 8 verifiable.

How to check: ask whether the system has a function to verify the integrity of the whole chain and what it does if it detects a break. A program that calculates hashes but never checks them will give you the bad news on the day of the tax inspection, not before.

4. The cancellation record

Article 11 governs the registro de facturación de anulación (invoice cancellation record), generated when an invoice has been issued in error. It is important to understand what it is not: it does not delete anything. It adds a record documenting the cancellation, and the original remains.

How to check: see whether the program distinguishes between cancelling (the invoice should never have existed) and correcting (the amount or the details were different). They are not the same thing and are not handled the same way.

5. The event log

Less well known, and often only half quoted. Article 8.3 requires the system to have an event log (registro de eventos) that automatically records certain interactions and operations, without the user being able to intervene. The idea is to leave a trail of what happens around the invoicing records — start-ups, configuration changes, incidents — and not just of the invoices.

How to check: ask to see that log. It must exist as such within the system, and not be the server's technical log that the supplier looks at whenever they feel like it.

6. The two modes: submit or sign

Article 15 opens the door to submitting the records voluntarily, and Article 16 defines what a VERI*FACTU system is: one that submits them “continuously, securely, correctly, completely, automatically, consecutively, instantly and reliably”. The choice has consequences:

For most small and medium-sized businesses, VERI*FACTU is the less complex option: you swap the burden of signing and safekeeping for the burden of staying connected.

7. The QR code and the wording on the invoice

The Order goes down to the millimetre. Its Article 21 requires a QR code measuring between 30 and 40 millimetres a side, compliant with the ISO/IEC 18004 standard, containing the issuer's NIF (Spanish tax ID), the invoice number, the date and the amount. And if the system is a VERI*FACTU one, Article 20 adds the wording “Factura verificable en la sede electrónica de la AEAT” or “VERI*FACTU”; in non-verifiable mode, the invoice carries only the QR code.

How to check: issue a test invoice and scan the QR code with your phone. It should take you to the Agencia Tributaria's verification service. And watch out for a detail that is easy to miss: if the system is working in the test environment, the QR code has to point to the test environment, not to the live portal, where that invoice does not exist.

8. The statement of compliance

Article 13 of the Regulation requires the software producer to issue a declaración responsable certifying that the system complies with Article 29.2.j) of the Ley General Tributaria (General Tax Act) and with the Regulation itself. It must appear in writing and visibly in the invoicing system itself, in each of its versions, and be provided to customers and resellers.

Two practical consequences that hardly anyone mentions:

• It is per version. A supplier with continuous deployment needs a versioning policy and must keep the statement for every version it has produced.
• It goes inside the program. It is not a PDF in the sales drawer: it must be viewable from within the system itself.

What the law doesn't say but shows in production

So much for the letter of the law. These four points don't come from the BOE (Spain's Official State Gazette); they come from having the system up and running:

1. Retrying submissions. The Agencia Tributaria's portal has outages and maintenance windows. If a network failure stops your invoicing, the problem lies in the design, not with the AEAT. The record has already been generated and chained; the submission must retry on its own, with the status of each one visible.
2. The mode is frozen in the invoice. What matters is how the document was issued, not how the system happens to be configured on the day someone reprints it. If the wording on the PDF is worked out on the fly, a future reprint can contradict the original invoice.
3. A real test environment. Before invoicing for real, you need to be able to rehearse against the AEAT's test environment, with its own verification URL.
4. Several companies, several chains. If you invoice from more than one company, each one needs its own numbering, its own certificate and its own hash chain, kept separate. We cover this in VeriFactu in a transport company.

Ten questions for your supplier

1. Can you show me the statement of compliance for the version I have signed up for?
2. Which mode does the system work in, VERI*FACTU or non-verifiable?
3. Is the issuance record generated in the same transaction as the invoice?
4. Can I verify the hash chain from within the program?
5. What exactly happens if I try to modify an invoice that has already been issued?
6. Does it distinguish a cancellation from a corrective invoice?
7. Where can I see the event log?
8. What happens if the AEAT doesn't respond? Does it retry on its own? Can I see it?
9. If I invoice from two companies, does each have its own series and its own certificate?
10. If I move into the SII next year, what do I need to change?