CESOP · quarterly · in force since Q1 2024
CESOP reporting
CESOP is the EU’s central electronic system of payment information. Payment service providers report, every quarter, the cross-border payments they made to payees who received more than 25 of them — so that tax administrations can find VAT that was never declared.
It has been in force since the first quarter of 2024. Unlike the OECD regimes, its rejection rules are published as a table of error codes, which means a file can be checked against exactly what the receiving system will do with it.
- Quarterly
- Reporting cadence
- To your national administration by the end of the following month.
- >25
- Payments per payee
- Counted per quarter, across everything you processed.
- Q1 2024
- First period
- Earlier periods are rejected outright.
- 1 GB
- Maximum message size
- Larger submissions must be split, each file valid alone.
Who has to report
The obligation falls on payment service providers under PSD2 whose payees are in a different Member State — or outside the EU — from the payer. Whether you are one is a question for an adviser; these are the shapes it commonly catches.
Acquirers
The acquiring PSP reports the payments it makes to the merchant, which is the payee. This is the largest single source of CESOP data.
E-money institutions
Issuing e-money and executing payment transactions with it brings the transactions into scope on the same terms as a bank's.
Payment institutions
Money remittance, payment initiation and account information services are all payment services, and each has payees.
Marketplaces that hold funds
A platform that receives funds and pays them on is executing payment transactions, whatever it calls itself internally.
Card schemes and processors
Three- and four-party schemes both appear in the PSP role list, and the reporting is apportioned between the roles.
Non-EU PSPs
Where the payer's PSP is in the EU, the payment is in scope for that PSP even if the payee's is not.
What surprises people
CESOP looks like a data export and behaves like a schema with opinions. The four below account for most first-quarter rejections.
The threshold is per quarter, not per file
More than 25 payments to one payee in a quarter, counted across everything you processed. A payee split across several files still counts once, so the count has to be done before the split.
Every reference is a UUID v4
MessageRefId, DocRefId and CorrDocRefId are UUID version 4 — not free text. A v1 UUID from a naive generator has the right shape, the wrong version nibble, and is rejected.
Refunds are negative
A refund carries a negative amount and the refund flag. Get the sign wrong and the quarter's totals invert, which is a rejection rather than a rounding difference.
Cross-border only
A payer in the same country as the payee is a domestic payment and is rejected. The payer is always located in an EU Member State.
Present but empty is a real answer
Elements required by law where you hold the data are reported empty when you do not — present to show you looked, empty to say there was nothing. Omitting them is a different claim.
Reporting too much is a problem too
A payee below the 25-payment threshold is normally out of scope. Filing them anyway means processing personal data without a legal basis for it.
We count the threshold across the whole quarter rather than per file, keep payee records stable between quarters so a correction points at the right DocRefId, and produce each quarter’s message on the deadline. The validator stays free and needs no account — it names the business rule and the error code for every finding, so you can see what the receiving system will do before you send it.