Briefing document & Podcast: Spain’s VeriFactu Verified Billing System

Last update: October 25, 2025

• Geographical Scope – National vs Regional: VeriFactu applies across Spain’s common territory (mainland Spain and territories under the national tax system, with minor adaptations for Canary Islands, Ceuta, and Melilla). However, the Basque Country and Navarre are excluded from VeriFactu because these regions have their own autonomous fiscalization systems: TicketBAI (and the related Batuz program in Bizkaia) in the Basque provinces, and a similar regime planned in Navarre. In practice, all businesses with tax residency in Basque Country or Navarre follow their regional e-invoicing mandates (TicketBAI, etc.) instead of VeriFactu. VeriFactu only affects those regions in very limited cases (e.g. if a Basque-based company is taxed under the state system). In summary: VeriFactu covers the entire country except the foral regions, which have parallel anti-fraud invoice rules. [edicomgroup.com], [globalvatc…liance.com] [fiskaly.com], [fiskaly.com] [edicomgroup.com]
• Purpose and Core Requirements: The system’s goal is to eliminate “double accounting” and hidden sales by forcing the use of certified billing software that produces unalterable records of every invoice. All invoice records must remain tamper-proof (through digital signatures, hash chains, timestamps) and must be either automatically reported to the Tax Agency (AEAT) or ready for immediate inspection. Invoices will carry a QR code and a unique verification code (“Código Seguro de Verificación”) that allow tax authorities and customers to verify in real time that an invoice was properly registered. These measures, often called “fiscalization”, mirror what the Basque TicketBAI system already does regionally (requiring each invoice to be signed and, in most cases, transmitted to the regional Treasury). [edicomgroup.com], [fiskaly.com] [edicomgroup.com], [quaderno.io] [edicomgroup.com], [edicomgroup.com]
• Implementation Timeline: VeriFactu’s rollout has been phased and recently postponed to 2026 to give businesses and software developers more time to adapt. Key dates and milestones include:
  • July 2021 – Legal Mandate Established: Spain’s Anti-Fraud Law 11/2021 was enacted, introducing the legal obligation for businesses to use electronic systems that guarantee the inalterability of invoicing records. This law amended the General Tax Law (Art. 29.2.j)) to prohibit “double-use” software and paved the way for VeriFactu. [boe.es], [boe.es]
  • December 2023 – Core Regulation Issued: Royal Decree 1007/2023 (published 6 Dec 2023) – often called the “VeriFactu Regulation” – was approved to define the technical and legal requirements for billing systems and standardized invoice record formats. This regulation detailed how invoicing software must secure records and (optionally) transmit them to AEAT. Initially, it set a compliance deadline of 1 July 2025 for all affected taxpayers to have their systems ready, and it gave software developers until 9 months after a forthcoming Ministerial Order to update their products. (At that time, July 2025 was envisioned as the go-live date for businesses.) [edicomgroup.com] [grantthornton.es]
  • October 2024 – Technical Specs Published: On 28 Oct 2024, the Ministry of Finance issued Order HAC/1177/2024 which published the detailed technical, functional, and content specifications for compliant e-invoicing systems. This Ministerial Order (effective 29 Oct 2024) kicked off the official 9-month window for software providers to adapt their billing programs. In other words, by 29 July 2025 developers must release compliant versions of their software. The Tax Agency (AEAT) also committed to have its systems ready to receive invoice data by the same date. (Notably, AEAT launched the first VeriFactu online services even earlier, in April 2025, to allow testing – including web services for submitting invoice records and a portal for consulting reported bills.) [marosavat.com] [grantthornton.es] [marosavat.com], [marosavat.com]
  • April 2025 – Deadlines Postponed: Recognizing implementation delays, the government issued Royal Decree 254/2025 (published 2 Apr 2025) to extend the compliance deadlines. Under the revised timeline, large corporate taxpayers have until **1 January 2026 to comply, and smaller businesses (self-employed individuals and others not in corporate tax) until 1 July 2026. This two-stage deadline (Jan 2026 and Jul 2026) replaces the original mid-2025 date, giving an extra year. The extension was made due to the late publication of technical specifications and to ensure an orderly transition. [marosavat.com] [marosavat.com], [boe.es] [boe.es], [boe.es]
    • ➤ 1 Jan 2026: Mandatory compliance for taxpayers that pay Corporate Income Tax (i.e. most companies). This is the first wave of VeriFactu adoption. [marosavat.com], [boe.es]
    • ➤ 1 July 2026: Mandatory compliance for all remaining in-scope taxpayers, such as self-employed professionals, entrepreneurs under personal income tax, and other entities not covered by the first wave. This gives smaller businesses an additional 6 months. [marosavat.com], [boe.es]
  • Beyond 2026 – Next Phases: In the future, Spain plans to expand real-time e-invoicing and reporting further. The Tax Agency has signaled a “second phase” in which sending invoice records to AEAT will become mandatory for all taxpayers (effectively extending continuous transaction reporting across the entire economy, similar to the current SII system but for everyone). Additionally, a separate initiative under the “Crea y Crece” Law (Law 18/2022) will make B2B electronic invoicing compulsory nationally, on a similar 2026 timeline (with larger firms adopting 12 months after that law’s technical rules are finalized, and smaller firms 24 months after). Important: The VeriFactu requirements for certified invoicing complement this upcoming B2B e-invoice mandate; VeriFactu ensures the integrity and reporting of invoices, while the B2B mandate will ensure all invoices are electronic and use a standard format (e.g. Spain’s Facturae XML) for interoperability. In short, from 2026 onward Spain is implementing both: (1) VeriFactu – secure, traceable invoicing systems with optional real-time reporting to AEAT, and (2) full electronic invoicing for business transactions. These efforts together move Spain toward a fully digital, real-time VAT control system by the later 2020s. [grantthornton.es] [grantthornton.es], [globalvatc…liance.com] [quaderno.io], [globalvatc…liance.com]
