VERI*FACTU and Custom Invoicing Software: What Spain Requires by 1 January 2027

Before 1 January 2027, every company in Spain that files corporate income tax (Impuesto sobre Sociedades) and invoices from software must be using software adapted to Real Decreto 1007/2023. Every invoice gets a hashed record chained to the one before it, and a QR code the customer can check against the tax agency. Everyone else in scope, mostly the self-employed, has until 1 July 2027.

If your invoices come out of a commercial package, this is largely your vendor's job. If they come out of software somebody wrote for you, or that your own team wrote, it is yours. You change the code, and you sign the declaration that says it complies.

The Dates, and the Two Postponements

This is the third set of dates, so some scepticism is fair.

• Real Decreto 1007/2023 originally gave businesses until 1 July 2025.
• Real Decreto 254/2025, of 1 April 2025, moved that to 1 January 2026 for corporate tax filers and 1 July 2026 for the rest. The reason was concrete: the technical order, Orden HAC/1177/2024, was only published on 28 October 2024.
• Real Decreto-ley 15/2025, of 2 December 2025, moved both dates by a year. Its text is in the BOE, and Congress convalidated it the same month.

AEAT's note on the extension, updated 26 March 2026, is unambiguous: "las entidades que presenten el Impuesto sobre Sociedades deberán tener adaptados sus SIF antes del 1 de enero de 2027. El resto de obligados tributarios, antes del 1 de julio de 2027."

Could it move again? Nothing official says so as of October 2026. The first delay had a technical cause that no longer exists. AEAT's submission services have been in production since 23 April 2025, and since 29 July 2025 software vendors may only offer adapted systems. Planning on a third postponement is a bet, not a plan.

Which date is yours? An SL or SA files Impuesto sobre Sociedades, so a company running its own ERP is almost certainly on the 1 January 2027 date. That is under three months away. The July date is for the self-employed and the other taxpayers in scope.

Who Is In Scope, and Who Is Not

AEAT's scope FAQ reduces it to four negatives. You are in scope if you do not invoice exclusively by hand, are not in SII (compulsorily or by choice), do not have your tax domicile in the Basque Country or Navarra, and hold no exemption ruling.

The exclusions, in practice:

• SII filers. The Suministro Inmediato de Información is mandatory for companies with turnover above €6 million, VAT groups and businesses on the monthly VAT refund register (REDEME), and others can opt in. AEAT puts it plainly: "El ámbito subjetivo de ambos proyectos es excluyente." If you move into SII, you stop sending VERI*FACTU records and stop printing the QR code.
• The Basque Country and Navarra. Businesses with their tax domicile there answer to the foral tax authorities and their own rules, not RD 1007/2023.
• Purely manual invoicing. A paper invoice book is out of scope. So is a spreadsheet used only to type, print and keep invoices; one that also produces your VAT books is not.

Foreign companies are in scope when they have a permanent establishment in Spain.

If you invoice from a commercial package (A3, Sage, Holded and the like), the vendor is the producer and has to ship an adapted version with its own declaration. Update it, check the declaration is there, and you can stop reading.

This article is for the rest: a custom ERP, an Access, Delphi or FileMaker program written fifteen years ago, or a billing module inside your own web platform.

Your Company Is the Producer

Article 13.1 of the regulation puts certification on whoever produces the system, by means of a declaración responsable. AEAT's certification FAQ answers the in-house case directly: "Cada sistema en operación debe disponer de una Certificación emitida mediante declaración responsable de su productor (artículo 13.1 RRSIF). Si el software hubiera sido desarrollado por la propia empresa, será esta la que deba certificarlo."

What that means in practice:

• There is no external audit. AEAT calls it an "auto-certificación" of the producer. Nobody approves your system in advance. You sign, and you answer for it.
• A contractor who builds an extension for you as a product certifies that extension. If you built it yourself, you certify it.
• The declaration has to be visible inside the system, in every version, and also reachable outside it, independently of the product.
• Its content is fixed by article 15 of Orden HAC/1177/2024: among other things, the system's name, identifier and version, its components, whether it works only in VERI*FACTU mode, the producer's name, NIF and address, and the date and place of signature.

The awkward case is the program whose author left years ago. Someone still has to produce the adapted version and sign for it. Decide who that is, in writing, before the work starts.

Customising a certified commercial product only needs a separate declaration if the change touches how the regulation's requirements are implemented. A modification made outside the producer's control that can alter them does not comply.

The stakes are set by article 201 bis of the General Tax Law: a fixed fine of €150,000 per financial year and per type of system for producing systems that fail the requirements, and €50,000 per financial year for holding a system that should be certified and is not, or that has been altered. Which of these a self-built system would attract is a question for your tax adviser. Neither number is small.

What the Software Has to Do

A record for every invoice, at the moment of issue

Article 9.1 requires the system to generate a registro de facturación de alta "de forma simultánea o inmediatamente anterior a la expedición de cada factura". A voided invoice gets a cancellation record (registro de anulación).

Article 10 lists what the record holds: issuer NIF and name, the recipient where required, series and number, issue and operation dates, invoice type, details of any invoice it rectifies, a description, the total, the VAT regime, tax base, rates and amounts, exemption or non-subjection reasons, the identity of the system and its producer, and a timestamp to the second.

