CESOP 2026 Filing Season: Common Errors and How to Fix Them Before the 31 July Deadline

ByOfficer

Last updated: May 2026

A rejected CESOP file two days before the quarterly deadline is not a theoretical risk. I have seen it happen twice in the past year, both times caused by errors that were preventable with basic pre-submission checks. The Q2 2026 reporting period covers payments processed between 1 April and 30 June 2026, with the filing deadline falling on 31 July 2026. That gives Luxembourg PSPs roughly four weeks after quarter-end to extract, validate, and submit their XML files to the AED (Administration de l’Enregistrement, des Domaines et de la TVA) via MyGuichet.lu.

CESOP is now in its third year of operation. The first quarterly filing covered Q1 2024 and was due by 30 April 2024. By this point, most PSPs have filed at least eight quarterly returns. Yet the same categories of errors keep appearing in rejected files. This article walks through the most common CESOP filing errors I have encountered and observed across reporting teams, with concrete fixes you can apply before your next submission.

Related reading: CESOP Reporting Explained: What Payment Service Providers Need to Report

How the CESOP Filing Calendar Works

Under Article 243b of the VAT Directive (as amended by Council Directive (EU) 2020/284), PSPs must keep records of cross-border payments and transmit them to their home Member State’s tax authority. The transmission deadline is the end of the month following the calendar quarter. For 2026, the calendar looks like this:

  • Q1 2026 (January to March): due by 30 April 2026
  • Q2 2026 (April to June): due by 31 July 2026
  • Q3 2026 (July to September): due by 31 October 2026
  • Q4 2026 (October to December): due by 31 January 2027

For first-time filers in Luxembourg, the AED requires PSPs to complete a CESOP business eSpace certification on MyGuichet.lu before any payment data message can be uploaded. The certification requires a duly signed mandate and a recent extract from the Trade and Companies Register confirming the signatory’s authority to act for the legal person. Set up the eSpace well ahead of your first quarterly deadline. The certification is reviewed by the Luxembourg authorities and is not instant.

In Luxembourg, the AED receives CESOP data through MyGuichet.lu. PSPs upload XML files conforming to the official schema, and the AED performs a first-level validation before forwarding the data to the European Commission’s central CESOP database. The Commission then runs a second validation. A file can pass AED validation but still be rejected or partially rejected at the EU level.

Error 1: Miscounting the 25-Payment Threshold

The reporting obligation under Article 243b applies when a payee receives more than 25 cross-border payments in a single calendar quarter, with the count calculated per PSP per Member State of services provision (per Article 243b(2) second subparagraph). “More than 25” means 26 or above. I have seen teams misinterpret this in two ways.

First, counting 25 as the trigger. A payee with exactly 25 cross-border payments in a quarter is not reportable. The threshold is strictly “more than 25.” Over-reporting is not penalised in the same way as under-reporting, but it adds noise to the data and increases your file size unnecessarily.

Second, aggregating payments across quarters. The 25-payment count resets each calendar quarter. A payee who received 15 payments in Q1 and 12 in Q2 is below the threshold for both quarters, even though the total is 27. Each quarter is assessed independently.

What Teams Get Wrong

The default counting unit under the EC guidelines is the identifier (e.g., per IBAN). However, where the PSP has knowledge that two or more identifiers belong to the same payee (for example, two IBANs registered to the same legal entity through KYC records), the EC Q&A (Question 3.2.3) treats aggregation across those identifiers as a best-effort obligation. The trap is in the knowledge condition: if you have the data to link multiple identifiers to the same payee but did not aggregate, that is the error.

Fix: where your KYC data supports linking identifiers to a common payee, aggregate before applying the 25-payment threshold. Document your aggregation methodology. The EC has framed this as best-effort, so a documented approach is the practitioner’s best defence. Run a reconciliation each quarter comparing per-IBAN counts against per-entity counts where the link is known, and flag any payee entity where the aggregated count exceeds 25 but no single IBAN does.

Error 2: Wrong Payee Location Determination

CESOP requires PSPs to determine whether a payment is cross-border by comparing the payer’s location to the payee’s location. A payment is cross-border when the payer is in one EU Member State and the payee is in a different country (EU or non-EU). Getting the location wrong means either missing reportable payments or reporting domestic ones.

The regulation specifies a hierarchy for determining location:

  1. Primary rule: use the IBAN of the payer’s or payee’s payment account, or any other identifier that unambiguously identifies and gives the location.
  2. Fallback rule: if no IBAN or equivalent identifier is available, use the BIC or any other business identifier code that unambiguously identifies and gives the location of the PSP acting on behalf of the payer or payee.

What Teams Get Wrong

