Skip to content
Gradion
|Compliance Fiscal

SII AEAT for Spanish firms: scope and deadlines

Ivor Padilla

by Ivor Padilla

Co-Founder & Engineering Director

SII AEAT for Spanish firms: scope and deadlines

SII AEAT for Spanish firms: scope and deadlines

By Ivor Padilla, co-founder of Gradion · Published on 11 April 2026 · Last updated: 11 April 2026 · 10 min read

When someone inside a Spanish accountancy or tax firm searches for SII AEAT, they are usually not looking for a textbook definition of the acronym. They are trying to answer something more practical: what Spain's tax authority actually says, whether the regime applies to them, which deadline matters, and why the team always ends up chasing invoices as the 16th gets closer.

That distinction matters. SII on its own is too broad. SII AEAT points to official guidance and to a need for an operational answer. A firm needs both sides at once: the legal rule and the workflow that makes the rule sustainable.

TL;DR: the official answer behind SII AEAT is this: the SII is not about sending invoices, but about submitting the billing records that make up the VAT books. It is mandatory for monthly VAT filers, voluntary for everyone else, and the default rule is four days to submit records, with eight days in some third-party invoicing cases. Most firms do not fail on the XML. They fail in the daily exception queue before the XML.

What the AEAT actually answers when you search for SII

The first confusion to remove is the most common one. Many SII AEAT searches are really asking, "Do I have to send the invoices themselves to the tax authority?" The answer is no.

The AEAT is explicit that the SII is not about sending invoices themselves. It is about submitting the billing records that make up the VAT books. That matters because the firm's bottleneck usually sits in correctly classified tax data, not in the PDF file.

For an accountancy firm, that changes the real work. A PDF may already exist in email, in a shared drive, or inside A3. But if the tax record does not go out with the right date, the right VAT ID, the right taxable base, the right VAT amount and the right period, the problem is still alive.

That is why SII AEAT is not a document-storage question. It is a tax operations question. The firm needs to:

  • identify the transaction type
  • pin down the correct operative date
  • check VAT ID, taxable base, VAT amount and counterparty
  • decide the right period for reporting or deduction

Treat the SII as a filing cabinet problem and you will already be late. Treat it as a VAT records queue and you are looking in the right place.

Who is in scope, and who can opt in voluntarily

The next practical question behind most SII AEAT searches is direct: does this regime apply to us or not?

The AEAT's own guidance places monthly VAT filers inside the mandatory SII scope, especially large businesses, monthly refund scheme taxpayers (REDEME) and VAT groups. Everyone else can opt in voluntarily, but they then take on the same operating discipline and deadlines.

Operationally, this is the threshold firms actually care about: the AEAT treats businesses above EUR 6,010,121.04 in turnover as large businesses. If your practice manages clients at that level, the SII is already part of the monthly VAT routine.

This has a practical knock-on effect for firms. A 12-person practice with 180 recurring clients may have only 14 clients inside the SII, yet those 14 still generate a disproportionate share of invisible monthly work. They create tighter deadlines, less room for cleanup, and more damage when records are posted late.

It also helps to separate close-but-different regimes early. The SII is not the same as VERIFACTU. Nor is it the same as mandatory B2B e-invoicing. Teams that mix those three regimes usually end up solving the wrong problem first.

Which deadlines actually matter

Once scope is clear, the next question is about timing. This is where firms need precision, not fuzzy summaries.

Article 69 bis of Spain's VAT Regulations sets the deadline that actually matters in the SII: four calendar days for sales and purchase records. Where the invoice is issued by the customer or by a third party, that extends to eight days, but every submission still has to land before the 16th of the following month.

There is one practical nuance firms often miss: when counting those four- or eight-day windows, the rule excludes Saturdays, Sundays and national public holidays. It does not fix a late record, but it does affect alert timing and internal review design.

Where firms usually struggle is not the number "4" itself. It is deciding which event starts the clock:

  • issue date for sales invoices
  • accounting entry date for purchase invoices
  • customs document posting date for imports
  • dispatch or receipt date for some intra-Community transactions

That is judgement work, not just software work. Software can help block obvious mistakes, but the correct operative date is still a tax decision.

And it links directly to the modelo 303 VAT return. The SII does not replace the monthly VAT close. It exposes whether the monthly close is actually under control.

Where firms get stuck even when the law is clear

When a practice says, "We have SII problems", the problem is often not legal at all. It is organisational.

In most firms, the drag comes from a mix of four unglamorous issues:

  1. The invoice arrives late or badly. Loose email, PDF with no context, phone photo via WhatsApp.
  2. Nobody knows whether the record is ready. It sits in A3 but has not been validated; it is in Sage but not reconciled; it is in Holded but missing a key tax field.
  3. The exception lives outside the system. It gets handled by email or chat instead of in a visible queue.
  4. The team reviews in batches. Instead of closing exceptions daily, they fight them all at once as the 16th approaches.

