CESOP reporting: rules, thresholds and who must file

CESOP is the EU’s quarterly cross-border payments register. Since 1 January 2024, every payment service provider in the EU has had to record cross-border payments above a fixed threshold and file them with member-state tax authorities — who pass the records up to a central database run by the European Commission. It is a VAT-fraud tool, not a supervisory return; but for fintechs operating cross-border on a Freedom-of-Services passport it has created a uniquely heavy operational footprint. This piece walks through what the regime is, exactly what is reported, who reports when the payee’s bank sits outside the EU, why home-state filing alone is not enough, and how a payments firm actually builds the pipeline.

1. What CESOP is, in one paragraph

CESOP — the Central Electronic System Of Payment information — is an EU-wide database of cross-border payment data, technically managed by the European Commission. The legal architecture sits in three instruments: Council Directive (EU) 2020/284 creates the PSP reporting obligation through new Articles 243b–243d of the VAT Directive (Directive 2006/112/EC); Council Regulation (EU) 2020/283 amends Regulation (EU) 904/2010 to build the central system and the Eurofisc access layer; and Commission Implementing Regulation (EU) 2022/1504 lays down the technical rules for the database. PSPs must keep the underlying records for three calendar years after the end of the year in which the payment was dated; the central CESOP retains them longer for cross-checking.

2. Why CESOP exists

The regime is a VAT-fraud tool. Cross-border e-commerce inside the EU has historically been hard for tax authorities to follow, because the seller often sits in a different member state from the buyer and from the bank that processes the payment. Carousel fraud, undeclared online sales and abuse of small-value B2C rules all exploit that gap. By collecting payee-side payment data centrally and giving Eurofisc liaison officials cross-EU search, CESOP gives tax authorities a continuous trail of who is actually being paid by EU consumers, regardless of where the seller has registered.

Notably, CESOP is payee-only. The payer’s identity is not collected. The point is to find sellers who under-declare, not to surveil consumers.

3. Who must report, and when the obligation shifts

The Article 243d obligation hits four categories of payment service provider under PSD2:

• Credit institutions (CRR banks)
• Electronic money institutions (EMIs)
• Payment institutions (PIs), including AISPs and PISPs that handle funds
• Post office giro institutions

The reporting trigger is the more-than-25 cross-border payments per payee per calendar quarter threshold. Once a single payee crosses 25 in a single quarter, every cross-border payment to that payee in that quarter becomes reportable — not just the ones after the 25th.

A common misreading is that both banks in a transaction report. They do not. The obligation is allocated to avoid double counting:

• Where the payee’s PSP is located in a member state, the payee’s PSP reports. The payer’s PSP does not.
• Only where the payee’s PSP is outside the EU (a third country or third territory) does the payer’s PSP step in and report instead.

“Cross-border” means the payer is in a member state and the payee is in another member state, a third territory or a third country. The location of each party is derived from the IBAN — or, where there is no IBAN, from the BIC or another identifier of the PSP. Domestic same-state payments are out of scope.

4. What data is reported

The CESOP XML schema (version 4.x at the time of writing) carries, per reportable cross-border payment:

• Payee identification — name, IBAN or other account identifier, BIC, address, and VAT/tax number where known
• Payment amount and currency
• Date and a payment reference
• Payment-method code and whether it is a refund
• The member state of the payee, derived from the IBAN/BIC routing logic
• The location markers that let CESOP confirm the payment is cross-border

The file itself is a solved problem; the difficulty is that the same schema must be validated and lodged separately in every member state where a reporting obligation arises.

5. The Freedom-of-Services problem

This is where most cross-border fintechs lose three months they did not budget for.

If you are an EMI authorised in (say) Spain and you operate across the EU on a Freedom-of-Services passport, you have no physical office in France, Italy, Germany, the Netherlands or the other member states. CESOP nonetheless requires you to file wherever you are the reporting PSP — and because the obligation follows the payee’s PSP, an EMI that holds accounts for merchants across several member states can end up filing in each of them.

