Belastingdienst CESOP Specifications: XSD 4.04 From 29 December 2026

On 28 October 2026 the Belastingdienst’s Ondersteuning Digitaal Berichtenverkeer (ODB) published new PSP_CESOP specifications for payment service providers reporting cross-border payment data to the Netherlands, to be implemented on 29 December 2026 for all reports and corrections. The new Belastingdienst CESOP specifications move the message to CESOP XSD version 4.04, and the version attribute must read 4.04 or the message is rejected.

The package is release MAN_PSPNL_R3.0 (product overview version 20). It adds optional address, email and webpage fields for the sending and reporting PSP, replaces currency code ANG with XCG, introduces validation warnings in CESOP’s response, and adds four business rules that warn without rejecting. The ValidatieTestService (VTS), the Belastingdienst’s test service for software developers, has not yet been updated; the ODB will announce the update on its website.

Related reading: CESOP Reporting Explained

Dates in the Belastingdienst CESOP specifications release

• 15 October 2026: version 4.0 of the known-error list marks issue 0006, the missing XCG code in isotypes.xsd, as solved.
• 26 October 2026: date of the release notes and of version 3.0 of Part 2 (Specification Data File) and Part 3 (Validation Report).
• 28 October 2026: ODB notice and product overview version 20 published, with every product in one ZIP file.
• 29 December 2026: the new specifications and XSD must be used, for all reports and corrections.
• 31 January 2027: by my calculation from the end-of-following-month deadline, the due date for Q4 2026, the first quarterly report that can only be filed after the cut-over.

Legal basis: the obligation behind the PSP_CESOP file

Release R3.0 changes the message. The duty to send it still comes from Council Directive (EU) 2020/284, which amended the VAT Directive with record-keeping obligations for payment service providers, and from Council Regulation (EU) 2020/283, which inserted Article 24b into Regulation (EU) No 904/2010. Article 24b requires each Member State to collect the Article 243b information from payment service providers by the end of the month following the calendar quarter, using an electronic standard form. The Netherlands transposed the directive in Chapter VI, Section 6 (Articles 39a to 39d) of the Wet op de omzetbelasting 1968, applicable from 1 January 2024.

The threshold and the allocation between PSPs are unchanged. Reporting starts at more than 25 cross-border payments to the same payee in a calendar quarter, which the Belastingdienst’s Part 1 manual places in Article 39b(3). Where the payer’s and the payee’s PSPs sit in different Member States, the payee’s PSP reports; where no PSP of the payee is established in a Member State, the payer’s PSP reports (Article 39b(5), as reproduced in the Part 1 manual).

What changes in the PSP_CESOP message

The release notes name PaymentData.xsd and isotypes.xsd as the schemas that must be used; the product overview also lists commontypes.xsd as changed and Responsemessage 2012.1.xsd, used for technical errors and acknowledgements, as unchanged. MAN_PSPNL 3.0 corresponds to CESOP Functional Specifications v15.0, CESOP Technical Specifications v18.00, XSD 4.04 and XSD User Guide 7.00; its predecessor, MAN_PSPNL 2.3, mapped to XSD 4.03.

Corrections filed from 29 December

The ODB notice applies the release to corrections as well as reports. Part 2 describes a correction (MessageTypeIndic CESOP101, with CorrMessageRefId pointing at the accepted original) as having essentially the same structure as an initial message and following the same schema. Read together, the two imply that a correction to Q3 2026 or any earlier quarter, sent on or after 29 December, is built on XSD 4.04 even though the file it corrects went in under 4.03. Neither document carves out older reporting periods.

Part 2 quotes the EU CESOP reporting guidelines’ recommended 30-day resubmission term, counted from when the Belastingdienst sends the validation report, so a partial rejection received in early December can push the correction past the cut-over. Part 2 also allows a correction only after the Belastingdienst has accepted the prior delivery; while that delivery remains rejected, for example for not complying with the XSD, its data goes back in as an initial CESOP100 delivery.