Card-based payments are the most common source of location errors. When a cardholder pays a merchant in another country, the cardholder’s location is often determined from the card issuer’s BIC rather than a direct account identifier. If the acquiring PSP does not have visibility into the cardholder’s IBAN, it defaults to the issuer BIC. Mistakes here include using the acquirer’s own BIC (which reflects the PSP’s location, not the payer’s) or using an outdated BIC directory.

More fundamentally, in many card payment configurations the issuer (payer’s PSP) is not the reporting party. Where both the payer’s PSP (issuer) and the payee’s PSP (acquirer) are in the EU, the payee’s PSP carries the reporting obligation and the payer’s PSP is generally relieved. The issuer-BIC question primarily becomes relevant when the acquirer is outside the EU, when location must be inferred from issuer data. Teams that overcomplicate location determination for routine intra-EU card payments are often solving a problem they don’t have.

Fix: maintain a current BIC directory mapping (ISO 9362). Cross-check your BIC-to-country mapping at least once per quarter. For card transactions where payer IBAN is unavailable, document your fallback methodology and ensure it aligns with the European Commission’s CESOP reporting guidelines.

Error 3: XML Schema Validation Failures

CESOP files must comply with the official XSD schema. As of early 2026, XSD schema v4.03 is the current schema definition. The User Guide version a PSP should use depends on the reporting Member State and on the CESOP central system’s support stage. User Guide v6.00 is the latest published, but Member States have moved to it on different timelines (some still operate on User Guide v5.00). For Luxembourg, confirm the applicable User Guide version with the AED via MyGuichet.lu before each quarterly submission. The European Commission also publishes a Validation Module that should be the version aligned with your Member State’s current support stage.

Common Schema Errors

MessageRefId format violations. The MessageRefId must be unique per submission. I have seen teams reuse the same MessageRefId across quarters, or use a format that does not match the expected pattern. Each national tax authority may have its own MessageRefId formatting expectations on top of the EU-level requirements.

Incorrect ReportingPeriod element. The quarter must be expressed as the last day of the reporting quarter (for example, 2026-06-30 for Q2 2026). Teams sometimes enter the first day of the quarter, the submission date, or the deadline date instead.

Missing or malformed BIC codes in the PSP identification fields. The reporting PSP’s BIC must be a valid 8 or 11-character ISO 9362 code. Submitting an invalid or decommissioned BIC will cause the file to fail schema validation before any business-rule checks even run.

Fix: download the latest CESOP Validation Module from the European Commission’s CESOP technical documentation page. Run every file through this validator locally before uploading to MyGuichet.lu. The validation module catches schema-level errors instantly. If your team does not use it, this is the single highest-value change you can make to your filing process.

Error 4: Payee Name and Identifier Mismatches

Article 243d of the VAT Directive requires the file to include the name or business name of the payee and, if available, the VAT identification number or other national tax number of the payee. In practice, PSPs often hold the payee’s name as it appears on the payment instruction, which may differ from the legal name registered for VAT purposes.

What Teams Get Wrong

Truncated or abbreviated names. The XML schema has character limits for the payee name field. When a PSP’s internal system stores longer names than the schema allows, automated truncation can produce names that no longer match the payee’s actual identity. A payment to “Luxembourg International Trading Company S.a r.l.” might be truncated to “Luxembourg Internation” in the file.

VAT ID formatting inconsistencies. Some teams include the country prefix (LU followed by 8 digits for Luxembourg), others omit it. The CESOP schema expects the VAT identification number in a specific format. Submitting “12345678” instead of “LU12345678” will not cause a schema rejection in all cases, but it degrades data quality and may trigger follow-up queries from the tax authority.

Fix: run a pre-submission name-length check against the schema’s maxLength constraint. For VAT IDs, standardise the format to always include the two-letter country prefix followed by the national identifier. Validate VAT ID formats against the expected patterns for each EU Member State using the VIES (VAT Information Exchange System) format specifications.

Error 5: Incorrect Handling of Refunds and Returns

Refunds are a persistent source of confusion in CESOP reporting. When a payee returns funds to a payer (for example, an e-commerce merchant issuing a refund to a consumer), the reporting treatment depends on whether the refund constitutes a separate payment or a reversal of the original transaction.

Industry practice, consistent with the EC guidelines and Q&A, treats refunds processed as new payment transactions (i.e., a separately initiated payment from the original payee back to the original payer) as reportable in their own right if they meet the cross-border and threshold criteria. Refunds that are processed as reversals of the original transaction (for example, a chargeback that cancels the original payment) are not separate payment events and should not be reported as new transactions. Refer to the EC guidelines and Q&A for borderline cases.

