Spain Payment Platform Compliance: VeriFactu, SII, LSSI, and Evidence-First Controls

Separate Spain compliance into verified lanes#

Compliance for a payment platform operating in Spain works best when you treat it as separate lanes, not one combined project. For teams handling contractor, seller, or creator payouts linked to Spain, a practical split is a confirmed invoicing lane (VeriFactu/SII) plus still-unverified lanes, such as LSSI-related website obligations and broader payment-reporting expectations. Validate each lane on its own legal basis before you hard-code controls.

The evidence behind those lanes is uneven. Here, the most concrete operational detail sits in invoicing. VeriFactu is presented as a certified e-invoicing framework focused on authenticity, traceability, and immutability of invoice records, with the stated goal of preventing manipulation or destruction of invoicing data. Claims about broader platform-reporting or website obligations should stay provisional until you confirm them in primary legal or regulator sources.

The clearest invoicing checkpoint here is the VeriFactu and SII interaction. The cited material says entities under SII, Spain's real-time electronic VAT reporting system, are exempt from VeriFactu invoicing requirements. It also describes SII reporting within four calendar days and cites a €6 million turnover trigger for mandatory SII scope. That same material also lists January 2026 rollout timing, with 1 January 2026 and 1 July 2026 milestones for different taxpayer groups. Verify those dates against primary AEAT or BOE publications before you make final implementation decisions.

For execution, start with evidence-first controls you can actually test. The material points to QR code generation and the VERI*FACTU invoice label as visible checkpoints, alongside software and audit-trail controls that support record integrity. This guide is built for operators who need defensible records, so your first-pass evidence pack should include:

• a legal-entity and role map for each Spain-linked payer, platform, merchant, branch, or establishment
• confirmed status on whether each relevant entity is in SII and therefore exempt from VeriFactu invoicing requirements
• sample invoices, software capability evidence, and edit and retention control records

If one lane is still uncertain, do not freeze the others. Move forward on verified requirements, document open interpretations, and escalate legal questions before assumptions turn into product or policy.

For audit-trail design, see Internal Payment Audit Trail for Platform Compliance.

Start with the compliance perimeter and shared vocabulary#

Fix the vocabulary and lane boundaries before you change controls. Teams often overbuild when they treat website rules, payments oversight, and invoicing as one requirement.

LSSI is the strongest anchor in this section: Law 34/2002 of 11 July 2002 published in BOE No. 166 of 12 July 2002. Use article-level checkpoints, not generic labels:

• Article 10: general information
• Article 20: required information about commercial communications
• Articles 38 and 39: infringements and sanctions

Keep VeriFactu and Billing Information Systems (SIF) in your map, but only as provisional labels at this stage. The material provided here does not include the legal text needed to define either one precisely, so mark their requirements as pending source confirmation.

Use regulator names with the same discipline. In the material reviewed, BdE appears as shorthand for Banco de España in the IMF glossary context. For AEAT references, do not assign obligations from this section alone. Log them only after the relevant primary tax source is in your file.

Keep actor mapping explicit. PSPs, platform operators, and merchants should remain separate control owners until legal allocation is confirmed. Also treat PSD2 industry guidance as non-binding input, not law. The EBF text says it is not legal advice and that compliance interpretation sits with national authorities and courts. This guide is an operator control model, not a substitute for Spain-specific legal counsel.

Related: Music Royalty Tax Compliance: How Platforms Handle 1099-MISC vs. 1099-NEC for Artist Payments.

Build a known versus unknown matrix before changing systems#

Do not change systems until you know which claims are grounded and which are still assumptions. Build a matrix first, tag the evidence quality, and only then decide what to implement.

For each row, record the document name, URL, capture date, and whether it is primary legal text seen or secondary summary only. If a claim rests on secondary-only material, keep implementation reversible and evidence-focused, not irreversible product-policy enforcement.

If a cited source is clearly outside Spain or outside the reporting lane, downgrade the claim immediately. That keeps uncertain reporting claims from blocking higher-confidence control work.

