VeriFactu for integrators and software producers
What to know if you develop, sell or implement software that issues invoices in Spain. Clear explanations with sources. This page is updated when the rules change; its review date appears below.
What VeriFactu means, in one sentence
VERI*FACTU is a mode of invoicing software systems (SIF) that submits records to Spain’s Tax Agency, the AEAT. An obligation to adapt a system does not necessarily require choosing that mode. Scope and requirements are set out in Royal Decree 1007/2023 and Order HAC/1177/2024.
Current deadlines
| Who | From | Source |
|---|---|---|
| Software producers and distributors | 29 July 2025 | Fourth final provision of Royal Decree 1007/2023: nine months after Order HAC/1177/2024 entered into force on 29 October 2024 |
| Corporate Income Tax taxpayers | 1 January 2027 | First final provision of Royal Decree-law 15/2025, which rewrites the fourth final provision of Royal Decree 1007/2023 |
| Other taxpayers within scope, including sole traders and income-attribution entities | 1 July 2027 | The same provision |
Reviewed: 8 September 2026. The deadlines apply to the persons within scope and under the conditions in the fourth final provision, which also addresses systems under multi-year maintenance contracts. Check the calendar and scope before classifying an installation.
Who falls outside
- Businesses under the Immediate Supply of Information (Suministro Inmediato de Información, SII) already report their invoices and do not apply VeriFactu.
- Foral tax rules: check the applicable regime under the relevant economic agreements. A postal address alone does not resolve every case.
The AEAT’s free application is not an exemption
A common distinction matters: the AEAT’s free application is an invoicing software system operating in VERI*FACTU mode. Its users are not outside the rules; they comply through it. For a sole trader issuing few invoices, it may be a reasonable option, and we say so where appropriate. It does not resolve integration with an ERP, point-of-sale system or custom application already used to invoice.
If you support several types of client, start by classifying them. That is the starting point of our technical assessment.
What your software needs to do
Invoicing records
For each invoice issued and each cancellation, a record contains the fields specified by the Order: issuer, number and series, date, type, breakdown by regime and tax, total amount, previous invoice reference and hash. It is generated at the time of issuance, not afterwards from the PDF. Adding a QR code to an already-issued PDF is not a compliant fix.
Chained hashes
Each record includes a SHA-256 hash calculated from its own data and the previous record’s hash. Breaking the chain is detectable. This requires sequential generation and careful concurrency handling: two processes issuing simultaneously must not create two records for the same event.
QR code and required wording
The invoice carries a QR code with the AEAT verification URL and, in VeriFactu mode, the wording “Factura verificable en la sede electrónica de la AEAT” or “VERI*FACTU”. The quoted wording is retained in its official Spanish form.
Submission and states
In VeriFactu mode, the record is submitted to the AEAT at issuance. Responses have two levels. For the whole submission, EstadoEnvio can be Correcto, ParcialmenteCorrecto or Incorrecto. For each record, EstadoRegistro can be Correcto, AceptadoConErrores (registered with warnings) or Incorrecto (rejected and not registered).
“Unknown” would be an internal label, not an official catalogue value. A lost response requires reconciling the result under the protocol before choosing the next attempt. The conceptual guide to states and retries distinguishes these scenarios and links the official specification; it does not offer a connected service or invented error codes.
Event logging and integrity
Retention, signing and event-log requirements depend on the mode and applicable scope. Identify them during assessment and preserve traceability of changes; a correction must not become a silent edit of the original.
The declaration of responsibility, without misconceptions
The rules do not establish prior Tax Agency authorisation or a register of approved products: there is no such approval application or listing. What the AEAT calls system “certification” is the producer’s declaration of responsibility (declaración responsable). It is signed by the software producer, identifies the product and version, and is accessible from the software itself. Article 13 of Royal Decree 1007/2023 establishes it; Article 15 of Order HAC/1177/2024 specifies its content.
Ask for the document and the version it covers. It is not prior AEAT approval. Read the detailed explanation.
When integrating components, document each component’s scope and responsibility for the whole system. The fictional sample report explains what to review; it is not a delivered integration. You can request an assessment today. The KeneaFactu connector and operations require an agreed scope, development and testing.
Three ways to adapt software, and when to consider each
| Option | When it makes sense | Risk |
|---|---|---|
| Update to the vendor’s official module | It exists, covers your installation and is maintained by the vendor | Old or customised installations may be outside its scope |
| Integrate a tax API yourself | You have a development team and few source systems | Check what the provider covers and what your integration must handle |
| Assess an integration and control layer with Kenea | You maintain many clients on the same source system and want a consistent approach | Depends on the source allowing record generation at issuance |
Risks to include in testing
- Generating records from a PDF or report instead of the act of issuance.
- Retrying without reconciling results or controlling repetitions.
- Mixing issuers in one hash chain.
- Failing to separate drafts, issued invoices and tax records in the data model.
- Treating corrective invoices and cancellations as edits to the original invoice.
- Using an integrator’s certificate for every client without formalised representation.
What about B2B electronic invoicing?
Electronic invoice exchange between businesses is a separate framework. Do not derive its timetable from SIF deadlines: it needs a specific regulatory review with your adviser.
Sources
- Royal Decree 1007/2023, the invoicing software systems regulation.
- Order HAC/1177/2024, technical specifications.
- AEAT: invoicing software systems, FAQs and test environment.
- AEAT: declaration of responsibility.
Discuss an assessment of my software
This guide is general technical information, not tax or legal advice. Discuss your circumstances with your adviser.