CESOP reporting: rules, thresholds and who must file

CESOP is the EU’s quarterly cross-border payments register, and the part firms get wrong is not the file — it is the counting. Since 1 January 2024 every payment service provider in the EU has had to keep records of cross-border payments to payees above a fixed threshold and lodge them with member-state tax authorities, who pass them to a central database run by the European Commission. It is a VAT-fraud tool, not a supervisory return. This piece works through the legal text: how the more-than-25 test is actually calculated, which of the two PSPs files, what the record must contain, where a Freedom-of-Services firm lodges it, and the two clocks that govern the quarter.

1. What CESOP is, and the three instruments

CESOP — the Central Electronic System Of Payment information — is an EU-wide database of cross-border payment data, technically managed by the European Commission. Three instruments build it, and they do different jobs:

The split matters: your obligation lives in the VAT Directive as transposed by each member state, which is why one national portal behaves differently from its neighbour.

2. Why it exists, and what it deliberately omits

Cross-border e-commerce is hard for tax authorities to follow, because the seller often sits in a different member state from the buyer and from the bank processing the payment. Collecting payee-side data centrally and giving Eurofisc liaison officials cross-EU search produces a continuous trail of who is actually being paid by EU consumers.

It is payee-only: Article 243d lists the payee’s name, tax number, IBAN and address, and the payer’s identity appears nowhere. Access is correspondingly narrow — under Article 24d of Regulation (EU) 904/2010, only Eurofisc liaison officials holding a personal CESOP user identification may look, and only to investigate or detect suspected VAT fraud.

3. Who is a reporting PSP — including the category most firms miss

Article 243a(1) defines the population by reference to points (a) to (d) of Article 1(1) of PSD2: credit institutions, electronic money institutions, post office giro institutions, payment institutions. It adds a fifth category scoping exercises routinely drop — a person benefiting from the Article 32 PSD2 exemption, the small-payment-institution regime. Article 243a(3) also pulls in money remittance (Article 4(22) PSD2) alongside ordinary payment transactions.

4. The more-than-25 test, calculated the way the text says

Article 243b(2) sets the trigger: the obligation applies where, in a calendar quarter, a PSP provides payment services corresponding to more than 25 cross-border payments to the same payee. Twenty-five is not enough; twenty-six is. Once the payee is in scope, every cross-border payment to that payee in that quarter is reportable, not only those after the twenty-fifth.

The second subparagraph is what quietly breaks implementations. The count is made per member state and per identifier as referred to in Article 243c(2) — the payee’s IBAN, or the BIC of the payee’s PSP where there is no IBAN. Only where the PSP has information that the payee has several identifiers is the calculation made per payee.

So the default counting key is not “payee”. It is member state × identifier × quarter, upgraded to payee-level aggregation exactly when you hold the linking information. An engine grouping on a customer ID from the outset over-reports; one grouping on IBAN and never consolidating known multi-account payees under-reports.

“Cross-border” is defined in Article 243b(1): the payer is located in a member state and the payee in another member state, a third territory or a third country. Location is resolved under Article 243c — IBAN first, then the BIC of the PSP acting for the party. Domestic same-state payments are out of scope.

5. Which of the two PSPs files

Both PSPs do not report. Article 243b(3) allocates the obligation from the payer’s side, by exclusion: the requirement does not apply to the payer’s PSP where at least one of the payee’s PSPs is located in a member state, as shown by that PSP’s BIC or other unambiguous business identifier. Where no payee PSP is in a member state — a third-country payee bank — the exclusion falls away and the payer’s PSP reports.

The sting is the last sentence of 243b(3): the payer’s PSPs shall nevertheless include those payment services in the calculation under paragraph 2. Payments you do not report because an EU payee PSP exists still count toward your own threshold. Counting scope and reporting scope are two different filters, and a single-filter implementation gets one of them wrong.

6. The record, field by field

Article 243d(1) fixes the contents: the BIC identifying the reporting PSP; the payee’s name or business name as it appears in the PSP’s records; if available, a VAT or other national tax number; the IBAN or, failing that, another identifier that unambiguously identifies and locates the payee; the BIC of the payee’s PSP where the payee receives funds without holding a payment account; if available, the payee’s address as recorded; and the details of each cross-border payment and of any refunds relating to them.

Article 243d(2) defines those details: date and time; amount and currency; the member state of origin of the payment (or of destination for a refund) together with the information used to determine it under Article 243c; any reference unambiguously identifying the payment; and, where applicable, that the payment was initiated at the merchant’s physical premises.

Two of those do more work than their length suggests: the “information used to determine the origin” element means the location decision must be evidenced, so keep the identifier you resolved on rather than only the resulting country code; and the physical-premises flag is how card-present activity is separated from distance selling.