For a step-by-step walkthrough, see How to Build a Compliance Operations Team for a Scaling Payment Platform.

Map LSSI to platform decisions that teams actually make#

Treat unclear LSSI applicability as a legal escalation item, then use baseline disclosure hygiene on payment-adjacent surfaces as a reversible control. The mistake to avoid is letting LSSI become a catch-all for every Spain payments question.

Teams should not merge website duties and payment-rail duties into one backlog. When those lanes get mixed, ownership blurs and controls get built from the wrong evidence.

Start with a scope test, not a product build#

Before writing requirements, log three facts for each Spain-facing flow. If the source is still secondary summary only, keep controls reversible and escalate scope interpretation to legal:

• which legal entity operates the surface
• whether the surface is part of a commercial activity, sign-up, offer, acceptance, or account or payment interaction
• whether the LSSI claim comes from primary legal text or only a secondary summary

Separate interface controls from PSD2 claims#

Use a simple working split while legal validates scope. Treat page content, ownership, and access to legal or support information as potential LSSI-side questions, and treat payment execution, authentication, rail behavior, and PSP obligations as PSD2-side questions.

The PSD2 item in this pack is only a download artifact: 2022-psd2-review-responses.zip, with psd2-review-responses-2022.xls referenced. Until the underlying file is reviewed and logged with URL, capture date, and what was read, do not derive controls from it.

Treat blogs as prompts, not authority#

The Didomi excerpt is plainly commercial blog content, with references such as Go to a category, Preference Center, and privacy or newsletter processing text saying Didomi collects your personal data in order to respond to your request. That is not regulator-issued LSSI wording or PSD2 legal text. Use blog material to generate questions, not to set binding requirements.

Set ownership and risk scoring carefully#

Make ownership explicit: legal interprets LSSI scope and requirement statements; product owns surface inventory and page-level implementation hygiene; compliance owns evidence capture and review records.

If penalties or enforcement ranges come from market summaries, mark them needs legal validation before using them in risk scoring. You can still score disclosure-hygiene risk now without unverified fine figures.

For cross-border launch planning, compare How to Expand Your Subscription Platform to Europe: Payment Methods Tax and Compliance.

Translate VeriFactu and SIF obligations into an implementation plan#

Once interface duties are ring-fenced, invoicing becomes the cleaner operational problem. Start with classification, not APIs: identify which Spain-facing billing components qualify as a Sistema Informatico de Facturacion (SIF), because that decision drives the rest of the implementation.

SIF in this context is software that issues invoices and preserves billing information. The practical question is whether a system that produces or preserves invoices can show exactly what it generated, stored, and exported.

If any timeline or sequencing detail comes from unofficial publication formats, verify it against an official legal edition before encoding it in product logic.

What SIF changes in practice#

Once a component is treated as SIF, the question shifts from "can we issue an invoice" to "can we show the invoice-record history." The grounded technical themes are digital fingerprinting, invoice chaining, QR generation, and possible AEAT data transmission.

Two practical checkpoints from the source context also help:

• Review all customer-facing billing outputs, not only formal invoices.
• Test whether transaction data is durably stored beyond display-level rendering.

How AEAT submission paths affect architecture#

The source context supports possible AEAT transmission, but not one binding architecture. Choose a model based on where invoice creation and preservation actually happen, then validate it with legal and tax.

• If your platform creates and preserves invoice records, direct integration may be appropriate.
• If an ERP or invoicing product is the SIF boundary, feed structured data into it and avoid creating competing invoice artifacts in your own product.

That choice changes risk:

• Direct model: stronger end-to-end evidence, but more control responsibility in platform.
• Mediated model: narrower product scope, but only if handoff completeness and single-record authority are provable.

Your minimum evidence pack should include:

• component inventory with create, store, and export responsibility
• samples of each billing document type
• field mapping from payment event to invoice record
• change-history and retention behavior for corrections, voids, and reissues
• design or vendor records showing direct versus mediated AEAT path

Sequence rollout by entity and system boundary#

Sequence implementation by entity and system boundary rather than as one Spain-wide switch. This pack does not confirm taxpayer-specific dates, thresholds, or sequencing rules.

