VERI*FACTU Adaptation Mistakes That Can Become Expensive

An invoice can look correct while the system behind it is wrong. That is the uncomfortable part of adapting to Spain’s invoicing-system rules. A QR code appears on the PDF, the software dashboard says “VERI*FACTU ready”, and the project is marked complete. Nobody has checked which software version produced the invoicing record, whether a point-of-sale terminal and its back office form one invoicing system, or what happens when a user corrects an issued invoice.

Those are implementation questions, not cosmetic ones. Royal Decree 1007/2023 regulates the integrity, conservation, accessibility, legibility, traceability and inalterability of invoicing records. It defines an invoicing system by what the hardware and software do with invoice information, including entering, retaining and processing it. Royal Decree 1007/2023, Articles 1 and 8

A VERI*FACTU adaptation is not complete because an invoice displays a QR code or a supplier labels a product as compliant; the installed invoicing flow and the producer declaration for that version must satisfy the SIF rules. Royal Decree 1007/2023, Articles 1, 8, 9 and 13 This article examines five places where an otherwise sensible business can get that work wrong. For a primer on terminology and the two modes, read the separate guide to SIF and VERI*FACTU in Spain.

The analysis below reflects the consolidated rules and AEAT guidance available on 24 August 2026. It is not a determination that a particular product, taxpayer or transaction is in or out of scope. That classification depends on the taxpayer, territory, invoicing method and operations.

Mistake 1: accepting “compliant software” without identifying the version

A procurement question can be too broad: “Does your software comply?” A yes tells you very little. Compliance attaches to a concrete invoicing system, its version and, where relevant, the components that take part in producing and preserving invoice records.

The producer, not AEAT or an external auditor, certifies the system through a responsible declaration. That declaration must appear in writing and visibly in every version of the system and be available to the customer when the product is acquired. Royal Decree 1007/2023, Article 13 AEAT confirms that the regime is producer self-certification: there is no required independent certification process and no prior product registry. AEAT: responsible declaration, external certification and registration

That is not the same as AEAT approving the product. A supplier’s declaration is legally relevant, but the word “certified” should not be read as a government guarantee. Ask for the document and make sure it identifies the version you will deploy, the producer, the system’s composition and functions, and the date and place of signature.

Version control matters after purchase too. An update to the invoicing engine, a custom plugin, a connector or a changed back-office module can alter the system described by the declaration. AEAT’s technical guidance says that when a SIF contains two or more invoicing components, the relevant components require responsible declarations; only components irrelevant to the regulated functions fall outside that certification need. AEAT: technical FAQ for developers, pp. 12–13

Consider a shop that creates tickets at a point-of-sale terminal, sends them to a cloud service and permits corrections from a separate administration panel. Buying a “ready” till is not enough if the panel can reprocess records in a way the declaration does not cover. The technical FAQ expressly warns against issuing at the terminal without simultaneously creating the registration record or reprocessing that record later in a way that alters it. AEAT: technical FAQ for developers, p. 12

The evidence file to request

Keep a copy of the responsible declaration for the installed version. Add the contract or order, release number, enabled mode, list of invoicing components and any configuration record supplied by the vendor. If an integrator adds a module, record who produced it and whether it affects record generation, chaining, QR output, transmission, conservation or the event log.

This file does not prove that every user action will be correct. It does give the business a version-specific starting point. A screenshot of a marketing page saying “compliant” does not.

Mistake 2: planning from an obsolete deadline

Old presentations and cached articles still circulate with earlier dates. The current consolidated timetable requires in-scope Corporate Income Tax taxpayers to adapt before 1 January 2027 and the other taxpayers in Article 3.1 to have operational systems before 1 July 2027. The first group is the taxpayers within Article 3.1(a); the second includes in-scope individuals carrying on economic activities. Royal Decree 1007/2023, final provision four

The distinction is about the taxpayer category, not the billing frequency or business size. A one-person SL does not receive the freelancer date because it has one owner. Conversely, a self-employed professional does not move to the company date because they invoice large clients.