• Who Must Comply (Taxable Persons in Scope): The VeriFactu regulation has a very broad scope – it applies to virtually all Spanish taxpayers who issue invoices in the common regime, with a few specific exceptions. In-scope categories include: [edicomgroup.com], [edicomgroup.com]
  • All businesses and professionals established in Spain subject to Corporate Income Tax or Personal Income Tax, provided they use any electronic/computerized invoicing system. This covers companies, self-employed entrepreneurs/freelancers, partnerships, and other entities engaged in economic activities. (For partially tax-exempt entities, it applies at least to their taxable activities.) In essence, any taxpayer that keeps digital invoicing records must ensure their software complies with VeriFactu. [edicomgroup.com], [marosavat.com] [edicomgroup.com]
  • Non-resident entities with a permanent establishment in Spain (e.g. a foreign company with a branch or fixed place of business in Spain) are also in scope for their Spanish operations. [edicomgroup.com]
  • Developers and vendors of invoicing software themselves have obligations too: they must develop and distribute software that meets the VeriFactu technical standards. (Software providers must self-certify their compliance and issue a “responsible declaration” confirming their product meets the new requirements. Since Oct 2024, the tax authority has provided official template declarations for this purpose.) [marosavat.com]
  • Geographical exclusions: As noted, taxpayers under the Basque Country or Navarre fiscal regimes are not subject to the state’s VeriFactu rules. Those regions enforce their own certified e-invoicing laws (e.g. TicketBAI). VeriFactu only applies in those regions for businesses taxed by the central government (which generally would not be the case unless by special arrangement). [fiskaly.com]
  • SII users exclusion: Taxpayers who already report all their invoices under Spain’s SII (Immediate Supply of Information) system are exempt from VeriFactu obligations. SII is the existing real-time VAT ledger reporting system (in place since 2017) required for large companies (annual turnover > €6 million) and certain other cases. Because SII already ensures these taxpayers transmit detailed invoice data within days, they are not forced to also use VeriFactu software on top. In other words, large companies on SII can continue with SII and need not adopt VeriFactu – avoiding double reporting. (One caveat: if an SII-reporting company issues invoices on behalf of a third party by mutual agreement – e.g. as a billing agent – then it must still comply with VeriFactu for those invoices. But if an SII company is doing self-billing for a supplier due to a legal mandate, that is exempt from VeriFactu.) [edicomgroup.com], [grantthornton.es] [fiskaly.com], [boe.es] [marosavat.com], [marosavat.com]
  • Other exclusions: Taxpayers not obliged to issue invoices at all under Spanish law (for certain transactions) remain out of scope as long as they truly do not issue any invoices. Likewise, foreign businesses with only a Spanish VAT number (but no permanent establishment) are not required to use VeriFactu software. Essentially, VeriFactu targets Spanish-established businesses (SMEs in particular), while large entities in existing special regimes and purely non-resident VAT payers are carved out. [marosavat.com]