Prioritize entities that both issue invoices and preserve billing data in their own stack, because classification risk is clearest there. For entities relying on an external invoicing provider, first confirm that the provider is the SIF boundary and that your platform is not generating a second authoritative-looking record.

Do not wait for full legal-date certainty to start reversible controls. Document analysis, storage evaluation, and ownership mapping can proceed now, and they usually expose implementation risk earlier than API work.

For diligence-style readiness checks, compare Prepare Your Payment Platform for Acquisition: Compliance, Technical, and Financial Readiness.

Handle Spain reporting-change claims with an evidence threshold#

Treat Spain-wide freelancer-payment reporting claims as unverified until you capture primary legal text or a regulator publication in your compliance record. That applies equally to claims involving Bizum or Revolut.

The excerpts here do not establish a Spain reporting duty. The Revolut material is US personal-fee content, including Personal Fees (Standard Plan) | Revolut United States and Personal fees (Metal), and the captured ECA item is only a title, Special report 01/2025: Digital payments in the EU, not operative Spain requirement text. Before you move from reversible controls to enforced policy, use an evidence gate:

• confirm source type: primary legal text or regulator publication, not summaries, blogs, or fee pages
• confirm scope fit: Spain, the correct actor type, and the relevant payment context
• log provenance: URL, downloadable PDF when available, and visible update marker, for example Download PDF and Last updated: November 18, 2025 on the Revolut pages

Treat source drift as a red flag. If terms defer to a separate Cardholder Agreement in case of conflict, or warn that card-issuer, ATM-operator, or network fees may apply, the document is commercial pricing content with variable outcomes, not a stable reporting rule.

While legal validation is pending, tighten data hygiene now. Run monthly transaction classification, standardize counterparty labels, and keep exports reconciliation-ready for possible reporting. The tradeoff is simple: waiting for certainty may reduce false positives, while delaying cleanup can increase backfill work later.

Related reading: KYC Best Practices for Reducing Money Laundering Risks: A Payment Platform Compliance Guide.

Separate obligations by entity so teams stop overcomplying#

Split obligations by legal entity before you assign controls. The material here does not establish Spain-specific LSSI, VeriFactu, or AEAT filing duties by PSP, platform, or merchant, so treat those role splits as legal-confirmation items, not engineering assumptions.

One entity-specific example is the EU Instant Payments Regulation lane. The source material describes it as applying to PSPs, with entry into force on 8 April 2024 and phased PSP timelines of 9 January 2025, 9 October 2025, and 9 April 2027. It also cites a processing benchmark of up to 100,000 euros within 10 seconds. Use that as a PSP control lane, not as a reason to copy PSP duties into marketplace terms.

Before you assign work, run one ownership test:

1. Are you the invoicing legal issuer in Spain?
2. Are you the regulated PSP, or are you using one?
3. Which entity owns customer-facing terms, payment screens, and invoice delivery?

If your platform is not the invoicing legal issuer in Spain, prioritize interface controls and evidence first, then get legal confirmation on filing roles before building irreversible reporting logic.

A common mis-scoping risk is that merchant invoicing duties get pushed to platform engineering, or PSP assumptions get copied into marketplace terms. Keep this boundary explicit, especially because the cited PSR Article 59 shared-liability model is presented as a proposal that could broaden liability toward online platforms, not a final enacted rule.

Design controls that auditors and operators can both trust#

Once you have split duties by entity, make every compliance judgment traceable from policy to data. For Spain work that may touch LSSI or VeriFactu, treat legal scope as a confirmation step and build the evidence pack before you automate enforcement. The excerpts here do not confirm Spain-specific required formats, thresholds, or deadlines.

Make four artifacts mandatory#

Use four artifacts that stay current and point to the same records:

• Decision log: date, owner, jurisdiction, affected entity, decision, open items, and supporting evidence
• Legal interpretation memo: whether each point comes from primary text, secondary commentary, or internal counsel judgment
• Control inventory: control owner, trigger, review cadence, and failure response
• System evidence map: where records live and which fields support reporting, invoice, payout, and reconciliation review