At the CESOP stage, Part 3 section 2.3.3 has a FULLY REJECTED Payment Data message resubmitted as a new CESOP100, whereas a PARTIALLY REJECTED one requires a CESOP101 correction for the affected payees. Its wording does not address a CESOP101 correction that is itself fully rejected, which is a separate case. The Finnish Tax Administration’s CESOP technical guidance (version 2.0, 14 January 2026) covers that case: the replacement stays a correction with the same CorrMessageRefId and CorrDocRefIds, pointing at the initial report and payee data. The Dutch treatment of a rejected correction, at either stage, is a question for the ODB servicedesk.

ANG to XCG in the currency attribute

Following the introduction of the Caribbean guilder, XSD 4.04 removes ANG (Netherlands Antillean guilder) from the permitted values of Amount/@currency and adds XCG. The release notes limit the switch to 4.04: files built on XSD 4.02 or 4.03 must keep using ANG, and XCG is not permitted in them. Known error 0006, logged on 27 August 2025, recorded that XCG was missing from isotypes.xsd and that ANG still had to be provided; version 4.0 of the list marks it solved on 15 October 2026.

A payment engine that already books Caribbean guilder amounts as XCG therefore needs to map them to ANG in any 4.03 file sent before 29 December, and can pass XCG through from that date. The release notes do not say how an amount originally reported as ANG should be expressed in a 4.04 correction, which is a question to put to the ODB servicedesk before the first such correction is due.

Optional PSP fields that are still checked

XSD 4.04 adds Address, EmailAddress and WebPage to the PSP type used for both SendingPSP and ReportingPSP, each with cardinality 0..n. Where an address is given, it must contain either AddressFix or AddressFree, and Part 2 states a preference for the structured AddressFix format. SendingPSP itself is omitted when the sending and reporting PSP are the same entity.

Leaving the new fields empty raises nothing. Populating them badly does: business rule 40160 requires the WebPage element to be in a valid and recognisable website address format, which Part 2 spells out as no whitespace, at least five characters, at least one dot, and at least one character before and after the dot. The change log attaches 40160 to the payee’s WebPage as well as the two new PSP fields, so web addresses reported for payees are checked too.

Validation warnings and the four new business rules

From XSD 4.04, a Validation Result from CESOP can carry warnings next to errors. A result of VALIDATED may contain one or more warnings; Part 3 states that the data is accepted and stored, that warnings are provided for information only, and that they do not require a new or corrective Payment Data message. Each warning carries WarningCode, WarningCounter, WarningShortDesc, WarningDescription and, where relevant, TransactionIdentifier and DocRefId. CESOP reports at most 5,000 warnings per message and then adds code 50090, so a single Validation Result can hold 5,001.

“Information only” describes the filing outcome. Part 3 also says that CESOP stores the warnings and that Member States may use them to inform PSPs about potential data quality issues, so a recurring 40140 on IOSS numbers is visible to the tax side even though the quarter was accepted. Our guide to EU e-commerce VAT under OSS and IOSS covers the scheme behind those IOSS numbers; the note on CESOP filing errors and fixes covers rejections. Warnings only appear for 4.04 messages: Part 3 notes that the Validation Result uses the XSD version of the original submission, and earlier versions cannot carry them.

Rules 20130 and 20140: the PSPRoleOther check changes code

According to the change log, the check that PSPRoleOther is provided when the PSP role type is “Other” leaves 20130 and moves to 20140, for the transaction-level PSPRole and for the representative’s identifier (Representative/RepresentativeId); the release notes add that 20140 now covers the PSPId “Other” check for certain elements. Rule 20130 keeps the PSPIdOther check on the PSP block. The release notes state that the descriptions and the elements in scope changed, with no change to validation logic or implementation.

The Part 3 v3.0 table lists 20130 as a full rejection and 20140 as a partial rejection, so they lead to different resubmission paths. Exception routing keyed on error codes should expect these conditions under 20140 from the cut-over. Whether the rejection level attached to the moved checks differs from the previous version is a point the release notes do not address.

English-only documentation and the VTS gap

The Belastingdienst has stopped publishing Dutch versions of the PSP_CESOP manuals; the ODB notice in Dutch points readers to the English release notes. Parts 4 and 5 will no longer be published as separate manuals: the Part 4 examples now sit in section 2.7 of Part 2, and the Part 5 structure diagram is chapter 5 of Part 2.