In older systems, this is where the work hides:

• VAT breakdowns are often calculated at print time and never stored. They have to exist as data at the moment of issue.
• "Issuing" is often just printing a report. There has to be an explicit point where a draft becomes an invoice, and the record is created then.
• Number reuse is over. Deleting an invoice and reusing its number, a habit in plenty of small systems, now fails: AEAT rejects the second record as "Registro de facturación duplicado." Test invoices issued in production are real invoices and must be cancelled.
• Nobody edits records. AEAT's FAQ says direct changes to the database of issued records must not be a permitted operation. If staff fix invoices with SQL today, that stops. Corrections go through rectifying invoices.

The hash chain

Each record carries the series, number and date of the previous record and part of its hash (huella). The algorithm is SHA-256, and the exact fields and concatenation are in AEAT's technical documentation, along with the record designs, XSD schemas, WSDL and the validation and error catalogue.

Before generating a new record, the system must check that the last one is correctly chained and that its timestamp is not more than one minute later than the current time. Records are generated in the order invoices are issued.

That has an architectural consequence. Each installation needs a single, serialised point where records are created. Two web servers appending to the same chain without coordinating will break it. AEAT accepts mixed setups, such as POS terminals that receive the record from a central back office, but the chain itself lives in one place.

Each system is identified by the taxpayer's NIF, a two-character system ID and an installation number that may never repeat, even when the same software is reinstalled on the same machine.

The QR code on the invoice

Every invoice carries a QR code following ISO/IEC 18004, between 30x30 and 40x40 mm, with error correction level M. It encodes a URL containing the issuer's NIF, the series and number, the issue date and the total, which the customer can check against AEAT. In VERI*FACTU mode the invoice also states "VERI*FACTU" or "Factura verificable en la sede electrónica de la AEAT".

For legacy software this means reworking the invoice template (an Access report, a FileMaker layout, a PDF generator) and adding a QR library to a stack that never had one.

Two modes: VERI*FACTU or not

VERI*FACTU mode. The system sends every record to AEAT automatically, as it is generated. In exchange, records need a hash but no electronic signature, AEAT keeps them, and a system that only works in this mode needs no event log. You need a SOAP client against AEAT's published services, a qualified electronic certificate, and a queue for when the connection fails. AEAT's developer FAQ treats an outage as an incident: records wait in the queue and are retried, and invoicing carries on.

Non-VERI*FACTU mode. Records stay with you, and each must be signed (XAdES Enveloped, ETSI EN 319 132) with a qualified certificate. The system must also keep a signed event log covering start and stop in this mode, anomaly checks and what they find, backup restores and exports, with a summary event at least every six hours of operation, and it must hand records over when AEAT asks.

For a bespoke system, VERI*FACTU only is usually the smaller build. No signing infrastructure, no event log, no anomaly tooling. A system that offers both modes has to implement all of it.

A Plan That Fits Before 1 January 2027

From early October, a corporate tax filer has about thirteen weeks. This is the order that works.

1. Week 1: inventory. List every system that issues invoices: the ERP, the web shop's billing module, the subscription script, the counter terminal. Confirm you are not in SII or under foral rules.
2. Weeks 1 to 2: decide who signs and which mode. Name the producer for each system. Choose VERI*FACTU only unless you have a reason not to. Make sure the company's qualified certificate exists and someone owns it, because AEAT's developer FAQ notes the system cannot operate without one.
3. Weeks 2 to 4: data gap analysis. Compare what your system stores against article 10 and AEAT's record design. Missing VAT breakdowns, invoice type codes and rectification references show up here.
4. Weeks 3 to 8: build. Record generation at issue, the chain and its checks, immutable storage, cancellation, the QR on every template, and the submission client with its retry queue. Remove direct edits to issued records.
5. Weeks 6 to 10: test. Start in AEAT's test environment, then send real records. AEAT treats the time before your deadline as a test period, during which you may stop sending and fall back to another system. Read the developer FAQ before writing the cancellation and rectification flows: it covers most of the edge cases.
6. Weeks 9 to 12: declare and train. Write the declaración responsable, show it in the application and outside it, and record the version. Tell finance that numbers are never reused and errors are fixed by rectifying invoices.
7. Mid-December: go live. A deadline that reads "antes del 1 de enero" is not a go-live date. Go live a fortnight early, so the first problems surface while there is still time.

On the 1 July 2027 date, the same plan applies with more room. Start in January, not in May.

Two alternatives to rebuilding are worth weighing honestly. AEAT accepts mixed architectures, so your ERP can keep preparing invoice data while a separate component, bought or built, generates the records, the QR and the submission, provided the declarations cover how the parts fit together. And if the old program issues a handful of invoices a month, AEAT's free invoicing application for small businesses, or a standard package, may cost less than adapting it.

Where to Get Help

We change invoicing code that companies already run, including older stacks: record generation, the hash chain, the QR on your templates and the AEAT submission client, with tests left behind. Our e-invoicing integration service covers the build, and legacy system maintenance is where it starts when nobody left knows how the old program works.

If you have a 1 January 2027 date and a custom system, write to office@c9group.dev. We are engineers rather than tax advisers: scope and liability questions belong with yours, and we build to the answer they give.