Who is required to comply with SII and what it means technically

• SII scope is determined by AEAT criteria, not business preference. Large taxpayers, REDEME members, VAT groups, and certain foreign businesses with Spanish VAT registrations are required to comply.
• SII is a real-time reporting obligation, not a periodic filing process. Businesses must submit structured VAT ledger records to AEAT within strict four-calendar-day deadlines.
• Compliance depends on systems and integrations. ERP, billing, and invoicing platforms must support XML generation, AEAT API connectivity, validation workflows, and audit-ready logging.
• SII and VeriFactu are different but increasingly connected. SII governs VAT ledger reporting, while VeriFactu governs invoice integrity and traceability, meaning many businesses will need operational readiness for both.

SII applies to businesses that fall within specific VAT categories defined by AEAT. It's not optional once those criteria are met. The main categories are:

• Large taxpayers with annual VAT turnover exceeding €6 million
• VAT groups registered in Spain (grupos de IVA)
• Businesses registered in REDEME (Registro de Devolución Mensual del IVA)
• Foreign businesses with a Spanish VAT number that meet the same criteria

Large taxpayer status is assessed annually by AEAT. Businesses do not self-certify. If a company exceeds the threshold, AEAT communicates the obligation directly.

REDEME membership also triggers mandatory SII participation. Businesses often join REDEME to benefit from monthly VAT refunds, but this automatically brings continuous VAT reporting obligations.

VAT groups are equally in scope because AEAT requires near real-time visibility into group-level VAT activity.

For businesses already preparing for SII and VeriFactu compliance in real-time invoicing, understanding where SII obligations begin is critical because reporting and invoicing controls increasingly overlap operationally.

Some businesses also opt into SII voluntarily. This is usually driven by operational or cash-flow considerations linked to REDEME participation rather than by reporting preference itself.

The key point is that SII scope is determined by VAT status and AEAT classification, not by whether the business believes real-time reporting is necessary.

What about foreign companies with Spanish VAT?

Foreign businesses are not excluded from SII simply because they are headquartered outside Spain.

If a nonresident company is registered for Spanish VAT and falls within one of the in-scope categories—such as exceeding the €6 million threshold, joining REDEME, or operating within a Spanish VAT group—SII obligations apply in the same way as for domestic entities.

This is where many foreign businesses run into problems. Teams often assume that because invoicing or finance operations are managed centrally outside Spain, local real-time reporting obligations do not apply. In practice, AEAT focuses on the VAT registration and reporting status attached to the Spanish activity itself.

For foreign companies, this creates additional operational complexity. Invoice data may originate in global ERP systems, shared service centres, or regional billing platforms that were not originally designed for Spanish real-time VAT reporting. This means SII readiness often depends on integration architecture and data flow, not just tax interpretation.

The obligation applies regardless of where the business is headquartered. Once the Spanish VAT entity falls within scope, SII reporting requirements become mandatory.

SII became mandatory on 1 July 2017 for businesses falling within scope. Since that date, in-scope businesses have been required to submit VAT ledger records continuously through AEAT's SII system.

There's currently no general grace period for businesses that fall within scope. Once AEAT classifies an entity as subject to SII, the obligation applies immediately within the reporting framework and deadlines defined by the regime.

For finance and IT teams, this means SII should not be treated as a future requirement. For in-scope entities, it is already an operational reporting obligation that must be supported continuously through systems, integrations, and reporting workflows.

SII is not just a reporting obligation. It's a technical integration requirement.

Businesses must be able to extract invoice data from their systems, transform it into AEAT's required XML structure, and submit it through AEAT web services within strict reporting deadlines.

At the centre of SII is API-based communication with AEAT. Systems must connect directly, or through middleware, to AEAT's web service infrastructure in order to submit VAT ledger records electronically. These submissions are not PDF invoices or documents. They're structured XML records containing transaction-level VAT data. SII operates across four main VAT ledgers:

• Issued invoices (libro de facturas expedidas)
• Received invoices (libro de facturas recibidas)
• Investment goods (bienes de inversión)
• Intra-EU operations (operaciones intracomunitarias)