• Transactions Covered (What must be invoiced and reported): All transactions for which an invoice must be issued by law are subject to the VeriFactu mandate. In practice this means every invoice or receipt generated by an in-scope taxpayer must follow the new requirements. This includes:
  • Both full invoices and simplified invoices (simplified invoices are receipts or tickets that contain reduced info). The regulation explicitly covers both types – the invoice record must indicate if it is a full or simplified invoice. For example, a cash sale in a shop that produces a sales receipt still falls under VeriFactu if the business is in scope. In the Basque Country’s TicketBAI, all sales, even those where issuance of an invoice is usually optional, must generate a TicketBAI-compliant invoice/record; the spirit of VeriFactu is similar for the rest of Spain, though if a transaction is truly exempt from invoicing requirements, the business need not create an invoice just for VeriFactu. [edicomgroup.com] [edicomgroup.com]
  • B2B and B2C transactions alike: There is no distinction – any sale of goods or services by a business, whether to another business or to a consumer, needs to be invoiced through a compliant system. The aim is comprehensive capture of economic activity, especially traditionally cash-heavy sectors. (TicketBAI, for instance, was explicitly designed to cover B2C retail and service transactions to ensure even small cash sales are recorded.) [edicomgroup.com]
  • Self-billed invoices and third-party billing: If you issue an invoice on behalf of another business (third-party billing), you generally must comply with VeriFactu (unless you’re mandated by law to do that billing and you already use SII). Conversely, if you receive a self-billed invoice (your customer issues the invoice on your behalf and they are under SII), that invoice doesn’t require your system to comply. These nuances basically prevent gaps in compliance in special invoicing arrangements. [marosavat.com]
  • Scope in Basque/Navarre vs State: A company operating in the Basque Country will invoice under TicketBAI rules (which similarly cover all invoices/receipts). If that same company has activities in common territory, it would also have to ensure VeriFactu compliance for those invoices. Generally, businesses will either follow TicketBAI (Basque/Navarre) or VeriFactu (rest of Spain) for their sales, depending on where they are fiscally established – the covered transactions are essentially “all sales” in either case. [edicomgroup.com] [fiskaly.com]