7. Where you lodge it — the Freedom-of-Services problem

Article 243b(4)(b) turns CESOP into a multi-country project. Records must be made available, in accordance with Article 24b of Regulation (EU) 904/2010, to the home member state of the PSP, or to the host member states when the PSP provides payment services in member states other than the home member state.

An EMI operating across the EU on a Freedom-of-Services passport has no office in the host states — but it provides payment services there, and the host-state limb bites. Each member state runs its own collection channel, and most require a local tax identification and registration before a single XML can be lodged.

8. Two clocks, and two retention periods

The quarter has two deadlines and only the first is yours. Under Article 24b(1)(a) of Regulation (EU) 904/2010 each member state collects from PSPs no later than the end of the month following the calendar quarter, by electronic standard form. Under Article 24b(3) the national liaison office then transmits to CESOP no later than the tenth day of the second month following the quarter.

Retention is also two numbers: the PSP keeps records electronically for three calendar years from the end of the calendar year of the payment date (Article 243b(4)(a)); CESOP retains them for a maximum of five years from the end of the year of transmission (Article 24c(2)). Late-filing penalties are national and vary widely.

9. Three worked examples

Example 1 — one payee, two IBANs, one quarter

Facts: an EMI holds two accounts for the same merchant, both in the EMI’s own member state. In Q2 the merchant receives 15 cross-border consumer payments into one IBAN and 14 into the other — 29 in total, neither identifier crossing 25 alone.

Rule: Article 243b(2), second subparagraph. The count is per member state and per identifier unless the PSP has information that the payee holds several identifiers, in which case it is made per payee. Holding both accounts under one customer record is plainly that information.

Outcome: consolidate the two IBANs to the customer before applying the test; the payee is in scope and all 29 payments are reportable. An IBAN-keyed engine files nothing and shows a clean nil position for that merchant.

Example 2 — the payments you count but do not report

Facts: a payment institution processes, for its own paying customers, 40 cross-border payments in Q3 to a merchant banked in another member state, plus 12 to the same merchant’s account at a third-country bank.

Rule: Article 243b(3). For the 40, a payee PSP is in a member state, so the payer’s PSP does not report them; for the 12 it does. But the final sentence requires the 40 to be included in the paragraph 2 calculation regardless.

Outcome: count 52, which is above 25; report 12. Test the threshold on reportable payments alone and you get 12, under the threshold, and file nothing.

Example 3 — the passporting EMI’s filing map

Facts: an EMI authorised in one member state provides payment services on a Freedom-of-Services basis in six others, and is the payee’s PSP for merchants attributable to three of them.

Rule: Article 243b(4)(b) — records go to the home member state or to the host member states where the PSP provides services beyond the home state. The obligation follows the service, not the office.

Outcome: build the filing map before the engineering — per host state, confirm the transposed lodging channel and obtain tax identification and portal enrolment, scheduling enrolments in parallel because each is serial and measured in weeks. Usually far fewer filings than passported states, but known in advance rather than discovered live.

10. The schema and validation stack

The Commission publishes the technical package, and it moves: the current release is the XSD and XSD User Guide package v7.00 of 17 April 2026, alongside the Guidelines for the reporting of payment data (v1.2, 19 June 2025), the Additional Clarification of 11 September 2024, the CESOP Validation Module v1.7.1 with User Manual v6.00 (20 October 2025), an FAQ and a Data Quality Checklist. Pin your mapping document to a named schema version and the next upgrade is a diff, not an archaeology exercise. The build has four parts:

1. Location logic — Article 243c resolution from IBAN then BIC, retaining the identifier used so the 243d(2)(c) evidence element can be populated.
2. Threshold engine — the member state × identifier count with payee-level consolidation where linkage is known, run over reportable and merely countable payments alike.
3. Schema generation and validation — XML against the current XSD, cleared through the validation module before a portal sees it.
4. Registration and lodging — host-state tax identifications, portal enrolments and quarterly submissions, with acknowledgements reconciled to the payee counts filed.

11. FAQ

12. What to do, today

• Re-read your threshold specification against Article 243b(2). If it groups on a customer identifier by default, or on IBAN with no consolidation step, it is wrong in one direction or the other.
• Separate countable from reportable in the data model — the payer-PSP rule needs both, and one flag cannot carry both meanings.
• Run the engine over a real past quarter to produce the filing map before any build-or-outsource decision, and start host-state tax registrations in parallel — they are serial per country and are the item that slips.
• Pin the mapping document to the current XSD package version, and check the 243d(2)(c) evidence element is populated.

Related: CESOP XML schema mapping · Building the CESOP file · CESOP data and system readiness · CESOP reporting in the Netherlands · CESOP reporting in Spain (Modelo 379) · DAC7 platform-operator reporting · Validation rules