Format matters less than traceability. A reviewer should be able to start at one disputed transaction and find the legal assumption, the control, and the stored evidence without rebuilding context from chat threads.

Trace one chain end to end#

Your core rule is simple: one payment event should trace cleanly to its ledger impact and then to one export package. If that chain breaks, your process depends on manual reconstruction.

Carry stable identifiers across stages, including source event ID, internal transaction ID, merchant or payee ID, legal entity, amount, currency, timestamp, and status history. For retries and replays, keep an audit trail and idempotent behavior so you can show whether a record was duplicated, superseded, or safely ignored. That is a control design choice, not a claim about a Spain-specific legal requirement.

Put checkpoints before money moves#

Build controls into payout gating and reconciliation, not just post-period cleanup. As data volumes rise and third-party reporting expands, missing or inconsistent records become easier to detect and harder to defend. Treat data availability, steering information, and risk-model inputs as explicit checkpoints.

1. Pre-payout gate

Confirm required fields before release: counterparty identity, legal entity assignment, payout reason, source transaction reference, and ledger mapping. Hold records that are missing jurisdiction or entity tagging.

1. Post-posting reconciliation check

Confirm totals and counts match across payment events, ledger postings, and outbound export files. Log exceptions with reason code, owner, and resolution date.

If a monthly spreadsheet is required to reconstruct who was paid and why, treat that as a control gap.

Be explicit about product coverage#

State coverage limits directly in the control inventory. Control depth varies by market, program, and enabled modules, so do not imply Spain-wide coverage when only part of your flows are in scope.

If a control applies only to bank-transfer payouts, say so. If VeriFactu-adjacent evidence appears only when a specific invoicing module is enabled, state that explicitly. Clear limitations are more defensible than broad claims that fail in testing.

For a deeper look at tamper-proof logging, see What Is an Audit Trail? How Payment Platforms Build Tamper-Proof Transaction Logs for Compliance.

Before you freeze your Spain control inventory, align policy gates, status handling, and reconciliation outputs in one implementation spec: Review the docs.

Execute in a practical sequence over the next quarter#

Use this 12-week plan as an internal rollout sequence, not a legal deadline: confirm scope and evidence first, ship reversible controls next, and enforce policy only after assumptions are owned and tested.

Phase 1 weeks 1 to 2#

Start by separating confirmed material from secondary interpretation. A useful intake anchor is the reported March 24, 2026 approval of a Royal Decree framework for B2B e-invoicing under Law 18/2022. The source here is a VATupdate briefing, so treat it as secondary evidence.

Tag each item in your register as either primary legal text or secondary summary, including potential LSSI interpretations, VeriFactu or SIF assumptions, and Banco de España-adjacent claims. If an assumption can change payout policy, invoice handling, or customer-facing rules, assign a named legal or tax approver. Do not automate until an independent reviewer can see what is confirmed, what is provisional, and who owns each item.

Phase 2 weeks 3 to 6#

Build minimum controls for integrity and traceability while legal interpretation is still being finalized. The VATupdate briefing is useful as directional input because it lists implementation areas such as timelines, technical requirements, correction procedures, transmission workflows, archiving, and penalties.

For anti-fraud-control goals, preserve originals, log all changes, and make corrections explicit. If a tax base is reduced, route it through a corrective document rather than an overwrite; in Spain terms, a credit note.

At minimum, log create, edit, approval, export, reversal, and correction events with identity, timestamp, legal entity, source transaction ID, and prior and new status. Ensure archived exports, correction records, and approval logs are locatable on demand.

Phase 3 weeks 7 to 10#

Run dry-run packs to test evidence quality before enforcement. Include bank transfers, wallet flows, and Bizum-style scenarios where relevant, but do not treat those drills as proof that all such payments are reportable under confirmed primary Spanish text.

Each pack should contain transaction extract, counterparty label, legal entity, payout reason, amount, timestamp, source reference, ledger tie-out, and any correction record. Stress-test common failure points: missing jurisdiction tag, duplicate export, unclear wallet mapping, reversal after payout, and unlinked corrective invoice.

