CESOP reporting in Spain — Modelo 379, the cross-border payments return, thresholds and deadlines

CESOP reporting in Spain runs through Modelo 379 — the quarterly cross-border-payments return that every payment service provider with a Spanish footprint files to the Agencia Tributaria. The substance is set by EU law and is identical across the bloc, but the Spanish layer has its own form, its own web service and its own thresholds you have to count correctly. This piece walks through what Modelo 379 captures, who has to file it, how the more-than-25-payments test actually works, and how the return feeds the central European CESOP system.

1. What Modelo 379 is

Modelo 379 is Spain’s implementation of the EU-wide CESOP reporting obligation — the declaración informativa sobre pagos transfronterizos. It transposes two EU instruments into the Spanish VAT framework:

• Council Directive (EU) 2020/284 — amending the VAT Directive 2006/112/EC to require payment service providers to keep and report records of cross-border payments.
• Council Regulation (EU) 2020/283 — establishing the Central Electronic System of Payment Information (CESOP), the Commission-run database that aggregates the returns from all member states.

In Spanish domestic law the obligation sits in Article 166 quater of Ley 37/1992 del IVA and Article 81 bis of the VAT Regulation (Reglamento del IVA). The obligation applies from 1 January 2024; the first Modelo 379 covered the first quarter of 2024 and was filed in April 2024. The purpose is anti-VAT-fraud: tax authorities cross-match payment flows against declared sales to catch undeclared distance sales into the EU.

2. Who must file

The obligation falls on payment service providers whose home member state or host member state is Spain — in other words, a PSP is caught if it provides the payment service from Spain or into Spain. The covered categories are:

Providers operating exclusively in the Canary Islands, Ceuta and Melilla are outside scope, because those territories sit outside the EU VAT area. The obligation attaches to the PSP that executes the payment — so a firm passporting into Spain on a Freedom-of-Services or branch basis is caught the moment its Spanish activity involves cross-border payees.

3. What counts as a cross-border payment

The single most misread part of CESOP is the geography test. A payment is cross-border, and therefore reportable, when the payer is located in one member state and the payee is located in another member state or in a third country. Location is fixed by the identifier of the account — the IBAN for the payer, and the IBAN or other identifier (or the BIC of the payee’s PSP) for the payee.

This creates a role test that decides whether you report at all. Where the payee’s PSP is in the EU, the reporting duty is that payee’s PSP; the payer’s PSP only steps in when the payee’s PSP is outside the EU. So for a given flow you must first ask whether you are acting for the payer or the payee, and where the counterparty’s PSP is located, before you decide whether the transaction belongs in your Modelo 379.

4. The more-than-25 threshold

You do not report every cross-border payment. The trigger is more than 25 cross-border payments to the same payee within a single calendar quarter. The mechanics that trip firms up:

• The count is per payee, per quarter — not cumulative across the year and not aggregated across payees.
• Once the 26th payment to a payee lands in a quarter, all cross-border payments to that payee in that quarter become reportable — including the first 25.
• The payee is identified through a stable identifier; the same merchant behind several trade names but one IBAN is one payee.
• Refunds and payment reversals are flagged but still form part of the dataset for a reportable payee.

5. What the record contains

For every reportable payee, and every cross-border payment to that payee in the quarter, the return carries a fixed CESOP dataset:

• The payee’s name and any VAT or tax identification number held.
• The payee’s identifier — IBAN or, where none, the identifier that lets the payee be located, plus the BIC or code of the payee’s PSP.
• The BIC or identifier of the reporting PSP.
• Per payment: the amount and currency, the date and time, and whether the payment was a refund.
• The member state of the payer and the member state (or third country) of the payee, derived from the account identifiers.
• Whether the payment was initiated at the physical premises of the merchant — the point-of-sale flag.

PSPs must keep these records in electronic form for three calendar years from the end of the year of the payment, so the retention layer, not just the quarterly extract, has to be built.

6. How Modelo 379 feeds the EU CESOP system

Modelo 379 is filed with the Agencia Tributaria, but it does not stop there. The AEAT validates the national returns and transmits the data to the Commission’s Central Electronic System of Payment Information by the tenth day of the second month following the reporting quarter. From CESOP, the data is available to the anti-fraud experts of every member state (Eurofisc). The practical consequence for a payments firm is that a malformed Spanish return is not merely a domestic problem — it fails onward transmission into an EU-wide dataset, so schema discipline matters.

7. Three worked examples

The rules are mechanical, so they are clearest through the cases a Spanish-facing PSP actually meets.

• Acquiring for one merchant. A Spanish-authorised electronic money institution acquires card payments for an online retailer. In Q2 it processes 40 payments from cardholders in France, Germany and Italy to that merchant’s single IBAN. Rule: the merchant is the payee, the count is per payee per quarter, and 40 exceeds 25. Action: the EMI reports all 40 payments to that payee in the Q2 Modelo 379, filed in July. Outcome: the full quarter’s flow to that payee is reported, including the payments before the threshold was crossed.
• Working out who reports. A firm executes a payment from a payer in Spain to a payee whose bank is in Portugal. Rule: where the payee’s PSP is in the EU, the duty sits with the payee’s PSP — here the Portuguese one. Action: the Spanish payer’s PSP does not report this flow. But reverse the geography — payer in France, payee with a Spanish IBAN at the firm — and the firm is the payee’s PSP in Spain, so the flow counts towards its Spanish return. Outcome: the same firm reports some flows and not others, depending purely on the role and the counterparty PSP’s location.
• Third-country payer. A Spanish payee receives 60 inbound payments in a quarter, all from payers whose banks are outside the EU. Rule: a payment where the payer is in a third country is not a cross-border payment for CESOP. Action: none of the 60 are counted or reported; the more-than-25 test is never reached. Outcome: a high inbound volume can carry zero reporting, because the direction of the flow, not the number of payments, governs.

8. Deadline and channel

Modelo 379 is quarterly. The filing window is the calendar month following the end of each quarter — Q1 in April, Q2 in July, Q3 in October, Q4 in the following January. There is no paper option: the return is filed electronically through the AEAT’s sede electrónica, and high-volume PSPs use the dedicated web service (procedure code GI51) to submit the XML message rather than keying data. A firm should build the quarterly extract as a batch job off its payments ledger, validate it against the AEAT schema before submission, and reconcile the payee count internally so the threshold is applied consistently.

9. FAQ

10. What to do, today

• Confirm whether Spain is your home or host member state for payment services — that single fact decides whether Modelo 379 applies to you at all.
• Build the role logic first: for each flow, determine whether you are the payer’s or the payee’s PSP and where the counterparty PSP sits, because that governs whether the payment is even yours to report.
• Implement the more-than-25 count per payee, per quarter, and make it recompute the whole quarter once a payee crosses the line.
• Validate the XML against the AEAT schema before you submit through GI51 — a return that fails onward transmission to CESOP is a return not filed.
• Stand up the three-year electronic retention of the payment records alongside the quarterly extract.

Related: What is CESOP reporting? · CESOP XML schema mapping · DAC8 EU crypto reporting