Each ledger follows AEAT schema requirements. This means invoice data must comply with:

• Required XML field structures
• VAT classification rules
• Counterparty formatting requirements
• Date and sequencing logic

The reporting window is operationally demanding. Most records must be submitted within four calendar days of invoice issuance or receipt. This leaves little time for correction once errors enter the workflow.

Error handling therefore becomes critical. AEAT returns the following response codes for submitted records:

• Accepted
• Accepted with errors
• Rejected

Rejected or flagged records must be corrected and resubmitted quickly to avoid growing compliance exposure. For finance and IT teams, this creates a continuous reporting environment rather than a month-end process.

Businesses managing both SII reporting and SII vs. VeriFactu operational requirements increasingly need integrated compliance workflows because invoicing integrity and VAT reporting are becoming technically interconnected.

Auditability is also essential. All submissions, acknowledgements, corrections, and response logs must be retained in a way that supports inspection and reconciliation. Without structured logging and traceability, finance teams struggle to prove what was submitted, when, and how errors were resolved.

SII compliance depends on systems architecture as much as tax knowledge. At a minimum, businesses need an ERP, billing, or invoicing system capable of extracting transaction-level invoice data in near real time. That data must then be transformed into AEAT-compliant XML records and submitted through AEAT web services. In practice, most organisations require:

• ERP or billing systems that expose invoice data consistently
• API middleware or a compliance platform to manage AEAT connectivity
• Validation controls before submission
• Error monitoring and correction workflows
• Logging and reporting capability for audit support

This is where many businesses encounter limitations. Standard accounting software may support VAT reporting internally but not direct AEAT API submission. In many cases, systems require additional integration or a compliance layer to support continuous SII reporting properly.

Invoice data often originates across multiple systems:

• ERP platforms
• Ecommerce environments
• Shared service centres
• POS systems
• External billing tools

Without integration and validation controls, discrepancies appear quickly between accounting records and SII submissions.

This is not just a tax project. IT teams, ERP owners, finance operations, and tax teams must coordinate closely because SII compliance depends on system behaviour, integration reliability, and data quality across the entire invoicing process.

No. SII and Verifactu are related, but they are not the same obligation.

SII is a VAT reporting framework. It requires businesses to submit VAT ledger data to AEAT in near real time through structured XML records.

VeriFactu is different. It focuses on invoice integrity and anti-fraud controls inside the invoicing system itself. The requirement is not just to report invoice data, but to ensure invoices are generated, stored, corrected, and linked in a traceable, tamper-evident way.

In practice:

• SII governs reporting
• VeriFactu governs invoice generation and integrity

Many businesses will need to comply with both at the same time. This is why finance and IT teams increasingly need shared compliance architecture rather than separate reporting and invoicing processes.

SII compliance requires more than meeting a reporting obligation. Businesses need systems that can extract, validate, transmit, reconcile, and monitor VAT data continuously across the organisation.

For many organisations, invoice data sits across ERP platforms, billing systems, ecommerce environments, and shared service workflows that were not designed for near real-time reporting to the AEAT.

Avalara helps businesses operating in Spain build a scalable SII compliance model without disrupting core finance operations.

As part of our agentic AI platform for global tax and compliance, Avalara combines a certified compliance engine with AI-powered automation to help businesses improve VAT reporting accuracy, reduce manual effort, and maintain audit-ready visibility across reporting workflows. By integrating with ERP and billing systems, Avalara enables:

• Near real-time extraction and validation of invoice data
• Automated XML generation and AEAT API submission
• Continuous monitoring of accepted and rejected records
• Reconciliation between ERP and SII reporting data
• Audit-ready logging and traceability across submissions and corrections

Avalara also helps organisations prepare for overlapping SII and VeriFactu requirements by aligning reporting workflows and invoice integrity controls within a centralised compliance framework.

The result is reduced manual effort, fewer reporting errors, improved audit readiness, and greater operational control for finance and IT teams. Speak with Avalara to learn more.