Application: ALL TAXPAYERS WHO ISSUE INVOICES AND ARE NOT REQUIRED TO USE THE Immediate Supply of Information (SII).
With the publication of Royal Decree 1007/2023 in the Official State Gazette (BOE), the regulation establishing the requirements for billing software systems was approved. The approval of the Ministerial Order that specifies the technical, functional, and content requirements was still pending. Finally, on 28/10/2024, this long-awaited Ministerial Order has been published. From now on, software manufacturers and developers have 9 months to adapt / develop billing systems according to this Ministerial Order, i.e. until 29/07/2025.
According to the dates specified in RD 1007/2023, the effective date for all obligated parties would be 1 July 2025, which is before developers are required to have their billing systems adapted. The AEAT (Spanish Tax Agency) has informed us that they are already working on adjusting the dates, but this could not be done with this Ministerial Order. The AEAT is working on changing the dates, with 1 January 2026, as the likely new date.
Let’s review the requirements that billing systems must meet as outlined in the various chapters of the Ministerial Order:
General Provisions and Definitions of Billing Systems and Components
1. Purpose: To detail the technical, functional, and content aspects of billing systems and programmes that comply with Royal Decree 1007/2023, focusing on the integrity and traceability of records.
2. Key Definitions:
• Billing System: Software or hardware designed to issue invoices in compliance with regulatory requirements.
• Billing Component: A combination of hardware and software that implements or manages the requirements for billing systems.
• Primary Billing Component: Responsible for implementing the necessary functionality to issue invoices, ensuring compliance with regulatory requirements.
3. Multiple-Taxpayer support: Where a system supports multiple users or taxpayers, it shall ensure the independence of each set of billing records, maintaining unique record chains for each taxpayer and operating autonomously for each case.
Technical Specifications, Including the VERI*FACTU System This chapter defines the technical and functional requirements for billing systems, divided into sections:
Section 1: VERI*FACTU Specifics
• Systems classified as VERI*FACTU automatically meet certain requirements for record integrity, traceability, and retention.
Section 2: Submission of Information to the Tax Agency
• Requirements for electronic and secure transmission of billing records, including:
• Internet connection and use of electronic certificates for authentication.
• Secure communication protocols.
• Management of responses and acknowledgements from the Tax Agency.
Section 3: System Requirements
• Integrity and Immutability of Records: Each record must have a verifiable digital footprint (hash) and an electronic signature.
• Traceability: Records must be chronologically linked, facilitating tracking.
• Retention and Readability: Systems must allow for the retention of records, quick access, and the ability to export them.
Section 4: Other Requirements
• Event Log: Each system must record specific events, such as the start or end of operations, and anomaly detectors. This helps ensure transparency and consistency of records.
Requirements for Generating and Content of Billing Records
1. Format and Encoding: Records must comply with a specific XML format, ensuring consistency in export and retention.
2. Content of Creation and Cancellation Records:
• Creation Records: Must include details such as the issuer’s NIF, invoice number, issuance date, and hash of the previous record.
• Cancellation Records: Contain the same type of information, ensuring that any cancelled record is correctly referenced.
3. Hash and Electronic Signature: Specifies how the hash and electronic signature are generated using security standards. The hash is calculated using an algorithm and stored alongside each record to ensure integrity.
Obligation for a Responsible Declaration
1. Declaration Content:
• Each billing system must include a responsible declaration certifying compliance with the regulations.
• Details to be provided: name and version of the system, components, producing entity, compliance with Article 29.2.j) of Law 58/2003, among others.
2. Availability: The declaration must be available to the user of the system, the distributor and the customer, either in paper or digital format.
3. Extensions: If the system is extended with other components, each producer must add a responsible declaration confirming compliance for each update.
The Tax Administration will develop responsible declaration models for software producers and developers.
Requirements for the Billing Application Developed by the Tax Administration
This chapter defines the conditions and limits of the billing application that the Tax Administration may develop:
1. Minimum Functions of the Application:
• Capture, storage, consultation, and download of invoice data.
• Issuance of invoices in printable PDF format.
• Download of the invoice in PDF-format.
• Generation and storage of the billing record.
2. Conditions of Use:
• The application can only be used to issue invoices on one’s own behalf or as an authorised representative.
• Access requires authentication through identification systems approved by the AEAT.
• Issued invoices must include a recipient.
• Both invoices and their linked records may only be managed through this application.
Instructions for Adding a QR Code on Invoices
1. QR Code:
• The QR must be included on each issued invoice, sized between 30×30 and 40×40 millimetres, complying with ISO/IEC 18004 and using level M error correction.
• The QR code content must include the URL of the verification or information submission service and invoice data such as the issuer’s NIF, serial number, date, and total amount.
2. Additional Text:
• For invoices issued through VERIFACTU systems, the phrase “Verifiable Invoice at the AEAT Electronic Headquarters” or “VERIFACTU” must be added to indicate the document’s authenticity and verifiability.
3. Electronic Invoices:
• In the case of electronic invoices, it is not necessary to include the QR code in the image, but the URL should be included as an additional field.
The AEAT has enabled a testing environment for developers to conduct tests and has published technical specifications both on the developer portal and at the AEAT headquarters. It is expected that this documentation, as well as the Ministerial Order, will be available in English, although no date can be specified. The publication of FAQs on VERIFACTU is also scheduled for today.
One interesting point is for companies that issue self-bills to their suppliers: If these companies are in the SII but issue invoices to suppliers who are not, and the latter are therefore required to comply with VERIFACTU, will the issuing company be obliged to comply with VERIFACTU? They indicate that initially they would be obliged, but this is being addressed and a solution is being worked out. The AEAT has provided a portal for developers where information has been published for months and has been updated following today’s publication of the Ministerial Order.
We recommend that you contact with your billing software provider to confirm that it is compliant with the VERIFACTU regulation. Billing software can be either Verifiable or Non-Verifiable (as the submission of billing records to the AEAT is voluntary), but in either case, it must meet the basic requirements stipulated in RD1007 and the Ministerial Order. The difference is that the former must be connected to the AEAT in “real time” to submit the records, while the latter must be able to connect in the event of an inspection. The submission can be made by the obligated party, an authorised representative or a social worker registered as a consultant.
We are available to answer questions and provide support in the months before and after the implementation.
For more information, we remind you of the session we held on “Q&A on mandatory e-invoicing in Spain”.