What Teams Get Wrong

Double-counting. Some PSPs report both the original payment and a separately initiated refund, which is correct, but then also report the refund as a negative amount on the original payee’s record. This creates an inconsistency where the refund appears twice in the data.

Netting. Other teams net refunds against gross payments before applying the 25-payment threshold. A payee with 30 gross payments and 6 refunds has 30 reportable payments (assuming the refunds are separate transactions). Netting them to 24 would incorrectly bring the payee below the threshold.

Fix: treat refund transactions as independent payment events for threshold-counting purposes. Report them separately if they meet the cross-border criteria. Never net refunds against gross payment counts when determining whether the 25-payment threshold is met.

Error 6: Multi-Member State Filing Confusion

Under Article 243b(4), PSPs must report to their home Member State. However, if a PSP provides payment services in host Member States through branches or agents, the PSP may also need to file in those host states. The exact filing obligation depends on the Member State’s implementation of the directive.

In Luxembourg, a PSP licensed by the CSSF and providing services cross-border under passporting arrangements reports to the AED. But if that same PSP has a branch in Germany, the branch’s payment data may need to be reported to the German BZSt (Bundeszentralamt fur Steuern) rather than to the AED.

What Teams Get Wrong

Filing all data to the home state only. PSPs operating in multiple Member States sometimes submit a single consolidated file to their home state, assuming the home state will distribute the data. The regulation does not work this way. Each Member State’s tax authority expects to receive data for payment services provided within its jurisdiction.

Fix: map your payment services footprint by Member State. For each state where you provide payment services (whether through passporting, branches, or agents), confirm the local filing requirements directly with the national tax authority. Prepare separate XML files per Member State where required.

Error 7: Correction and Amendment File Errors

When a PSP discovers an error in a previously submitted file, it must submit a correction. The CESOP XML schema provides mechanisms for corrections: a new file referencing the original MessageRefId with corrected data. Getting the correction methodology wrong can create duplicate records in the central CESOP database or fail to replace the erroneous data.

What Teams Get Wrong

Mishandling the MessageTypeIndic and DocTypeIndic codes for corrections. The CESOP correction workflow uses specific code combinations depending on whether the correction is in response to a national-level rejection, an EU-level partial rejection, or a spontaneous correction. The XSD User Guide (section 3.3.3) and section 5 of the EC guidelines describe the correct sequencing. Treating every correction as a full file replacement can overwrite previously accepted records; sending corrections without the right indicator codes can leave erroneous records intact alongside the new ones.

Incorrect use of the CorrMessageRefId field. The correction file must reference the MessageRefId of the original submission, not the MessageRefId of a previous correction. If a file has been corrected once already, a second correction still references the original MessageRefId.

Fix: document your correction workflow before you need it. Test the correction submission process with your national tax authority’s test environment (most Member States, including Luxembourg, provide one). Keep a log of all MessageRefIds per quarter so corrections can be linked accurately.

Error 8: Nil Reporting Omissions

When a PSP has no reportable payments in a given quarter (no payee exceeded the 25-payment threshold), the question is whether to submit a nil report. Under Article 243b(4)(b) of the VAT Directive, nil reporting cannot be made mandatory and is voluntary. The EC Q&A (Question 5.5) confirms this position. The XSD schema includes a ‘No Payment Data Message’ construct for PSPs that choose to file a nil submission.

Several national tax authorities (Germany BZSt, Czech Republic, Sweden, Ireland) explicitly recommend nil reporting as best practice. The Luxembourg Guichet.lu CESOP page does not contain an equivalent recommendation, but submitting a nil report still provides documented evidence that the PSP assessed its obligations for the quarter.

Fix: configure your extraction process to generate a valid nil-report XML when the threshold is not met for any payee. Submitting a nil report is a low-cost way to maintain a complete audit trail of quarterly obligation assessments, even where it is not legally required.

Pre-Submission Checklist for Q2 2026

Based on the errors above, I run through this checklist before every quarterly CESOP submission. I started doing this after the second rejected file and have not had a rejection since.

  1. Confirm you are using XSD schema v4.03 and the User Guide / Validation Module version applicable to your reporting Member State (for Luxembourg, confirmed via MyGuichet.lu). Check the European Commission’s CESOP technical documentation page and your national tax authority’s CESOP page for any updates published after the quarter-end.
  2. Run your generated XML file through the CESOP Validation Module locally. Fix all schema errors before uploading.
  3. Verify the 25-payment threshold is counted per identifier (per IBAN) per PSP per Member State, with aggregation across identifiers as a best-effort obligation where you have knowledge they belong to the same payee. Run a reconciliation report.
  4. Check that payee locations are determined using the correct hierarchy: IBAN first, BIC fallback. Verify your BIC directory is current.
  5. Confirm the ReportingPeriod element shows 2026-06-30 (the last day of Q2), not the submission date or deadline date.
  6. Ensure the MessageRefId is unique and follows your national tax authority’s formatting expectations.
  7. Verify payee names are not truncated and VAT IDs include the country prefix.
  8. Check that refunds are not netted against gross payments in the threshold count.
  9. If operating in multiple Member States, confirm separate files are prepared for each jurisdiction.
  10. If no payees exceed the threshold, prepare and submit a nil report.