Testing is the open item. The VTS, which checks generated XML against the applicable message and data specifications and requires a subscription, has its specifications for files from 29 December 2026 marked “Follows”. Test scenarios for Digipoort’s FTP interface are available through Logius’s Aansluit Suite Digipoort. Neither the notice nor the product overview gives a date for the VTS update.

Frequently Asked Questions

Does a quarter with no reportable payments need a 4.04 message?

Part 2 leaves that choice to the PSP: with no data to report in a quarter, it can submit a message with MessageTypeIndic CESOP102 or submit nothing. If a CESOP102 message is sent on or after 29 December 2026, it is a report under the ODB notice and would carry version 4.04 like any other file.

We report CESOP data in several Member States. Does 29 December 2026 apply to all of them?

The date and the release notes cover PSP_CESOP files sent to the Belastingdienst; each tax administration announces its own schema version and portal arrangements, as our CESOP reporting guide for Luxembourg payment providers shows for one of them. If another administration moves to 4.04 on a different date, a shared XML generator would need both versions in the gap.

Related Articles

• CESOP Reporting Explained: the quarterly payee data PSPs send to tax authorities for VAT control.
• CESOP 2026 Filing Errors and Fixes: CESOP validation errors and how to clear them before the deadline.
• CESOP Reporting in Luxembourg: The Quarterly PSP Filing to the AED: scope, thresholds, deadlines and MyGuichet.lu submission for Luxembourg PSPs.
• EU E-commerce VAT: OSS and IOSS Compliance: how the One-Stop Shop and Import One-Stop Shop handle VAT on cross-border e-commerce sales.

Key Takeaways

• Key the 4.03/4.04 switch to the submission date; as read above, that includes corrections to earlier quarters.
• Map Caribbean guilder amounts to ANG in 4.03 files and to XCG in 4.04 files, and agree the treatment of previously reported ANG amounts with the ODB servicedesk before the first 4.04 correction.
• Decide who owns the PSP Address, EmailAddress and WebPage values: the fields are optional, and a malformed WebPage draws warning 40160.
• Store ValidationWarnings from 4.04 responses next to errors; a VALIDATED result with warnings needs no resubmission, and CESOP keeps the warnings.
• Repoint error routing for a missing PSPRoleOther, or a representative’s PSPIdOther, from 20130 to 20140.

Sources and References

• Belastingdienst ODB, “Nieuwe specificaties voor PSP_CESOP”, 28 October 2026: odb.belastingdienst.nl
• Belastingdienst ODB, Payment Service Providers v20 (product page and version history): odb.belastingdienst.nl/en
• Belastingdienst ODB, Payment Service Providers (PSP) v20 ZIP (MAN_PSPNL_R3.0 release notes, Parts 1 to 3, change log, known-error list v4.0, product overview, XSD 4.04): Payment-Service-Providers-PSP-v20.zip
• Belastingdienst, “PSP-CESOP: EU-richtlijn voor gegevensuitwisseling betalingsdienstaanbieders”: belastingdienst.nl
• Wet op de omzetbelasting 1968, Chapter VI, Section 6 (Articles 39a to 39d): wetten.overheid.nl
• Council Directive (EU) 2020/284 of 18 February 2020 amending Directive 2006/112/EC as regards introducing certain requirements for payment service providers: EUR-Lex
• Council Regulation (EU) 2020/283 of 18 February 2020 amending Regulation (EU) No 904/2010 (Article 24b): EUR-Lex
• Belastingdienst ODB, “Test facilities for software developers”: odb.belastingdienst.nl/en
• Finnish Tax Administration, CESOP report technical guidance, version 2.0, 14 January 2026: vero.fi

Building the first 4.04 file before 31 January 2027

By the same calculation, the Q3 2026 report due by 31 October 2026 is the last scheduled quarter filed on XSD 4.03, and the Q4 2026 file is the first that can only go in on the new schema. Once the ODB announces the VTS update, developers can use the VTS to check the generated XML. The ODB’s test-facilities page treats the VTS as an XML validator and the Aansluit Suite Digipoort, whose responses are simulated, as a separate Digipoort connection test, so a VTS pass alone does not prove Digipoort delivery.

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.