Getting ready for Central Electronic System of Payment Information (CESOP)
EU wide reporting to combat VAT Fraud
From 1st Jan 2024, all Payment Service Providers (PSPs) operating in EU will have an obligation to report cross border payments to local authorities on a quarterly basis. This data will be consolidated into a Central Electronic System of Payment Information. The objective is to provide regulators with enough data to track and eventually plug VAT leakages from the system.
Frequently Asked Questions
The Central Electronic System of Payment information (CESOP) has been created by the European Union to collect payment data in order to help combat e-commerce VAT fraud. The new Council Directives are (EU) 2020/284 and (EU) 3030/283.
Payment data for all cross-border transactions where the Payer is in an EU Member State will be collected from Payment Service Providers by each Member State. Each member state will submit this data to CESOP. The collective data will then be made available to each member state to further enhance the fight against VAT fraud.
The new Council Directives come in to force on 1st January 2024 with the first submission due on the 30th April 2024 for the first period 1st January 2024 – 31st March 2024. Subsequent reports are required every quarter.
All Credit, E-money, Payment, and post-office giro institutions which provide payment services in the EU must submit eligible transactions. This includes all payment service providers in EU member states and EEA countries (Iceland, Liechtenstein, and Norway). For EEA countries this includes all payment service providers that process payments for either Payers or Payees an EU member state. Although Northern Ireland is part of the EU VAT directive, payment service providers established in Northern Ireland are not in scope. Marketplaces who hold funds on behalf of their clients and are licensed in an EU Member State or EEA are also in scope.
- Credit transfer
- Direct Debit
- Money remittance
- Card Payment
All transactions where the Payer is located in an EU member state and
- Where the transaction is to a Payee in another EU member state or third territory or third country.
- Where there are 25 or more payment transactions to a Payee
Note that payments initiated by a Payer in an EEA country are not in scope.
This is referred to as aggregation rules in CESOP. A payment service provider must aggregate transactions for each Payee to determine if 25 or more transactions have been made to a Payee. The transactions are not to be aggregated for submission – individual transactions need to be reported.
Thus, a payment service provider must aggregate all cross-border transactions for all payment types and payment accounts applicable to a Payee and determine if that Payee is in scope. The payment service provider must then send only the transactions that are applicable to their submission.
For all transactions there will be a payment service provider for the Payer and the Payee. Only one of these payment service providers should report the transaction and the following principle applies.
The payment service provider of the payee is responsible for reporting all transactions unless the payment service provider of the payee is in a third territory or third country. In this case the Payer’s payment service provider must report.
Note that for card payments there are circumstances where the payment service provider is both the issuer and the acquirer. In such cases then they will report all qualifying transactions in their capacity as payment service provider to either the Payer or the Payee.
This reporting obligation applies to all payment service providers licenced to operate in an EU member state and includes payment service providers in an EEA country who are licensed to provide payment services in the European Union including those without physical presence in an EU member state who provide services under PSD2 passporting rules.
Transactions should be reported by payment service providers:
- to their home member state where they are licensed or
- to their host member state(s) if they are providing services directly or through a branch or an agent in EU member states other than their home member state.
Note that each EU member state national tax administration will define transmission methods, validation, and re-submission processes.
The table below lists the core 15 data elements that should be reported. Each data element is either “mandatory”, “optional mandatory” or “mandatory when applicable”. This is dependent on the payment type and the availability of data. It is important to provide all data where applicable and where available as failure to do so would result in non-compliance.
Data definitions for the data elements below are defined in the XML Schema Definition which is defined as part of the directive.
|BIC ID reporting PSP
|Identifier for the PSP transmitting the Data
|Legal name and Business Name of the Payee
|Payee VAT / TIN
|VAT Identification Number / and or other national tax number of Payee
|Payee Account ID
|IBAN or other identifier that unambiguously identifies and gives location of payee involved in transaction
|BIC ID / Payee PSP
|BIC or any other business identifier code that unambiguously identifies and gives the location of the PSP – when Payee received funds without having a Payment account
|All address of the Payee – including legal, business and warehouse address
|Refence to the refund transaction and link to the original
|Date / time
|Date / time of execution of Payment transaction or refund
|MS Origin payment
|MS original of Payment received by Payee
|MS Destination refund
|MS of destination refund
|Payer location information
|Indication of How the location was deduced
|Reference that unambiguously identifies the transaction
|Reference to indicate Physical presence of Payer in premise of merchant
Payment service providers are responsible for validating that their submissions adhere to the XML Scheme Definition and for compliance with the business rules governing the inclusion of transactions and the content of each data element.
The rules for validation by each EU member state national tax administration are not defined in the directives. However, it is likely that each member state will validate adherence to the XML Schema Definition and reject files that do not conform.
CESOP business rules (and XML Schema Definition validation where national tax administrations have not already verified) will then be checked centrally by CESOP. CESOP will send the validation result to the national tax administration who in turn will send the result to the payment service provider.
If the result of the validation is negative, then there are two types of error:
- XML Schema definition error. In this case the payment service provider must resubmit the whole file with corrections.
- Business rule validation error. In this case national tax administrations are advised to allow payment service providers to resubmit only the data on Payees that require correction.
Each national tax administration is at liberty to set their own procedures and time constraints for validation and re-submission. CESOP have recommended that national tax administrations swiftly inform payment service providers of any errors and give up to 30 days after the validation message is sent to the payment service provider to correct and re-submit.
Note that should a payment service provider determine that previous submissions have errors then they can send a spontaneous file to the relevant national tax administration. To avoid non-compliance, this must be done prior to the expiry of the reporting period that applies and/or retention period for data in CESOP (5 years).
- Reporting to local authorities will be required f the PSP operates in multiple jurisdictions resulting in multiple submissions and in multiple formats.
- Reporting criteria viz. which transactions are in scope and who does the reporting obligation fall on
- Data across multiple business lines needs to be consolidated and aggregated to determine eligibility.
- Regulatory compliance not restricted to CESOP as PSPs will need to consider compliance with data protection rules as well.