There is another date error: treating the statutory deadline as the project start. The regulation requires the system to be adapted or operational by the applicable date. A configuration that has never processed a cancellation, corrected a mistake or recovered from a failed transmission has not been tested against the business’s real work.

Work backwards from the legal date. The internal cut-off should leave time to identify every invoicing path, receive the right software release, test representative documents, train users and resolve defects before live dependence. This is an implementation recommendation, not an additional statutory deadline.

The pre-mandatory period also affects mode decisions. AEAT describes use before the applicable 2027 date as a test period and permits a taxpayer to stop test submissions and use another system while the obligation has not begun. Once the obligation applies, different permanence rules attach to an effective move into VERI*FACTU. AEAT: FAQ on the test period and mandatory dates

Mistake 3: applying an exclusion to the whole business without checking it

“We use SII” and “we only raise a few invoices” are not enough to close a scope review. Article 3 applies to specified taxpayers that use invoicing systems, even where they use them for only part of an activity. It excludes taxpayers who keep VAT records under the SII rule in Article 62.6 of the VAT Regulation. Article 4 then contains operation-specific exclusions. Royal Decree 1007/2023, Articles 3 and 4

AEAT presents a useful initial screen for businesses and professionals established in Spain: they issue invoices, do not invoice exclusively by hand, are not within SII, do not have their tax domicile in the Basque historical territories or Navarre, and do not hold an applicable non-application decision. That “four NOs” explanation is a screening tool, not a substitute for reading the taxpayer and operation rules. AEAT: who is affected by the SIF regulation

Three boundary mistakes are easy to make:

A group assumes that one entity’s SII position covers every company using the same platform. Scope is assessed for the relevant taxpayer, not the brand name above the login screen.
A business treats a taxpayer-level exclusion as if it came from one excluded operation, or treats one operation-specific exception as if it removed all other invoicing.
A mixed-territory business imports a conclusion from common territory, the Basque Country, Navarre or the Canary Islands without checking the applicable indirect-tax and regional rules.

The regulation also permits an interested person or entity to request total or partial non-application for justified sector practices, disruption risks or exceptional technical circumstances. That requires a decision by the head of AEAT’s Financial and Tax Inspection Department and may be temporary or conditional. It is not an exemption a business can grant itself because adaptation is awkward. Royal Decree 1007/2023, Article 5

Write the scope conclusion down. Identify the taxpayer, tax domicile, tax category, SII status, invoicing tools, affected activities, excluded operations and any formal decision relied upon. If the conclusion is “out of scope”, record why and when it will be revisited. Acquiring another entity, joining or leaving SII, changing territory or adding a digital invoicing tool may alter the answer.

Mistake 4: a workflow that falls between the two modes

VERI*FACTU and NO VERI*FACTU are two valid ways for an in-scope SIF to comply. They are not “full compliance” and “light compliance”.

In VERI*FACTU mode, the system sends every generated invoicing record to AEAT continuously and immediately under the prescribed conditions. In NO VERI*FACTU mode, it does not make that continuous submission, but the system must sign the records electronically and keep an event log. AEAT: the two compliance modes Every compliant SIF must still have the capacity to transmit records; AEAT says a product that can operate only as NO VERI*FACTU is not permitted because Article 8.1 requires transmission capability. AEAT: permitted SIF configurations

A risky hybrid borrows convenient pieces from each mode. It prints the VERI*FACTU wording but does not reliably transmit. During an incident it may stop transmitting and assume that the records now behave as compliant NO VERI*FACTU records, even though the local signature and event-log design was never enabled. A label or fallback toggle cannot replace the technical conditions of the chosen mode.

Once the rules apply, a taxpayer may move from NO VERI*FACTU to VERI*FACTU, but after the first effective submission must remain in VERI*FACTU at least until the end of that calendar year. AEAT: changing between VERIFACTU and NO VERIFACTU