• Required Data and Invoice Content (Data to be provided): The VeriFactu regulation standardizes the content of each invoice record that must be captured (and, if using the reporting mode, sent to the tax authorities). The minimum data elements that every compliant billing system must record for each invoice include: [edicomgroup.com], [edicomgroup.com]
  • Invoice issuer identification: Tax ID number (NIF) and full name or business name of the person or entity obligated to issue the invoice. [edicomgroup.com]
  • Invoice number (and series): A sequential invoice number (with any series prefix if used) as assigned by the invoicing system. [edicomgroup.com]
  • Invoice dates: The date of invoice issuance, and if different, the date of the underlying transaction or advance payment being documented. (This captures cases where an invoice is issued later than the supply date or where prepayments are involved.) [edicomgroup.com]
  • Invoice type: An indication of the type of invoice – e.g. whether it’s a full (ordinary) invoice or a simplified invoice (ticket). (For special invoice types like credit notes or self-invoices, additional descriptors must be included per existing VAT invoice rules, but those specifics are part of the “necessary detail for correct identification” of the invoice type.) [edicomgroup.com]
  • Transaction description and amount: A general description of the transactions on the invoice (e.g. goods or services supplied), and the total amount of the invoice. (The item-level detail doesn’t all have to appear in this summary record, but key summary info is included. However, note that if using the real-time reporting mode, effectively many line-item details are conveyed via the required VAT breakdown fields below, similar to SII’s level of detail.) [edicomgroup.com] [grantthornton.es]
  • Tax regime indicators: An indication of the VAT status of the transaction – for example, whether it’s subject to standard VAT, a special VAT scheme, or outside the scope. The record must note the VAT scheme or any other tax implications of the transaction. It also must indicate if the invoice recipient is a VAT taxpayer or not (which matters for certain cross-border or domestic reverse-charge situations). [edicomgroup.com]
  • Tax base and tax amounts: The taxable amount (net amount) of the transaction, the VAT rate(s) applied, and the resulting VAT amount(s) charged. If applicable, any equivalence surcharge (recargo de equivalencia, a special surcharge for retailers under that regime) rate and amount must be included as well. Essentially, the record needs to break down the invoice’s VAT calculation. [edicomgroup.com]
  • VAT exemptions or special cases: If the transaction is exempt from VAT, the record must state the exempt amount and the reason for exemption (e.g. which article of the VAT law applies). This mirrors the normal invoice requirement to annotate the reason for VAT exemption or reverse charge on the invoice. [edicomgroup.com]
  • Timestamp: The exact date and time when the invoice record was generated in the system, down to hour, minute, and second. (This provides an audit trail to see the chronological order of invoice entries and helps ensure sequential integrity – no gaps or post-fact modifications – when combined with the hash chaining.) [edicomgroup.com]
  • Cancellation records: If an invoice is cancelled or voided (for instance, a mistake that is corrected by voiding the invoice), the system must generate a cancellation record referencing the original invoice record and providing the information necessary to invalidate/replace it. (This is similar to how a stornation or adjusted invoice would be handled – everything is tracked.) [edicomgroup.com]
  • Security elements: In addition to the content fields above, the system must apply security features to each record: it must compute a digital fingerprint/hash for each invoice record (and link of each record to the previous one’s hash to create an immutable chain) and often also an electronic signature using the software provider’s certificate. These ensure that any alteration of an invoice record after the fact would be detectable (the hashes wouldn’t match). The invoice itself must include a QR code encoding key data (like an ID and a verification code), as well as a textual reference or label indicating it was generated by a Verifiable Invoice System (often the invoice will bear the literal label “VERI*FACTU” to show compliance). For TicketBAI in the Basque region, similarly, invoices include a QR code and a unique TBAI code on the printed or electronic invoice. Under VeriFactu, the QR code allows the customer or inspector to scan and verify the invoice details on the AEAT portal instantly. (If the business is using the real-time reporting mode, the QR code can even direct to the actual record stored at AEAT; if using local mode, the QR might just encode the invoice data and a hash for verification.) [edicomgroup.com], [edicomgroup.com] [edicomgroup.com] [edicomgroup.com], [edicomgroup.com] [edicomgroup.com], [quaderno.io]
  • Standardized format: These required data fields are transmitted or stored in a standard format defined by the tax authorities. Per the October 2024 Ministerial Order, Spain has published detailed XML schemas for the “Registro de Facturación” (invoice record) that software must produce. In other words, each invoice generates an XML file/record with all the above information and security keys. This record format is broadly analogous to the data submitted in the SII system (in fact, the level of detail “is similar in detail to what is required in SII” for each invoice). If the business opts for the VeriFactu real-time submission mode, these XML records are sent automatically to AEAT’s servers; if not, they are stored locally but could be transmitted later or inspected. (See “Format of e-invoice and e-reporting” below for more on technical format.) [fiskaly.com] [grantthornton.es]