Frequently Asked Questions

What is the CESOP filing deadline for Q2 2026?

The deadline is 31 July 2026. Under Article 243b of the VAT Directive (as amended by Directive 2020/284), PSPs must transmit quarterly payment records by the end of the month following the calendar quarter. Q2 2026 covers April to June, so the deadline is the last day of July.

Which PSPs are subject to CESOP reporting in Luxembourg?

All payment service providers as defined under PSD2 that are authorised or registered in Luxembourg. This includes credit institutions, payment institutions, e-money institutions, and post office giro institutions. The AED is the receiving authority, and submissions go through MyGuichet.lu.

How does the 25-payment threshold work?

The threshold applies per payee per quarter. If a single payee receives more than 25 cross-border payments in a calendar quarter (that is, 26 or more), all payments to that payee in that quarter become reportable. The count resets each quarter. Where the PSP has knowledge that multiple identifiers belong to the same payee, payments across those identifiers should be aggregated as a best-effort obligation per the EC Q&A.

What happens if my CESOP file is rejected?

Rejection can occur at two levels. The AED performs an initial validation when you upload to MyGuichet.lu. If the file fails, you receive an error notification in your MyGuichet.lu business eSpace. If the file passes national validation but fails at the EU CESOP level, the European Commission returns a rejection or partial rejection status. In either case, you must correct the errors and resubmit. There is no automatic grace period for late resubmission after a rejection.

Do I need to submit a nil report if I have no reportable data?

No. Under Article 243b(4)(b) of the VAT Directive, nil reporting cannot be made mandatory and is voluntary. The EC Q&A (Question 5.5) confirms this. Several national tax authorities recommend nil reporting as best practice, and the XSD schema supports a ‘No Payment Data Message’ for PSPs that choose to submit one. Submitting a nil report provides documented evidence that you assessed your obligation for the quarter.

What XML schema version should I use for Q2 2026 filing?

As of early 2026, XSD schema v4.03 is the current schema. User Guide version support varies by Member State and CESOP central system stage. v6.00 is the latest published version, but some Member States still operate on v5.00. For Luxembourg filings, confirm the applicable User Guide and Validation Module versions with the AED via MyGuichet.lu before submission.

How do I correct errors in a previously submitted CESOP file?

Submit a correction file using the CESOP XML correction mechanism. The correction file must reference the original submission’s MessageRefId in the CorrMessageRefId field. Use the correct MessageTypeIndic and DocTypeIndic codes for your correction scenario (national rejection, EU-level partial rejection, or spontaneous correction) as described in XSD User Guide section 3.3.3. Test corrections in the available test environment before submitting to production.

Does CESOP reporting apply to domestic payments?

No. CESOP only covers cross-border payments where the payer is located in an EU Member State and the payee is in a different country. Payments where both payer and payee are in the same Member State are not reportable under CESOP.

Related Articles

Key Takeaways

  • The Q2 2026 CESOP filing deadline is 31 July 2026. PSPs report to the AED in Luxembourg via MyGuichet.lu.
  • The 25-payment threshold is counted per identifier (typically per IBAN) per PSP per Member State per quarter. Aggregation across multiple identifiers belonging to the same payee is a best-effort obligation under the EC Q&A, applicable where the PSP has knowledge that the identifiers refer to the same payee.
  • Payee location must follow the regulation’s hierarchy: IBAN first, BIC fallback. Using the wrong identifier, especially for card payments, is a frequent source of misclassification.
  • Always validate XML files locally using the CESOP Validation Module before uploading. The current XSD schema is version 4.03.
  • Refunds and reversals have distinct reporting treatments. Never net refunds against gross payment counts when assessing the 25-payment threshold.
  • PSPs operating across multiple EU Member States may need to file separately in each jurisdiction, not only the home state.
  • Correction files must use the correct MessageTypeIndic and DocTypeIndic codes for the correction scenario, and reference the original MessageRefId.
  • Nil reporting is voluntary under Article 243b(4)(b), but submitting one provides documented evidence of quarterly obligation assessment.

Sources and References

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.

Similar Posts