Free forever · no account · nothing uploaded
CESOP XML validator
Drop a CESOP Payment Data message in and get a line-by-line report against the Commission’s Payment Data XSD. The parser runs in this tab: the file is never transmitted and never stored — which matters more here than anywhere else, because a CESOP file is a list of your customers’ payees.
CESOP is the one regime whose rejection rules are published as a table. So rather than guessing, every finding below names the business rule it implements and the error code the receiving system will raise.
Drop a CESOP XML file here
It is parsed in this browser tab. No upload, no account, no size limit beyond what your machine can hold.
What it checks
The XSD catches shape. What gets a message partially rejected is a payee whose payer is in the same country, an IBAN with one digit wrong, or a refund recorded as a positive amount — rules the schema cannot express, published separately, and checked here against the file you are about to send.
Every finding names its error code
The Commission publishes CESOP's business rules as a table of rule IDs and error codes. Each finding here names the one it anticipates — not 'this looks wrong' but 'CESOP rejects this record with 40010'.
UUID v4 references
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 with 10050 or 20030.
Cross-border only
CESOP collects cross-border payments. A payer in the same country as the payee is a domestic payment and is rejected with 40010, and the payer is always in an EU Member State.
IBAN and BIC
An account identifier typed IBAN is checked for shape and then run through the mod-97 algorithm the rules specify. BICs on the Reporting PSP and on a Representative are checked against ISO 9362.
Refunds and amounts
A refund carries a negative amount and a payment a positive one — get the sign wrong and the quarter's totals invert. Zero amounts, duplicate transaction identifiers and repeated date types are all rejected.
Quarter arithmetic
Transactions dated outside the quarter being reported, periods before CESOP began on 1 January 2024, quarters that have not finished yet, and submissions past the end of the following month.
Source: European Commission DG TAXUD, Payment Data XSD User Guide — CESOP, v4.40 (DG TAXUD). Findings quote it; they are not tax advice.
CESOP code lists
The enumerations, and the full published error catalogue — useful in its own right when a national administration sends back a Validation Result with a bare number in it.
MessageType
- PMT
- Payment data (or 'no payment data')
- VLD
- Validation Result message
MessageTypeIndic
- CESOP100
- The message contains new data
- CESOP101
- The message contains corrections or deletions of previously sent data
- CESOP102
- The message indicates there is no data to report
DocTypeIndic
- CESOP1
- New data
- CESOP2
- Corrected data
- CESOP3
- Deletion of data
AccountIdentifier type
- IBAN
- International Bank Account Number
- OBAN
- Other Bank Account Number
- Other
- Other identifier locating the payer or payee
TAXId type
- UNCONFIRMED_VAT
- Unconfirmed or national VAT identifier
- TIN
- Tax Identification Number
- IOSS
- Import One Stop Shop identifier
- OTHER
- Other tax identifier
TransactionDateType
- CESOP701
- Execution date
- CESOP702
- Clearing date
- CESOP703
- Authorisation date
- CESOP704
- Purchase date
- CESOP709
- Other date
LegalAddressType
- CESOP301
- Residential or business
- CESOP302
- Residential
- CESOP303
- Business
- CESOP304
- Registered office
- CESOP309
- Unspecified
CESOP error codes
- 10010
- MessageRefID is not unique
- 10020
- The 'Timestamp' element refers to a wrong value
- 10030
- The period is before 01/01/2024
- 10040
- Wrong CorrMessageRefID
- 10050
- Wrong format of the MessageRefID
- 10060
- Wrong format of the CorrMessageRefID
- 10070
- An initial Payment Data message can only contain new data
- 10080
- A correction message can only contain corrections and/or deletions
- 10090
- The message is not a payment data message
- 10100
- The reporting period cannot be updated
- 10110
- CorrMessageRefId wrongly used in MessageSpec
- 10120
- Wrong TransmittingCountry
- 20010
- DocRefID is not unique within the message
- 20020
- DocRefID is not unique within the system
- 20030
- Wrong DocRefID format
- 20040
- Wrong CorrDocRefId value
- 20050
- CorrDocRefId for new data
- 20060
- Missing CorrDocRefId
- 20070
- CorrDocRefId no longer valid
- 20100
- Invalid PSP's BIC format
- 20110
- Missing ReportedPayee
- 30010
- Business identifier of the Representative is equal to that of the Reporting PSP
- 40010
- The reported transaction does not represent cross-border payment
- 40020
- Wrong IBAN format
- 40030
- IBAN is not valid
- 40040
- ReportedPayee listed in the No Payment Data for the requested period message
- 40050
- The 'ReportedTransaction' element is missing
- 40060
- Discrepancy in the 'AccountIdentifier' attributes
- 40070
- Invalid Representative's BIC format
- 40080
- Discrepancy between 'AccountIdentifier' and 'Representative'
- 45010
- Wrong value of the 'IsRefund' element in the 'AmountCurrency' element
- 45030
- The 'DateTime' element refers to a wrong value
- 45040
- The 'TransactionIdentifier' element is not unique within the Payment Data message
- 45050
- The 'TransactionIdentifier' element is not unique within the system
- 45060
- Zero value for 'Amount' element
- 45080
- Same transaction date provided more than once
- 50010
- The XML message is not well formed
- 50070
- Message size exceeded
- 50080
- Too many errors detected
Validating is free. Producing the file is what we sell.
CESOP is quarterly, and the threshold — more than 25 cross-border payments to one payee in a quarter — has to be counted across everything a PSP processed, not per file. The paid product does that counting, keeps the payee records stable across quarters so corrections point at the right DocRefIds, and produces each quarter’s message on the deadline — from EUR 59 a month, priced on the page.