The structural cost is the registration and filing overhead across many jurisdictions, not the schema. A firm passporting into a dozen member states can be looking at a dozen registrations and a dozen quarterly submissions, each against a portal with its own quirks, deadlines and validation rules.

6. Reporting cadence and the two-step deadline

The PSP files within one month of quarter-end. The member-state tax authority then forwards the data to the central CESOP database by the tenth day of the second month following the quarter — so a Q1 filing lodged by 30 April is transmitted centrally in mid-May. Late-filing penalties are set nationally and vary widely; some member states issue per-payee fines that escalate quickly. The regime has been live since 1 January 2024, and supervisors now cross-compare data across member states, so an inconsistent or missing filing is visible.

7. Three worked examples

The rules are mechanical, so they are clearest through the cases a payments firm actually meets.

• Spanish EMI, French merchant, 40 payments. An EMI authorised in Spain holds the account of a merchant established in France and processes 40 cross-border consumer payments to it in Q2. Rule: the payee’s PSP is in a member state (Spain), so the payee’s PSP reports; 40 > 25, so all 40 are reportable. Action: the EMI lodges the XML with the Spanish tax authority — as the payee’s PSP, it reports in its own member state of authorisation, not France. Outcome: one quarterly filing covering that payee, transmitted to CESOP by mid-August.
• Payee bank outside the EU. An EMI in the EU processes 60 payments from EU consumers to a merchant whose account sits with a bank in a third country. Rule: no EU PSP holds the payee side, so the obligation shifts to the payer’s PSP. Action: the EMI reports these payments as the payer’s PSP, and — importantly — counts them toward the 25-payment threshold together with any payments to the same payee’s EU accounts. Outcome: the third-country leg does not fall through the cracks; the payer-side EMI captures it.
• Threshold not crossed. A PISP processes 18 cross-border payments to a given payee in Q3 and 30 in Q4. Rule: the test is per payee per quarter. Action: the payee is out of scope in Q3 (18 ≤ 25) and in scope in Q4 (30 > 25), so the firm reports nothing for that payee in Q3 and all 30 payments in Q4. Outcome: scope is recalculated every quarter — a payee can drift in and out, so the threshold logic must run on each quarter’s data, not once.

8. How a payments firm builds the pipeline

Stripped of vendor branding, the build has four moving parts:

• Threshold engine. A quarterly job over the payments warehouse that groups by payee, counts cross-border payments, applies the more-than-25 test per member state, and marks every payment to an in-scope payee as reportable.
• Location logic. IBAN/BIC parsing to place payer and payee, decide whether the payment is cross-border, and allocate the obligation to the payee’s PSP or — where the payee’s bank is outside the EU — to the payer’s PSP.
• Schema generation. Producing valid CESOP XML and passing each national portal’s validation rules, which are broadly common but not identical.
• Portal and registration layer. The long pole: obtaining a local tax number and registration in each member state where you report, then lodging and reconciling the filings. This is procedural rather than technical, and it is where timelines slip.

Below a handful of active member states, a firm can run this in-house or outsource only the portal-submission and local-representation steps; across ten or more, the registration and filing burden usually pushes a small team toward a managed reporting service. The decision is driven by country coverage, not by engineering difficulty.

9. FAQ

10. What to do, today

If you operate cross-border on a Freedom-of-Services passport:

• Run the threshold engine against a real quarter of data to see how many payees and member states you actually trigger — the answer is usually smaller than feared and drives everything else.
• Open tax registrations in the member states where you are the reporting PSP, in parallel — this is the long pole, measured in weeks per country.
• Confirm your location logic handles the payer-PSP shift for third-country payee banks, including the threshold-counting rule.
• Run a Q1 dry submission against each portal so audits do not catch you in your first live quarter.
• Pick build / outsource / hybrid on the basis of country coverage, not engineering — and revisit it as your passport footprint grows.

Related: CESOP XML schema mapping · CESOP reporting in the Netherlands · DAC8 EU crypto reporting · CESOP reporting in Spain (Modelo 379) · DAC7 platform-operator reporting · CESOP data and system readiness