Choose between VERI*FACTU and NO VERI*FACTU by testing transmission, continuity, local security and correction workflows rather than treating NO VERI*FACTU as the unregulated option. AEAT: the two compliance modes For VERI*FACTU, test credentials or representation, transmission failures, rejected records, queues and recovery. For NO VERI*FACTU, test signing, custody of the signing material, the event log, export and inspection access. For either mode, decide who reviews failed records, how quickly and with what evidence.

AEAT permits a taxpayer to use more than one SIF and to run different SIFs in different modes. AEAT: multiple SIFs using different modes Each SIF must remain in its own mode and cannot interleave operations into the other one: the VERI*FACTU system always transmits, while the NO VERI*FACTU system always preserves its records securely. AEAT: one mode per SIF Document which operations belong to each SIF and which record chain each system generates. A centralized SIF has a single chain, while independent SIFs chain and, where relevant, transmit separately. AEAT: record chains where a business uses more than one SIF

Mistake 5: preserving the PDF but breaking the record trail

Businesses are used to correcting the customer-facing document. The SIF rules put equal weight on the invoicing record behind it.

Article 9 requires the system to generate an initial invoicing record automatically, simultaneously with or immediately before issuing each invoice. The original invoicing record cannot be silently hidden, deleted or modified; a correction or cancellation requires at least one later record while the original remains intact. Royal Decree 1007/2023, Articles 8 and 9

AEAT’s correction guidance follows that logic. An erroneous invoicing record is corrected through a new substitute record where that procedure is appropriate, not by editing the generated record. If an issued invoice is cancelled, the system keeps the original registration record and generates a linked cancellation record; the original invoice number remains in the series. The substantive invoicing rules still determine when a corrective invoice, cancellation or another response is correct. AEAT: correcting an invoicing record AEAT: cancellation records

That exposes several bad habits:

editing a final invoice and replacing the PDF in cloud storage;
deleting a ticket and reusing its number;
importing invoices issued by another SIF into general management without retaining their invoicing records or identifying the emitting SIF and, where applicable, issuance by a third party or the recipient; AEAT: technical FAQ for developers, importing invoices, pp. 20–21
sending a PDF from one system while a later back-office batch creates or changes the regulated record; or
treating proforma documents as an unrelated stream even though they feed the invoicing system without a controlled link.

AEAT says a prefacture, draft or proforma generator must be inseparably linked to the SIF where it forms part of the invoicing process, with controls that preserve the preparatory documents in relation to the invoices or records ultimately produced. AEAT: prefactures and traceability

Test the awkward cases, not only a clean sale. Use a representative simplified invoice, full invoice, advance payment where relevant, correction, cancellation, failed submission, duplicate user action and imported marketplace transaction. Record what the user sees, what record the system creates, whether the original remains visible and how the event appears in accounting. The applicable test cases depend on the business; this list is an advisory control, not a statutory catalogue.

What the sanction figures do and do not mean

The sanction headline needs more care than it usually receives. Article 201 bis of the General Tax Act creates serious infringements for producing or marketing certain non-compliant systems and for a defined form of possession by users.

For producers and marketers, the main fixed sanction is €150,000 for each financial year in which sales occurred and for each distinct type of offending system. Failure to certify when certification is required carries €1,000 for each system marketed without the certificate. General Tax Act, Article 201 bis.1 and bis.4

For users, Article 201 bis.2 addresses possession of systems that do not meet Article 29.2(j) where they are not duly certified despite a regulatory certification requirement, or where certified devices have been altered or modified. The fixed sanction for that infringement is €50,000 for each financial year. General Tax Act, Article 201 bis.2 and bis.4

The €50,000 figure is not an automatic charge for every implementation defect: Article 201 bis defines a specific possession infringement, and AEAT says culpability must be present. A bad QR, training mistake or rejected transmission does not by itself establish every legal element. AEAT states that sanctioning producers or users must take account of culpability, at least negligence, including where code was destroyed or hacked. AEAT: integrity FAQ and culpability