• Compliance Options – VeriFactu vs Non-VeriFactu Mode: A noteworthy aspect is that businesses have two ways to comply with the VeriFactu regulation: [edicomgroup.com], [marosavat.com]
  1. Use a “VeriFactu” system (Real-time reporting mode): This means your invoicing software is set up as a Verifiable Invoice Issuance System that automatically transmits each invoice record to the AEAT at the time of issuance. In this mode, every invoice you issue is effectively reported to the tax agency in real time (or very near real time). The invoice that you give to your customer will include a QR code and typically a phrase like “Factura verificable en la Sede Electrónica de la AEAT” (Invoice verifiable on the AEAT e-office) to indicate that it’s registered with the tax authority. The AEAT provides web services for these submissions (as of April 2025, the “web service for submission of billing records” was made available for testing). If any errors occur in the data sent (for example, a required field is wrong), the system will return an error and the invoice record must be corrected and resent. Advantages: If you operate in this mode, you do not need to implement some of the heavier security features like digital signatures on each invoice – since the data is being handed to AEAT immediately, the government server acts as a secure repository. This mode is also technically simpler to implement in software (no need for complex hash chaining logic in the software, because AEAT will ensure sequence). It provides benefits like allowing your customers to verify invoices on the AEAT portal, and it gives you an official backup of all invoices at AEAT. The tax agency also promises easier VAT compliance (like pre-filled VAT ledgers – see below) for those who use this live reporting option. [edicomgroup.com], [quaderno.io] [quaderno.io] [marosavat.com] [quaderno.io], [quaderno.io]
  2. Use a certified “SIF” system without instant transmission (Secure local mode): SIF stands for Sistema Informático de Facturación – a computerized billing system that meets all VeriFactu technical requirements but does not necessarily send each invoice to AEAT in real time. In this mode (sometimes called “non-VeriFactu option”), your software must still generate the complete invoice record with all the required fields and apply the digital signature/hash and QR code, but it can keep the records stored locally (or in your system’s cloud) instead of transmitting every one immediately. The records must be continuously numbered and unalterable in the system, and the system must be capable of giving the tax agency access to the data on demand (or potentially via periodic uploads). Essentially, this is compliance by certification: your software is “certified” as anti-tamper and you maintain an event log of all operations (startup, shutdown, edits, etc.) to prove no invoice can go missing. Advantages: This mode may be preferred by businesses that do not want to or cannot transmit data in real time (due to connectivity issues, or simply preference). It still satisfies the law by ensuring if an inspection happens, the business cannot have falsified records. However, because data isn’t automatically with AEAT, businesses in non-VeriFactu mode won’t benefit from things like pre-filled returns or immediate verification by customers. Note that the law empowers AEAT to require these stored records to be sent; indeed, the plan is a later phase will likely mandate that even these have to be uploaded regularly. For now, though, either approach is acceptable by January 2026. [edicomgroup.com], [fiskaly.com] [marosavat.com] [fiskaly.com] [edicomgroup.com] [grantthornton.es]
  In summary, businesses can either “opt-in” to real-time e-reporting (VeriFactu mode) or just use certified software that keeps the secure records (non-VeriFactu mode). Either way, the internal software requirements (fields, hashes, QR codes, etc.) are largely the same. The key difference is whether you transmit continuously or store securely and potentially transmit later. This dual approach is intended to offer flexibility and a gradual on-ramp for full real-time reporting: many companies may start with just compliant software and later shift to the live submission model as it becomes common. Spain’s approach here is layered rather than a single “clearance portal” for all invoices from day one. (By contrast, the Basque TicketBAI essentially mandates real-time or near-real-time submission for most provinces already, although Bizkaia allows batch sending via ledger books later.) [fiskaly.com] [globalvatc…liance.com] [edicomgroup.com] [edicomgroup.com], [fiskaly.com]
• Deadlines for Transmitting Data: Under VeriFactu, if you choose the real-time reporting mode, the “deadline” to send each invoice is essentially immediate – at the moment of issuance. The system is built to send the invoice record nearly instantaneously to AEAT as you finalize the invoice. This is analogous to Italy’s SdI clearance or the Basque TicketBAI: the invoice data is dispatched and a confirmation/validation is received within seconds or minutes. There is no separate periodic report needed because each invoice is handled on the fly. [quaderno.io]
  If you choose the non-transmission mode, currently there is no routine periodic submission required (outside of existing obligations like VAT returns or SII if applicable). You must, however, guarantee that all invoice records are stored sequentially and can’t be altered, and the tax authority can access them if needed. In practice, the AEAT could audit your system and pull the records, or a future regulation may require uploading them periodically (the second phase mentioned could introduce a requirement to submit these records perhaps in batches). But as of the initial implementation, the law stopped short of forcing continuous upload on everyone. The Tax Agency has indicated that eventually they envision extending mandatory submission to all invoices by all taxpayers (once VeriFactu is rolled out, turning it effectively into a universal real-time reporting system akin to SII). For now, though, sending invoice data via web service is optional – albeit incentivized. [edicomgroup.com] [grantthornton.es]
  It’s worth noting that Spain’s existing SII system (which large companies use) requires sending invoice info within 4 days. VeriFactu’s real-time mode is even faster (immediate), but again, only those opting for it will be transmitting. Basque/Navarre regional systems: In Araba and Gipuzkoa provinces, TicketBAI requires real-time or same-day transmission of each invoice’s XML to the foral tax authority (immediate upon issuance). In Bizkaia, the TicketBAI data is sent via the LROE ledger system periodically (so not each invoice in real time, but all recorded in the electronic ledgers that the taxpayer must submit regularly). Navarre is reportedly planning a system by 2026 requiring invoice submissions to its Hacienda as well. These regional timelines all conclude by 2024–2026 for full mandatory adoption, complementing the national timeline. [globalvatc…liance.com], [globalvatc…liance.com] [edicomgroup.com] [edicomgroup.com], [fiskaly.com]
