# Spain: separate B2B e-invoicing, SIF/VERI*FACTU and SII Start a Spanish invoicing project with three questions: how must the invoice reach the customer, what must the issuing system record, and what VAT-ledger information must the taxpayer submit? These questions lead to different scope decisions and outputs. A product described as "VERI*FACTU ready" does not answer all three. **Diagram:** Keep the three Spanish invoicing workstreams distinct. Conceptual distinction only. Check each regime's enacted scope, effective dates and current technical rules independently. This guide builds an operating process from a dated legal assessment through transaction reconciliation. It includes the legal-status distinction visible on **17 October 2026**, when a proposed SIF timetable alignment must be kept separate from the dates in the consolidated regulation. Use the [Spain applicability and evidence worksheet](#template) to preserve that distinction. ## Identify the three requirements **B2B electronic invoicing** addresses electronic invoices between the businesses/professionals covered by the framework, including exchange and status obligations. Its 2026 implementing regulation and public-solution order are separate instruments from the invoicing-system regulation. [BOE: Royal Decree 238/2026](https://www.boe.es/buscar/doc.php?id=BOE-A-2026-7295), [BOE: Order HAC/1028/2026](https://www.boe.es/diario_boe/txt.php?id=BOE-A-2026-20587). **SIF**, *sistemas informáticos de facturación*, concerns the records and safeguards of covered invoicing systems. VERI*FACTU is one compliant mode within that framework, not the name of every Spanish invoice obligation. **SII**, *Suministro Inmediato de Información*, concerns VAT-ledger information supplied through AEAT. It is not delivery of the commercial invoice to its customer. [BOE: Royal Decree 1007/2023](https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840), [AEAT: SII overview](https://sede.agenciatributaria.gob.es/Sede/iva/suministro-inmediato-informacion/informacion-general.html). Give the three outputs separate names in requirements, demonstrations and support tickets. Ask whether a response concerns invoice exchange, an invoicing record or a VAT-ledger submission. Otherwise an operator can mistake success in one service for completion of the entire transaction. ## Keep the verified calendar and the announcement separate AEAT says Order HAC/1028/2026 entered into force on **6 October 2026**, starting the B2B timetable. It identifies **6 October 2027** for issuance/reception by businesses whose previous-calendar-year VAT turnover exceeds **EUR 8 million**, and **6 October 2028** for the remainder. Its status/payment timetable separates remaining legal persons/entities in 2028 from remaining individuals and income-attribution entities in 2029. The first large-business year also includes a readable PDF accompaniment requirement. [AEAT: B2B implementation calendar](https://sede.agenciatributaria.gob.es/Sede/iva/factura-electronica/calendario-implantacion.html). The consolidated RD 1007/2023 text inspected for this guide still states systems must be adapted **before 1 January 2027** for Article 3.1(a) taxpayers and **before 1 July 2027** for the remaining Article 3.1 taxpayers. BOE labels consolidated text informative; inspect the underlying amendment when approving the legal conclusion. [BOE: final provision four](https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840). The Ministry's **5 October 2026** notice announces intended alignment of outstanding SIF obligations with **October 2028** and refers to the alignment being approved. The notice alone does not enact that change. This research did not establish a subsequently published amending instrument replacing the inspected dates. [Ministry of Finance: proposed alignment notice](https://www.hacienda.gob.es/sgt/gabsehacienda/nota-informativa-verifactu.pdf). Record a current-law check as a release condition. The tax owner should reopen the BOE regulation, inspect amendment history and confirm the controlling instrument immediately before scheduling the live obligation. Procurement can plan for an announced change, but should not remove an earlier legal milestone solely because a news notice promises postponement. Maintain separate fields for publication date, entry into force, obligation date, affected population and status: enacted, announced or technical release. Update the affected decision and test plan when a binding change is confirmed; retain the earlier assessment as history. This is especially useful when a supplier offers one date for every customer. ## Decide applicability for the actual taxpayer Start with the legal person, tax residence, common/foral jurisdiction, corporate/individual status, activities and issuing systems. Record whether the taxpayer is included in SII, either compulsorily or voluntarily, and the effective date of that inclusion. Ask which establishment issues the invoice and whose invoicing obligations are being performed. AEAT's SIF guidance excludes taxpayers subject to its SII VAT-ledger obligation from the SIF regime and distinguishes the common-territory scope from Basque Country/Navarre residence. Foral systems and unusual self-billing arrangements need their own assessment rather than automatic reuse of the common-territory example below. [AEAT: who is covered and which operations are included](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/cuestiones-generales/quienes-estan-obligados-que-operaciones-incluyen.html). Have tax approve a decision for each regime, with an included/excluded reason and effective date. One exclusion does not settle the other two decisions. A business excluded from SIF because it uses SII still needs an independent B2B invoice-exchange assessment. Inventory every invoicing source: ERP, point of sale, specialist billing, expense recharges and documents issued on behalf of another party. Count populations and amounts before designing connectors. A system overlooked in discovery can remain outside the compliance change even while the main ERP passes its tests. ## Choose the SIF operating mode where applicable AEAT describes two valid modes. **VERI*FACTU** remits invoicing records immediately after generation. **NO VERI*FACTU** does not require that routine remittance but has additional security requirements, including signature and an event register. Both include a QR code under the described framework; QR appearance alone does not identify identical reporting behaviour. [AEAT: SIF compliance modes](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/cuestiones-generales/modalidades-cumplimiento-obligaciones.html). Choose the mode explicitly for the taxpayer and proposed product. For VERI*FACTU, test record generation, submission, response capture and interrupted communication. For the alternative mode, test the actual integrity, event and retention controls required by the chosen implementation. "We do not send automatically" is an incomplete description of NO VERI*FACTU compliance. Ask the producer for the **declaración responsable** covering the supplied system/version and relevant extensions. AEAT provides specific guidance on that producer declaration. Treat it as evidence about the specified product, not a tax-authority endorsement of the business's complete configuration. [AEAT: system certification and producer declaration](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/certificacion-sistemas-informaticos-declaracion-responsable.html). The integration owner should document which component generates the legal record, how identifiers and sequence relationships are preserved, which changes produce further records and how evidence can be exported. Freeze and approve that design before running high-volume invoice batches. ## Trace a synthetic invoice through the applicable lanes Assume Empresa Ejemplo SL is a common-territory corporate taxpayer, independently confirmed outside SII and within SIF. Its project selects VERI*FACTU. For a future B2B acceptance scenario, assume its prior-year turnover places it in the October 2028 exchange phase. This scenario's later date is not presented as a legal postponement of its SIF obligations. The company sells a domestic business service for **EUR 1,000 net plus an illustrative 21% VAT**, total **EUR 1,210**. There is one invoice, ES-100. The tax adviser has approved the simple standard-rate treatment; there are no discounts, reverse charge, partial exemptions or foreign-currency complications. AR approves the invoice and its recipient. The SIF component generates the applicable record in the approved mode and the operating process preserves its identity and response. The B2B exchange test uses the electronic invoice and actual platform/public-solution integration selected for that later obligation. The SII lane is marked excluded with the approved reason; no dummy SII submission is created to make all three lanes look active. The customer disputes part of the supply. Under the example's approved correction process, the seller issues a credit for **EUR 100 net and EUR 21 VAT**, total **EUR 121**, linked to ES-100. The remaining balance is **EUR 1,089**, comprising **EUR 900 net and EUR 189 VAT**. Preserve the original and credit as related documents and apply the correct record/correction process in each applicable lane. For payment testing, assume a receipt of EUR 1,089 fully settles that remaining balance. Preserve the payment date and original invoice relationship for any applicable B2B status obligations. Do not treat the existence of a bank receipt as proof that a status message was accepted, and do not assume this article's arithmetic defines the statutory content or deadline for every payment-status message. At close, the controller expects one EUR 1,210 original, one EUR 121 credit and a EUR 1,089 commercial balance settled by the receipt. The applicable electronic/record processes must explain both documents and their outcomes. Their counts need not match a bank statement containing only the net receipt. ## Run a separate SII variant Now change the facts: another Spanish taxpayer is properly included in SII. Keep that entity and its decisions separate from Empresa Ejemplo SL. Its finance team designs the required issued/received VAT-ledger information process and verifies its B2B exchange obligations independently. Under the cited exclusion, it does not add SIF records simply because the first example used them. AEAT describes SII as electronic maintenance of VAT books from invoice-record detail. Timing depends on record type and applicable rules; configure the current detailed calendar rather than converting the overview's general four-day description into a universal rule. [AEAT: SII system overview](https://sede.agenciatributaria.gob.es/Sede/iva/suministro-inmediato-informacion/informacion-general.html). The SII owner should reconcile the ledger population, original references, corrections and accepted responses to accounting. The invoice-exchange owner separately verifies delivery and relevant status information. Even when the same ERP supplies both, response identifiers and failed-item queues need to remain distinguishable. ## Recover failures and control changes Suppose the invoice reached the customer but an applicable record submission returned an error. AR should see that commercial delivery succeeded while the reporting/record task remains open. Correct the failed task using the documented procedure and preserve its link to the original. Do not issue another commercial invoice solely to obtain a fresh technical response. For a timeout, query the existing attempt or follow the verified connector recovery process before retrying. Identify whether the result is unknown, explicitly rejected or accepted with a warning. Store original messages; a simplified dashboard label should not discard the evidence needed to make that decision. Test credits, cancelled attempts, incorrect recipient data, changes of accounting period and interrupted connections. Test the chosen NO VERI*FACTU controls separately if that is the actual mode. Re-run only affected scenarios when a binding timetable, scope or technical amendment changes the implementation. ## Ownership and ready checklist Tax owns the applicability and legal-calendar record. AR/AP own invoice and correction populations. Treasury owns payment evidence. Integration owns mappings, transport and response capture. The software producer supplies its declaration and product documentation. The controller approves reconciliation and the business's readiness decision. - ☐ Each taxpayer has separate B2B, SIF and SII conclusions with sources and effective dates. - ☐ Common-territory and foral cases have been assessed correctly. - ☐ The latest BOE amendment history has been checked before accepting the implementation calendar. - ☐ The October 2028 SIF announcement is labelled as proposed unless a binding amendment is established. - ☐ The selected SIF mode and exact product/version declaration are documented where applicable. - ☐ Every invoicing source is included in discovery and reconciliation. - ☐ Invoice, record, ledger and payment-status results have distinct evidence and exception owners. - ☐ The original/credit worked example and an ambiguous-timeout recovery pass without duplicate sales. - ☐ The controller can explain count, amount, timing and scope differences across applicable outputs. Use [mapping tax and reporting obligations](https://erplocalization.com/guides/map-tax-and-reporting-obligations/) for the overall output inventory and [localization change management](https://erplocalization.com/guides/localization-change-management/) to maintain the dated legal decisions. Complete the worksheet for the actual taxpayer before approving a supplier's broad "Spain compliant" claim. ## Worksheet: Spain three-regime decision and evidence record Copy this worksheet for each case. It records decisions and evidence; it does not determine the tax or legal treatment. Show the worksheet Use with [the Spain guide](https://erplocalization.com/guides/spain-invoicing-sif-verifactu-sii/). Complete one scope record per taxpayer and repeat transaction blocks as necessary. Blanks are intended inputs, not missing research. ### Taxpayer facts - Legal name, NIF and establishments: - Residence and common/foral jurisdiction: - Corporate/individual/other taxpayer category: - Prior-calendar-year VAT turnover, year and evidence: - SII inclusion: compulsory/voluntary/excluded; effective date and evidence: - Activities, special regimes and self-billing arrangements: - Invoicing systems and source populations: - Tax reviewer and approval date: ### Separate regime decisions For each of B2B exchange/status, SIF and SII, record: - Included / excluded / separately reviewed population: - Exact reason, legal provision and authority guidance: - Publication / entry-into-force / obligation dates: - Scope effective date and reassessment trigger: - Proposed changes tracked separately from enacted rules: - Output, system, owner and acceptance evidence: ### Current-law release check - BOE instrument and consolidated amendment-history check date: - Underlying controlling amendment inspected: - Any proposed change and its source: - Has a binding amendment been established? Evidence: - Approved operational calendar and tax-owner signature: The 17 October 2026 guide inspected 2027 SIF dates in RD 1007/2023 and a separate notice proposing October 2028 alignment. Replace this dated assessment only with verified current evidence. ### System and transaction trace - SIF applicability and selected VERI*FACTU/NO VERI*FACTU mode: - Producer, exact version, extensions and declaración responsable: - Invoice source/ID, date, parties, net/VAT/gross: - Original/credit relationship and commercial balance: - B2B exchange/status submission and original response: - SIF record/submission and original response, if applicable: - SII ledger record/submission and original response, if applicable: - Payment evidence and applicable status outcome: - Excluded lane and approved reason: - Retry/correction identifiers and final result: ### Worked expectations and acceptance - Original illustrative invoice: EUR 1,000 net + EUR 210 VAT = EUR 1,210: - Linked credit: EUR 100 net + EUR 21 VAT = EUR 121: - Remaining balance: EUR 900 net + EUR 189 VAT = EUR 1,089: - Actual results, counts and differences: - Rejection and ambiguous-timeout recovery evidence: - Mode-specific integrity/retention tests, if applicable: - Source populations reconciled to applicable accepted outputs: - Outstanding exceptions, owner and decision: - Controller approval and evidence location: The worked amounts assume one illustrative 21% rate and an approved credit scenario. Confirm actual transaction treatment separately. **Sources checked:** 17 October 2026. The legal-status assessment is deliberately dated. This guide establishes the inspected B2B calendar and the distinction between the SIF consolidated dates and the Ministry's planned alignment; it does not establish an enacted October 2028 SIF amendment. Recheck the current BOE text before publication or operational reliance. ## Related on this site - [Country pages](https://erplocalization.com/countries/): key facts with sources - [E-invoicing matrix](https://erplocalization.com/e-invoicing/): country × ERP support - [All guides](https://erplocalization.com/guides/) Vendor documentation is cited only as an example of the level of evidence to ask for; it is not a recommendation or a ranking. This guide is general information, not tax or legal advice. Checked 2026-10-17. Related: [Glossary](https://erplocalization.com/glossary/) – abbreviations and terms used in these guides (SAF-T, Peppol, CTC, EN 16931, IFRS and more). --- Canonical: https://erplocalization.com/guides/spain-invoicing-sif-verifactu-sii/ · Last updated: 2026-10-17 · Informational only; not tax, legal or implementation advice. Featured placements are paid or promotional and do not affect the compliance data. Data: CC BY-NC 4.0 (commercial use needs a licence: https://erplocalization.com/data-licence/), attribution "ERP Localization (erplocalization.com)".