Nor does keeping historical access to an old program automatically establish the possession infringement. AEAT’s condition is stricter than simply not using the old program: the business must be able to prove that it can no longer issue invoices. Uninstalling it or modifying it so that new invoices cannot be issued after a fixed date can establish that boundary. If a non-adapted system retains invoicing capability after the applicable deadline, AEAT says its possession can constitute the Article 201 bis.2 infringement, subject to assessment of the taxpayer’s conduct and responsibility. AEAT: FAQ on retaining a historic invoicing program

Other invoice, record-keeping or obstruction provisions may apply to different conduct. A penalty analysis should identify the conduct, date, responsible person, statutory provision and evidence. Quoting the largest number on a software sales page is not legal analysis.

A control file that survives a later review

A defensible implementation maps every invoice-producing component, determines the applicable scope and mode, obtains the declaration for the deployed version, tests issue and correction flows, and keeps dated evidence of the result. This sequence is an advisory control derived from the system, certification and record duties above. It is not a safe harbour from inspection or sanction. Royal Decree 1007/2023, Articles 8, 9 and 13

The file should answer these questions without relying on one employee’s memory:

Which taxpayer and operations were assessed, and what exclusions were accepted or rejected?
Which applications, tills, marketplaces, plugins and back-office modules can cause an invoice to be issued or changed?
Which versions and components do the producer declarations cover?
Which mode is active, from what date, and who owns failures or changes?
What happened in tests of issuance, corrections, cancellations and interruptions?
Where are declarations, contracts, test evidence, incident records and user instructions kept?
What event triggers a new review: an update, new sales channel, acquisition, SII change or mode change?

Article 6 keeps the taxpayer that supplies the goods or services responsible for compliance when invoicing is materially delegated to a customer or third party. Royal Decree 1007/2023, Article 6 That taxpayer responsibility is distinct from AEAT’s statement about a duly certified SIF: the taxpayer is not responsible for the system’s incorrect operation, for which AEAT attributes responsibility to the manufacturer under Article 201 bis. AEAT: certification and responsibility for invoicing systems

That is why adaptation needs tax and accounting supervision as well as a software conversation. The vendor knows its product. The business and its advisers know the taxpayer, transaction types, invoicing rules, accounting trail and evidence that should remain after an exception.

TaxFactory’s tax and accounting advisory team can review the scope and invoicing flow with the same records used for bookkeeping and returns. Start before the legal date with one sample month and every system that can issue an invoice. The useful output is a written gap list and ownership plan, not a generic compliance badge.

Frequently asked questions

When must my invoicing system comply with the SIF rules?

Corporate Income Tax taxpayers within Article 3.1(a) must have adapted systems before 1 January 2027. The other taxpayers within Article 3.1, including in-scope freelancers, must have them operational before 1 July 2027. Scope and exclusions still need to be checked for the specific taxpayer and operations. Royal Decree 1007/2023, final provision four

Does an invoicing provider need AEAT approval to say its software complies?

No external approval or prior AEAT registration is required. The producer certifies each version. Ask for the responsible declaration issued by the producer and verify that it identifies the version, components, mode and configuration that you will use. AEAT: responsible declaration

Can I switch between VERIFACTU and NO VERIFACTU whenever I want?

Before the mandatory date, AEAT treats use as a test period. Once the rules apply, a taxpayer may move from NO VERI*FACTU to VERI*FACTU, but after the first effective submission must remain in VERI*FACTU at least until the end of that calendar year. AEAT: changing modes

Is a QR code proof that my invoicing system complies?

No. The QR code is only one visible output. Compliance also concerns when records are generated, their integrity and traceability, corrections, conservation, transmission capability and the producer responsible declaration for the installed version. Royal Decree 1007/2023, Articles 8, 9 and 13

Is every non-compliant setup automatically fined €50,000?

No. Article 201 bis defines a specific serious infringement for possessing systems that fail the statutory requirements when they lack a required certification or certified devices have been altered. AEAT also says sanctioning requires culpability, at least negligence. The facts and applicable provision must be assessed before stating a penalty. General Tax Act, Article 201 bis