• Penalties for Non-Compliance: Spain has introduced stringent penalties to enforce the VeriFactu system, targeting both the users and the makers of invoicing software. Key sanctions include:
  • Using Uncertified Software: If a business subject to VeriFactu requirements continues to use non-compliant invoicing software (e.g. “double accounting” software that isn’t certified), it faces fines of up to €50,000 per year. This is a per taxpayer penalty cap for using forbidden software. Notably, Law 11/2021 actually prohibits the mere possession of software that can falsify invoices, and this €50k fine is a direct deterrent. [quaderno.io]
  • Providing Non-Compliant Software: Software developers or vendors who sell software that does not meet the requirements (for example, failing to include the security features or allowing deletions of invoices) can be fined up to €150,000 per year, per software product. In other words, a software company could incur €150k penalties each fiscal year for each non-compliant system offered to clients. This puts significant pressure on software providers to update their systems or withdraw them from the market. [quaderno.io]
  • Invoice Manipulation or Deletion: Apart from the above general fines, the law also punishes specific fraudulent behaviors. For instance, if a taxpayer deletes an invoice or alters records in violation of the system (e.g. trying to bypass the safeguards), additional penalties apply. The core idea of VeriFactu is to prevent undeclared sales, so any attempt to game it would likely fall under general tax fraud penalties – which in Spain can be steep (for serious fraud cases, penalties can be up to 75% of the underpaid tax and even criminal charges in extreme cases). Under Basque TicketBAI, their rules set a fixed penalty of around €1,500–€3,000 per invoice that is not properly issued through the system (approximately €2,000 per missing or falsified invoice record), and that fine can apply both to the business and the software provider. The State system (VeriFactu) doesn’t use a per-invoice fine model; it uses the lump-sum €50k/€150k approach to penalize systematic non-compliance. [globalvatc…liance.com] [fiskaly.com] [quaderno.io]
  • Late adoption: Given the deadlines have been extended to 2026, businesses are expected to comply by then. If a company fails to adapt its invoicing system by the required date, it would likely fall under the above “using non-compliant software” fine (up to €50k). Software companies that miss the July 2025 adaptation deadline similarly risk the €150k fine.
  These penalties underscore that Spain is treating compliant e-invoicing software as a formal obligation, not just a best practice. The tax authorities have explicitly prioritized eliminating “double-use” software (programs that allow parallel books or selective deletion of sales). In fact, since October 2021 it’s already illegal to produce or sell such fraudulent software in Spain – VeriFactu now provides the framework to certify which software is acceptable. By imposing potential six-figure fines, the law incentivizes all software vendors to certify their products and all businesses to upgrade in time. The penalty exemptions (as mentioned, SII users are exempted from VeriFactu obligations) are meant to avoid double penalty – e.g. a large company already doing real-time reporting will not be penalized for not using VeriFactu on top. [edicomgroup.com] [grantthornton.es]
