How to report CESOP in the Netherlands — step by step

CESOP reporting in the Netherlands runs on its own technical rail — and it is not the same one that handles your DNB supervisory returns. The Belastingdienst (Dutch Tax and Customs Administration) ingests CESOP filings through Digipoort, the government’s data-exchange platform operated by Logius. Submission is automated XML only — no manual upload, no portal form. Connection requires a PKIoverheid certificate, which non-Dutch entities cannot purchase directly. This piece walks through the five practical steps to file CESOP in the Netherlands, what each requires operationally, and the specific traps for foreign-licensed PSPs reporting from abroad.

1. Recap — what CESOP is

The Central Electronic System Of Payment information (CESOP) is the EU’s quarterly cross-border payments register, established by Regulation (EU) 2022/1504. PSPs in scope file payee-side data on cross-border transactions to each member state where the payment legs touch. For Dutch-attributable activity, the receiving authority is the Belastingdienst. For the XML mapping from SEPA pacs.008 to the CESOP schema, see our schema-mapping piece.

2. Digipoort — the channel

Digipoort is the Dutch government’s data-exchange platform — the same infrastructure used for VAT returns, corporate tax filings and other regulated digital submissions to the Belastingdienst. CESOP uses Digipoort’s File Exchange FTP interface. Submission is fully automated; there is no web form for manual upload.

3. Step 1 — determine whether you are in scope

Before any technical work, confirm the reporting obligation applies to your firm. The Belastingdienst publishes the in-scope criteria on its dedicated PSP-CESOP page. For most credit institutions, EMIs and PIs with Dutch-attributable cross-border activity above the 25-payments-per-payee-per-quarter threshold, the answer is yes.

Source: belastingdienst.nl publishes the formal criteria. Read those, document your conclusion, and engage the Belastingdienst PSP-CESOP team before drafting the report if there is genuine ambiguity about scope.

4. Step 2 — build, buy or develop the XML generator

The CESOP report is a structured XML file. You need software that:

• Reads your payments warehouse and identifies in-scope transactions
• Applies the 25-payment per-payee per-quarter aggregation logic
• Generates the CESOP XML against the published schema
• Validates the file before submission

Three operating models:

• Buy — a regulated-reporting vendor handles XML generation and submission
• Build in-house — your engineering team builds against the published specifications
• Hybrid — internal data layer, external boundary integration

If you go the build route, register on the Belastingdienst’s ODB (Ontwikkelaars en Dienstverleners van Belastingdienst) site. Registration unlocks access to the current technical specifications, the Validation Test Service, the Belastingdienst service desk, and the news-release subscription for CESOP-related updates.

5. Step 3 — validate test messages

The Belastingdienst operates a Validation Test Service (VTS) — a separate sandbox where you can submit test XML files and receive structured validation feedback before going live. VTS access is granted through the ODB registration.

Two things matter operationally:

• The VTS runs the same validation rules as the production endpoint — passing in VTS is a reliable indicator of production acceptance
• The VTS is the only sandbox available to you; the Digipoort pre-production environment is reserved for Belastingdienst internal testing and is not accessible for PSP file rehearsal

6. Step 4 — connect to Digipoort

Connecting to Digipoort requires:

• A PKIoverheid certificate — the Dutch government’s digital-passport infrastructure, issued by accredited Trust Service Providers (TSPs)
• Implementation of the Digipoort File Exchange FTP interface (Bestandsuitwisseling FTP v1.6.1 at the time of writing)
• Submission of the metafile alongside each data file, per the PSP-CESOP metafile specifications

The production submission address for CESOP filings is bld-lpsp@ftp.procesinfrastructuur.nl.

7. The foreign-PSP PKI problem

Three workable solutions for a foreign-licensed PSP with Dutch CESOP-reporting obligations:

• Establish a Dutch branch with a KvK registration — the heaviest option, but the cleanest. The branch obtains the certificate in its own right.
• Appoint a General Fiscal Representative in the Netherlands — a regulated tax-representative service that holds the Dutch presence on your behalf. The representative obtains the certificate and files CESOP on your behalf. Common operating model for cross-border VAT obligations; transfers cleanly to CESOP.
• Use a tax or technical service provider — a third party that holds the PKIoverheid certificate and acts as the submission intermediary. The provider sits between your XML generator and Digipoort.

The choice is structural. If you already use a fiscal representative for VAT obligations in the Netherlands, extending the mandate to CESOP is the lowest-friction path. If you have no Dutch presence and no representative, the choice between establishing a branch and engaging a service provider is a function of overall Dutch market strategy — see our branch vs Freedom of Services piece for the wider framework.

8. Step 5 — run end-to-end test exchanges

Before going live, run the two published test scenarios in Logius’s Aansluit Suite Digipoort (ASD):

• Scenario 16 (happy flow) — submit a valid data file and metafile to the ASD test receiver address. Expected outcome: successful Digipoort acceptance, successful Belastingdienst delivery, processing report flagged VALIDATED.
• Scenario 17 (invalid XML) — submit a deliberately invalid file. Expected outcome: Digipoort accepts the transfer, Belastingdienst rejects the content, processing report flagged FULLY_REJECTED.

Both scenarios exercise the end-to-end pipeline — your XML generator, your PKIoverheid certificate, your Digipoort FTP integration, and the metafile structure. Running both before the first live submission is the standard operational discipline.

9. Reading the processing report

Every CESOP submission returns a processing report from the Belastingdienst:

• VALIDATED — accepted, ingested, no further action required
• FULLY_REJECTED — the entire file failed validation; correct and resubmit
• Partial-acceptance states — defined per the ODB specifications, with clear remediation paths

Processing reports are delivered through the same Digipoort channel. Your case-management system needs to ingest them and trigger remediation workflows automatically — manual polling does not scale beyond a handful of submissions per quarter.

10. VTS vs production — two distinct environments

11. The multi-state submission problem (still applies)

Even with a clean Dutch Digipoort setup, the CESOP obligation runs per member state where you have a payment leg. Filing the Dutch slice through Digipoort does not discharge your obligation to file the French, German, Italian or Spanish slices through their respective national channels. Each member state runs its own portal with its own credentials. This is the structural Freedom-of-Services cost covered in our CESOP overview.

12. FAQ

13. What to do, today

• Confirm your scope against the Belastingdienst PSP-CESOP criteria and document the conclusion.
• Register on the ODB site early — VTS access and current specifications gate the development work.
• If you are a foreign-licensed PSP, decide between a Dutch branch, a General Fiscal Representative, or a service-provider intermediary before starting the PKIoverheid certificate process.
• Build the XML generator against the published specifications; validate continuously in the VTS.
• Run both test scenarios (16 happy flow, 17 fully rejected) before the first live submission.
• Build the processing-report ingestion as an automated step in your case-management system.
• Plan multi-state CESOP coverage in parallel — Digipoort handles the Dutch slice only.

Related: What is CESOP reporting? · CESOP XML schema mapping · DNB DLR — Dutch supervisory reporting channel