If operations still need ad hoc spreadsheets to resolve exceptions, controls are not ready.

Phase 4 weeks 11 to 12#

Use the final two weeks to lock decisions, not expand scope. Freeze escalation ownership for interpretation, invoicing controls, and production-blocking authority.

Approve go or no-go only when unresolved assumptions are not driving irreversible policy changes. Owners should be named across legal, finance, engineering, and operations. Trace tests should pass for standard and corrected records, and scope limits should be documented by product, rail, and entity.

Keep guidance hierarchy explicit in the approval pack: ENISA's June 2025 Version 1.0 technical guidance states it reflects ENISA interpretations and does not itself create regulatory obligations.

Catch the red flags that usually cause regulatory surprises#

Most regulatory surprises here come from weak evidence, scope drift, and broken traceability, not from one hidden rule. Treat these as release blockers before you lock irreversible controls.

Commentary mistaken for law#

Flag it when teams treat market commentary as binding text. If a requirement is justified with a market article, social post, fintech explainer, or blog post, require primary legal or regulator material in the record before calling it mandatory.

One source here is explicitly labeled a blog post, and another explicitly says it does not necessarily represent the European Parliament's official position. Use those as context, not as legal basis.

Keep a simple register for each requirement: source type, publisher, capture date, and primary legal text reviewed marked yes or no. If that field is no, keep the control reversible.

Scope drift between contracts and controls#

Flag actor mismatch early. If contracts, compliance tickets, and engineering controls describe different actors for the same flow, you have scope drift and should pause enforcement until ownership is clear.

Check the same transaction sample across three fields: legal entity, contracting party, and invoice issuer or payment descriptor. If they do not align and no approved rationale exists, escalate.

Records that cannot survive scrutiny#

Flag any process that cannot show what changed, when, and why from system records. If teams rely on emailed screenshots, edited PDFs, or analyst memory to explain corrections or reversals, traceability is not reliable.

One source describes manual PDF handling as a single point of failure. Use that as an audit mindset: originals, change history, correction path, and export evidence should be recoverable without rebuilding the story in spreadsheets.

Escalate immediately when any of the following is true:

• legal basis is still unclear, but product wants an irreversible rule
• finance and engineering assumptions about required reporting outcomes diverge
• teams use framework or regulator labels interchangeably, for example DORA, DMA, or AMLA, without stating the exact source and issue

Your escalation pack can stay short, but it should include the disputed source, actor assumption, one worked transaction example, and the specific evidence gap.

For team enablement, see How to Build a Payment Compliance Training Program for Your Platform Operations Team.

Conclusion#

The practical win is simple: separate confirmed obligations from unverified claims, then implement reversible controls first. That keeps you moving without hard-coding assumptions you may need to unwind later.

Here, the clearest confirmed pressure is invoicing integrity. If your entity issues invoices in Spain or operates the billing software behind them, prioritize VERI*FACTU-ready capabilities now: digital signatures, near-real-time recording, per-invoice QR code generation, and traceable record-keeping.

Use dated checkpoints as planning anchors, not final legal truth. The cited Banqup summary states approval on March 24, 2026 and a 12-month notice period after BOE publication. It also describes phased timing tied to turnover and taxpayer group, with later timing for some taxpayers in 2027, while noting that technical and implementation details may still be clarified.

Keep your control model in separate lanes: unresolved LSSI questions, invoicing obligations, and possible tax-reporting changes. If a claim is still secondary-only, avoid irreversible controls and keep your logic evidence-backed, dated, and easy to adjust.

Apply the same discipline to payment execution. EY flags higher risk exposure in fast-settlement flows, with sanctions screening and strong fraud detection as critical mitigations, so payment-speed changes should stay coordinated with invoice-control evidence and monitoring.

Use this article's tables and sequence as your operating baseline, then validate country-program specifics with specialist counsel before final enforcement.

If you need to confirm market or program coverage before turning compliance rules into production enforcement, talk to Gruv.