• Format of the E-Invoice and E-Reporting: Spain’s system distinguishes between the invoice itself (which must be in an approved electronic format when e-invoicing is mandated) and the invoice record data (the information sent or stored for tax purposes). Here’s how formats are defined and used:
  • E-Invoice Format: Spain’s official e-invoice format is Facturae, an XML schema used for electronic invoices. Since 2015, all B2G invoices (invoices to the public administration) must be in Facturae format and sent through the government’s FACe platform. The upcoming B2B e-invoicing mandate (Law 18/2022) is expected to also require using a structured format like Facturae (or possibly PEPPOL/UBL for interoperability) for all business invoices. In the Basque TicketBAI system, electronic invoices can be in Facturae XML or EDIFACT format, provided they incorporate the required TicketBAI codes in the specified fields. For example, a TicketBAI-compliant invoice in Facturae format includes the TicketBAI ID and QR within the XML, and one in EDIFACT includes the ID in an FTX segment. We can infer that under VeriFactu, businesses will likewise use standard formats (Facturae XML, etc.) for the invoices they issue to customers, especially once B2B e-invoicing is mandatory. The key addition is that those invoices (whether PDF, XML, or paper printouts given to customers) must contain the QR code and VeriFactu reference to show compliance. So the format of the invoice file might be Facturae, but it will be extended with a VeriFactu QR code (if printed, the QR appears on the invoice, and if purely electronic, the QR data and verification code are part of the digital representation). Spain has indicated that Facturae will be adapted to accommodate these new data points. (In summary, Facturae XML is the primary e-invoice format, and VeriFactu doesn’t replace that – it adds security and reporting on top of it. In fact, VeriFactu is meant to work alongside the broader e-invoicing initiative, not to replace the need for structured invoices.) [globalvatc…liance.com] [edicomgroup.com] [edicomgroup.com] [quaderno.io]
  • E-Reporting Format (Invoice record format): The invoice record that gets reported (or stored) under VeriFactu is structured in a specific electronic format prescribed by AEAT. Per the technical regulations, each invoice’s data is compiled into a “Registro de Facturación” XML file containing all the fields listed earlier (issuer, amount, tax breakdown, etc.) plus the security fields (hash, timestamps, etc.). This XML is what is transmitted via web service to the tax agency for those using the VeriFactu mode. If the business uses the AEAT’s free invoicing application, that app will generate and send these records in the correct format automatically. The format for VeriFactu invoice records is standardized by Order HAC/1177/2024, ensuring all software speaks the same language when sending data to AEAT. It’s conceptually similar to the SII XML format (which is basically an XML of invoice data as well). The contents of the XML record are essentially the fields enumerated above (customer and supplier info, dates, amounts, tax details), and it also includes the hash of the previous record (to maintain an unbroken chain per taxpayer) and the digital signature if in non-real-time mode. In VeriFactu’s design, each taxpayer will have one continuous sequence of invoice records (regardless of how many series they use on their invoices), which is enforced by chaining the records cryptographically. [fiskaly.com] [sede.agenc…ria.gob.es] [fiskaly.com], [fiskaly.com]
  • Verification codes and IDs: When an invoice record is submitted to AEAT, the system generates a Secure Verification Code (CSV) unique to that record. This CSV is stored and can be used to look up the invoice on the tax authority’s system. The QR code on the invoice often encodes a URL or reference including this CSV, so that scanning it will pull up the data from AEAT’s website for verification. If an invoice is not submitted (non-VeriFactu mode), the QR might contain a hash or code that the tax authority can later verify by comparing with the taxpayer’s records. In all cases, the format of these codes and QR follows the specs in the regulation – ensuring every invoice nationwide has a standardized way for verification. [quaderno.io]
  • Summary: An in-scope business will be dealing with two types of electronic records: (1) the invoice document itself (which could be an XML, PDF, etc., but by 2026 will likely need to be a structured e-invoice like Facturae for B2B transactions), and (2) the VeriFactu invoice record (XML) that is generated for tax compliance. The latter is either sent to AEAT immediately or stored securely for potential submission. Both contain largely the same financial data, but the VeriFactu record has extra audit fields. Spain’s choice of format is an open XML schema (not a proprietary format), aligning with EU standards and making it easier to integrate with other systems. Developers have guidelines to implement these formats from the official documentation (the AEAT has published extensive technical documentation, XSD schemas, and even a test platform (PRE-Exteriores) for VeriFactu submissions).
• Pre-filled VAT Returns (Tax Return Facilitation): One significant benefit of the VeriFactu system – especially when using the real-time reporting option – is that it enables the tax authority to pre-populate VAT ledgers and potentially VAT returns for taxpayers. Because the AEAT will receive detailed invoice-by-invoice data (similar to SII but for all businesses), it can use that information to help prepare the taxpayer’s periodic declarations. In fact, a stated objective of the VeriFactu project is to “enhance the assistance services offered by the Tax Agency to taxpayers by enabling the download of [recorded] transactions… and facilitate the preparation of VAT books and tax returns.”. [marosavat.com]
  Concretely, the AEAT’s online system will allow a business to view and download all their submitted invoices (sales and purchases, if both sides report). This makes it easier to compile VAT input/output totals. Spanish tax authorities have experimented with pre-filled VAT returns for SII users, and a similar approach is expected with VeriFactu. For example, if all your sales invoices are in AEAT’s database (via VeriFactu) and your purchase invoices are reported by your suppliers (via their VeriFactu or SII), the AEAT could pre-fill your VAT return form with the figures they already have. Quaderno (a Spanish tax tech firm) notes that “using pre-filled data optimizes tax return workflows, minimizing errors and reducing the administrative burden”. In essence, businesses that fully digitalize and report will spend less time on manual VAT calculations, and audits can be reduced (since the data is already verified). [marosavat.com] [quaderno.io]
  In the Basque Country’s Batuz system (Biscay), this concept is already in practice: the provincial treasury uses the TicketBAI invoice data and the required ledgers (LROE) to generate draft VAT returns (and even income tax and corporate tax drafts) for taxpayers. The taxpayer can then simply review and confirm the pre-drafted return if it matches their records, vastly simplifying compliance. Spain’s AEAT is heading in the same direction – VeriFactu lays the groundwork for pre-filled VAT registers and eventually “VAT IN” and “VAT OUT” summaries for each taxpayer. While as of 2025 Spain hasn’t rolled out universal pre-filled VAT declarations for all businesses, those using SII or VeriFactu effectively get a head-start: all their invoice data is in the system, and the AEAT provides tools to utilize it. [edicomgroup.com]
  In summary, yes – pre-filled VAT returns (or at least pre-populated VAT data) are a planned benefit of VeriFactu. Taxpayers who opt for real-time invoice submissions will have the ability to download or directly use their precompiled VAT books from the tax office’s portal, making it much easier to file VAT returns. This improves accuracy and reduces the chance of omissions, thereby benefiting both the taxpayer and the tax authority. The push for pre-filled returns is part of the broader strategy to modernize tax administration (similar to what Italy and France are also moving towards with e-invoicing data). Spain is effectively moving compliance “upstream” – by the time the VAT return is due, all invoice data is already in the system, so the return becomes almost a formality. [marosavat.com]