In that kind of setup, the SII feels permanently urgent. But the urgency is not created by the AEAT. It is created by the absence of a visible queue with states and owners.

A firm already working with A3 Asesor, Sage Despachos, Holded or Contasol does not usually need to start by replacing tools. It needs to answer a simpler question first: where does the exception queue live today? If there is no queue with statuses such as pending, reviewed, sent, rejected, the team is working blind.

How to run the workflow with A3, Sage, Holded or Contasol

The encouraging part is that making SII AEAT manageable does not usually require tearing up the stack. It requires making an implicit workflow explicit.

A workable flow for a Spanish firm handling SII clients often looks like this:

  1. Controlled intake. Everything arrives through email, scan folder or client portal. Nothing should live first in someone's phone.
  2. Initial classification. Sales invoices, purchase invoices, credit notes, intra-Community movements and import records are separated from the start.
  3. Minimum validation. Nothing moves on without VAT ID, taxable base, VAT amount, transaction date and expected period.
  4. Posting in the existing system. A3, Sage, Holded or Contasol remain the working source of truth.
  5. Visible exception queue. Anything that fails goes into an assignable list instead of disappearing into inboxes.
  6. Daily reconciliation. Export, AEAT acknowledgement, review, close.

Useful automation here does not decide the tax treatment. It reduces mechanical waste.

Examples that genuinely help:

  • a rule that blocks submission if the VAT ID is missing
  • an alert where the accounting entry date and intended period do not match
  • automatic reconciliation between the daily export and the AEAT acknowledgement
  • queue assignment by client or responsible person

The technical layer is not negotiable either. Order HFP/417/2017 fixes the record fields and message format. A3, Sage, Holded or a custom integration may differ at interface level, but the payload itself is not something each firm invents.

Translated into commercial terms, the answer is not "buy another vague digital transformation project". The answer is "make the current stack behave like an orderly monthly VAT operation rather than a recurring fire drill".

Frequent mistakes when the team lives in fear of the 16th

The expensive mistakes are usually less sophisticated than people think:

  • purchase invoices posted too late
  • credit notes with no separate route
  • imports split across customs document and supplier invoice
  • clients mixing email, WhatsApp and portal uploads
  • exceptions with no clear owner

The AEAT also points to the administrative upside: taxpayers inside the SII, including those who opted in, do not file forms 347 and 390. That is a real simplification, although it does not compensate for a messy internal process.

The AEAT itself used the regime as the basis for a high-frequency indicator built on nearly 61,000 taxpayers in the SII, representing 70% of non-exempt domestic sales. That helps show the real operational weight of the system in Spain.

The lesson is simple. The SII does not punish complexity as much as it punishes fuzziness. Firms can survive with fuzzy processes under slower obligations. Under SII timing, that fuzziness turns into lost hours, rework and a damaged monthly VAT close.

Frequently asked questions about SII AEAT

Does SII AEAT mean sending invoices to the tax authority?

No. It means sending the billing records that make up the VAT books.

Are the SII and VERIFACTU the same thing?

No. VERIFACTU regulates invoicing software behaviour. The SII regulates electronic VAT book records.

Can an SME opt in voluntarily?

Yes. The AEAT allows it. The real question is whether the firm has enough operational control to support it.

What tends to fail more often: software or process?

In most firms, process. The software often knows how to emit the right format. Intake, validation and daily review are what usually fail.

Does the SII reduce admin work overall?

It removes some information returns, but it increases the need for daily discipline around records and exceptions.

Do we need to replace A3 or Sage to improve?

Usually not. It is often higher leverage to fix intake and exception handling around the existing system first.

How we are solving this at Gradion

In the flows we have reviewed, the SII bottleneck is rarely generating the XML or pressing send. It is getting to each day with the invoice already classified, posted and validated. The expensive exception is not "the AEAT rejected the submission". It is the purchase invoice that arrived late, got posted outside the right window, hit the wrong period, and forced somebody to chase the client or redo the bookkeeping.

That is why, when we work on this type of operation, we do not start with another reporting layer. We start with a daily exception queue tied to the firm's actual workflow: daily export from A3 or Sage, minimum validations on VAT ID, amount and date, visible statuses, and reconciliation against the AEAT acknowledgement. The professional still decides the tax treatment. Automation prevents the team from burning hours on predictable avoidable failures.

We are not selling "AI that runs VAT for you". We are selling fewer lost hours, better visibility and a process that can survive the 16th without last-minute heroics.


Do you want to see how this would work in your firm?

10-day pilots, fixed price, production result.

Request a demo →