CESOP: the payment message and its rejection codes.

How the file is structured

A CESOP submission is an XML message covering one reporting member state for one calendar quarter. It carries a header identifying the reporting payment service provider, the member state and the period, and then a body organised around payees rather than around transactions.

That orientation is the single most important design fact. The threshold is counted per payee, the reported population is defined per payee, and the transactions sit underneath the payee they belong to. Systems that store a flat transaction ledger have to invert it before the file can be assembled.

The payee block

• Identity — name as recorded, and any value added tax or other tax identification number held.
• Account identifiers — the identifier used to receive the funds, and any other identifier the provider holds for the payee.
• Location — the member state or third country derived from the identifier, together with the basis on which it was derived.
• Address — as held by the provider.

The transaction block

Under each payee sit the cross-border payments received in the quarter: date and time, amount and currency, whether the record is a payment or a refund, the payment method, the member state of origin of the payer, and an indicator of whether the payment was initiated at the physical premises of the merchant. Refunds are reported as records in their own right and linked to what they reverse, not netted against it.

Two gates, two failure sets

Treating portal acceptance as the finish line is the most common process error. Build the operating model around the assumption that findings arrive after submission, and that the correction window is shorter than the preparation window.

The recurring rejection classes

• Identifier structure — account identifiers that do not conform to the expected format for the country they claim, or business identifier codes of the wrong length.
• Coded values — country and currency codes not drawn from the controlled lists, or free text in a coded field.
• Location without a basis — a payee country reported with no permitted derivation recorded.
• Threshold inconsistency — a payee reported with fewer transactions than the threshold requires, or a payee omitted whose count crosses it once identities are resolved.
• Duplicates — the same payment appearing twice, usually where a partial submission was re-run rather than corrected.
• Period mismatch — transaction dates outside the quarter the header declares.
• Role confusion — records submitted for payments where the provider acted for the payer rather than the payee.

Corrections and deletions

Corrections operate at record level. A corrected record references the original so the receiving system can replace it, and a deletion withdraws a record that should never have been reported. Resubmitting a whole quarter without references creates a duplicate population rather than replacing the first one — the same failure mode as in the automatic exchange frameworks, for the same reason.

National practice varies on windows, statuses and whether a nil submission is expected. Confirm all three with each authority you file to rather than generalising from one.

REGREP is an independent software provider. This record explains a reporting framework in plain language and is not legal, tax or regulatory advice. Confirm scope, thresholds and submission dates with your competent authority before you file.