• Links to Key Regulations and Official Resources: For further reference and verification, here are direct links to the main legal texts and official info:
  • Law 11/2021, of 9 July 2021 (Anti-Fraud Law): This law amended the General Tax Law to introduce the requirement for tamper-proof invoicing systems. (BOE reference: BOE-A-2021-11473). [boe.es], [boe.es]
  • Royal Decree 1007/2023, of 5 December 2023: Established the Regulation on requirements for invoicing software and standardized invoice record format – essentially the VeriFactu technical regulation. (BOE reference: BOE-A-2023-24840.) [edicomgroup.com]
  • Order HAC/1177/2024, of 17 October 2024: The Ministerial Order detailing technical, functional, and content specifications for billing systems under VeriFactu. (BOE reference: BOE-A-2024-22138.) This includes schema definitions for invoice data. [marosavat.com]
  • Royal Decree 254/2025, of 1 April 2025: Modified RD 1007/2023 to extend deadlines and refine scope (postponing enforcement to 2026 and clarifying SII exemptions). (BOE reference: BOE-A-2025-6600.) [boe.es], [boe.es] [boe.es]
  • Basque Country TicketBAI Laws: TicketBAI is implemented via provincial regulations (Normas Forales in Álava, Gipuzkoa, and Bizkaia, and associated decrees). For example, Bizkaia’s Norma Foral 2/2020 and Orden Foral 148/2021 set out Batuz/TicketBAI obligations, with the final compliance calendar extending to 2026. (See official sites like Bizkaia’s Hacienda Foral and the Basque Government’s TicketBAI portal for specifics.) [edicomgroup.com], [fiskaly.com]
  • AEAT Official Portal for VeriFactu: The Spanish Tax Agency has a dedicated page “Sistemas Informáticos de Facturación (SIF) y VERI*FACTU” with general information, technical guidance, FAQs, a free invoicing app, and the electronic services for VeriFactu. This is a primary resource for businesses and software developers navigating the implementation. [sede.agenc…ria.gob.es]
  • AEAT Announcement (28 Oct 2024): “Ministerial Order regulating the Billing and VERIFACTU Computer Systems”* – official news release summarizing Order HAC/1177/2024 and its implications.
  • Spanish Government’s Digital Toolkit: Additional context can be found in government publications about the “Crea y Crece” law for e-invoicing (Law 18/2022) and the “Immediate Supply of Information (SII)” system for VAT, to see how VeriFactu fits into Spain’s overall VAT digitization strategy. [globalvatc…liance.com], [globalvatc…liance.com]

Other newsletters on Verifactu

• VATupdate.com

• See also
  • E-Invoicing/Real Time Reporting – What can you find on VATupdate.com
  • Worldwide Upcoming E-Invoicing mandates, implementations and changes – Chronological
  • Collection of E-Invoicing Guides – Worldwide – VATupdate
  • Briefing / Comprehensive Guides (incl. podcasts)

• Join the Linkedin Group on Global E-Invoicing/E-Reporting/SAF-T Developments, click HERE