Frequently asked questions (FAQ)
Compilation of questions and answers regarding the Billing Computer Systems and VERI*FACTU
Features and requirements of SIFs: integrity and unalterability
The SIF must guarantee the integrity and inalterability, traceability, and conservation of the billing records, in accordance with the terms established in article 8 of the RRSIF and its implementing regulations. In addition, it must have an event log that records certain interactions with the system determined by ministerial order (among others, the detection of anomalies in the integrity, unalterability and traceability of billing records or in the event log itself).
As regards developers and their responsibility, they must meet the regulatory requirements to ensure that, during the period of retention of the records, there have been no improper interactions with them that have altered, modified, interpolated, deleted or regenerated them. They must also certify to their clients that they comply with these requirements. Naturally, the sanctioning regime referred to in article 201.bis of the LGT must take into account, when sanctioning the behaviour of system manufacturers and users, whether their behaviour has involved culpability, even through mere negligence, or whether the destruction or hacking of programme codes has occurred.
No, a billing record, once generated (and signed/sent to the AEAT depending on the method used) should never be modified by anyone (if it were, it could be detected: thanks to the fingerprint, signature, chain...). Any "change" that you wish to record must be done by generating one or more - as needed - new billing records, of the type that corresponds to each case (normally - and preferably - using the procedures established by the regulation of billing obligations). If by correcting you mean “recovering” in some way what was already generated, but had been “lost” or “corrupted,” the answer must be the opposite.
As regards data corruption, it is recalled that all the requirements of the regulation and the order must be met, with conservation being of particular importance in this case (and also legibility, accessibility and unalterable integrity), so the necessary means must be put in place to prevent corruption and guarantee conservation.
Finally, on the issue of migration, the regulation and the order do not address what is subsequently done with the billing records generated (such as their possible sending to other systems with the idea of using them for other purposes), beyond requiring their conservation, legibility and accessibility in the future during the conservation period.
An incorrect billing record must be corrected by generating a new billing record and, if applicable, submitting it to the VERI*FACTU systems (since the incorrect record cannot be altered if it has already been issued).
According to the record design that will be published in the Ministerial Order (already available on the Electronic Headquarters of the AEAT ), this new generation of a billing record must have 'Record Type'="Substitute" and SubsanaError indicator to "S". Traceability is not affected, as it is linked to the billing records according to the temporal order of their generation, not to the invoices to which they refer.
The regulation approving RD 1007/2023, of December 5, and the Ministerial Order that develops it only apply to computerized billing systems ( SIF ), that is, those systems that are used to issue invoices or simplified invoices. Any other computer system other than billing is not, in principle, affected by the regulations.
The general traceability requirements arising from the literal of article 29.2.j) determine that, for computer purposes, the system for generating pre-invoicing, drafts or proformas without tax validity, must be inextricably linked to the Invoice Issuance System, forming a unit. For this reason and for reasons of internal control, it is advisable to keep records of the pre-invoices or pro forma invoices prepared.
Since the billing record is generated immediately before issuing the invoice, it must be understood that at the time of generating said record, it will also be sent to the AEAT , or it will be signed.
Any data for which the billing regulations do not require the issuance of a corrective invoice can be corrected (Substitute record type). In any case, if the modified invoice data is not in the generated and signed/sent billing record (nor does it affect any of the fields in this record), there would not be any need to correct anything in the generated and signed/sent billing record. It can be changed without affecting the integrity of the file.
If the loss only affects billing records, in a VERI*FACTU system this situation would be less problematic because the records would be held by AEAT and the taxpayer could recover them in their entirety. In a system of issuing non-verifiable invoices, it is the entrepreneur who must ensure the preservation of the billing records, as established by the standard, without denying the possible existence of cases of force majeure that would exclude culpability and could lead to determining the taxable bases by the indirect estimation method.