CESOP XML reporting — mapping a SEPA payment to the CESOP schema, field by field

Mapping a SEPA payment to the CESOP XML schema is mostly mechanical — until you hit the parts where the schema asks for data your payment messages do not carry. This is the technical companion to our CESOP overview: a field-by-field walkthrough of how a single euro-zone credit transfer turns into one CESOP record, where the reporting obligation actually sits, and where most engineering teams spend the longest. The obligation itself flows from Council Directive (EU) 2020/284 (which inserted Articles 243b–243d into the VAT Directive 2006/112/EC), with the central system established by Council Regulation (EU) 2020/283 and the technical detail in Commission Implementing Regulation (EU) 2022/1504; it has applied since 1 January 2024.

1. Recap — what CESOP wants

CESOP captures cross-border payments where the payee is the focus. A payment is in scope when the payer is located in a member state and the payee is located in another member state or a third country, and where the payee’s payment service provider (PSP) recorded more than 25 cross-border payments to that payee in the calendar quarter. For each reportable payment, the schema asks for:

• The payee’s identification (name, address, IBAN or other account identifier, BIC, VAT or tax number where known).
• The payment amount, currency and date.
• The payment-method code.
• The location of the payee (member-state-of-payee designation).
• A flag indicating whether the payment is a refund of an earlier reportable transaction.

The payer is not in scope. The schema is concerned with the merchant or recipient side of the transaction. Crucially, the reporting duty sits with the payee’s PSP where that PSP is located in the EU; it shifts to the payer’s PSP only where the payee’s PSP sits outside the EU. Get that allocation wrong and you either double-report or leave a gap.

2. The CESOP XML structure, in plain terms

The schema is maintained by the Directorate-General for Taxation and Customs Union (DG TAXUD) at the European Commission and is versioned — track the version number across reporting periods, because a new release can tighten validation. It has three tiers:

• Message header — identifies the reporting PSP, the reporting period and the recipient member-state tax authority.
• Reporting PSP block — the PSP’s BIC, country and identifier.
• Reported transactions — one element per reportable payment, repeated for as many records as exist in the reporting period.

Each transaction element carries the payee block, the payment block, and the optional refund linkage block.

3. Mapping a pacs.008 credit transfer, field by field

SEPA credit transfers travel as ISO 20022 pacs.008 (FIToFICstmrCdtTrf) messages between PSPs. The mapping into CESOP fields, from the payee’s PSP perspective:

4. Refunds — the pacs.002 / pacs.004 link

For SEPA, refunds and reversals come as pacs.004 (PaymentReturn) messages or pacs.002 (FIToFIPaymentStatusReport) for cancellations. Both carry an OrgnlEndToEndId referencing the original payment. In the CESOP record the refund flag is set, the refund amount populated, and the original record’s identifier referenced. Because refunds can cross a quarter boundary — the original in Q1, the refund in Q2 — your pipeline has to be able to reference a record it reported in an earlier period, not just the current batch.

5. The 25-payment threshold — applied at output, not intake

CESOP requires reporting of every cross-border payment to a payee that received more than 25 cross-border payments from your PSP in the quarter. The implication for the data pipeline:

• You cannot decide reportability in real time — you need a quarterly aggregation step that counts cross-border payments per payee.
• Once a payee crosses the threshold in a quarter, every cross-border payment to that payee in that quarter is reportable, including the first 25.
• The aggregation runs at the level of payee identifier — typically IBAN or, where present, VAT number. Pick a stable identifier and document it.

6. Determining the payee’s member state

CESOP wants the member state where the payee is located. For SEPA, this is derived from:

• The IBAN country code (positions 1–2) — the country of the account.
• The BIC’s country (positions 5–6) — the country of the payee’s PSP.

The two usually agree. They diverge where a PSP serves customers across borders — for example, a PSP in one member state holding an IBAN issued in another for a resident there. The guidance is to use the account identifier’s country as the primary signal, but the point that matters operationally is: pick a documented rule and apply it consistently across every reporting period, because inconsistency between quarters is what triggers tax-authority queries.

7. Validation gotchas

Most CESOP submissions that fail validation fail for one of three reasons:

• Date format. CESOP wants ISO 8601 in the schema’s specific tightenings. A pacs.008 date that looks valid can be rejected on a CESOP namespace check.
• Country codes. ISO 3166-1 alpha-2 throughout. Three-letter codes from internal systems will fail.
• Empty optional blocks. Optional fields must be omitted, not present-with-empty. A self-closing tag in place of an absent VAT number breaks validation.

8. The multi-state submission problem

The CESOP schema produces one XML file per member state you report into. The obligation runs to each member state where your reporting duty is triggered — for a PSP under Freedom of Services this can be many, depending on reach. Each member state’s tax authority operates its own portal with its own credentials and its own acknowledgement format; the XML body follows the common schema but the wrapper and authentication differ per portal. In Spain this is the Modelo 379 filing at the AEAT; the build/buy/hybrid choice is discussed in our CESOP overview.

9. Worked examples

Facts: An EMI’s settlement bus carries a SEPA SCT to a merchant with a French IBAN and a French payee BIC, one of 40 such payments in the quarter from EU payers.

What the rule says: The payee’s PSP is in the EU, so the reporting duty sits with it; 40 > 25, so all 40 are reportable. Member-state-of-payee resolves to France on both the IBAN and BIC signals.

What the practitioner does: The quarterly aggregation flags the payee at count 26, all 40 records are emitted with the SEPA-credit-transfer method code, and the file is validated against the current XSD before submission through the French portal.

Facts: A payment in the same batch has an IBAN country code of ES but a payee BIC resolving to Portugal — the account was opened at a PSP operating cross-border.

What the rule says: The two location signals disagree; CESOP still needs one member-state-of-payee value, applied consistently.

What the practitioner does: Applies the documented tie-break rule (account-identifier country as primary), records ES as the member state, and logs the divergence for the data-quality review rather than silently overwriting one signal with the other.

Facts: A merchant reported with 30 payments in Q1 receives a single refund in Q2, sent as a pacs.004 carrying the original EndToEndId.

What the rule says: Because the original was reportable, the refund is reportable; the refund record must reference the original transaction’s identifier so the central system pairs them.

What the practitioner does: The Q2 pipeline looks up the identifier reported for the original in Q1, emits a refund-flagged record referencing it, and does not net the refund against the original — the two remain separate, linked records.

10. FAQ

11. What to do, today

• Pull a sample week of pacs.008 messages from your settlement bus and dry-map them through the table above.
• Confirm your payee-vs-payer PSP allocation logic first — it decides whether you report at all.
• Identify the fields that come from your customer master rather than the message — those are the longest data-quality work.
• Build the quarterly threshold aggregation as a batch step before the XML generator, not inside it, and make it able to reference records from earlier quarters for refunds.
• Validate against the published XSD before sending, on every submission cycle, and re-check the schema version each quarter.

Related: What is CESOP reporting? · CESOP reporting in Spain (Modelo 379) · CESOP reporting in the Netherlands · CESOP data and system readiness