Submitting CbC via Digipoort: Why There Is No Standard Entry Point

Anyone submitting a Country-by-Country report to the Tax Authority for the first time will sooner or later run into the same obstacle: submissions are made via Digipoort, but there is no directly accessible entry point like the one for the Chamber of Commerce annual financial statements. For tax firms and accounting firms that handle this on behalf of multiple multinational clients , this is not a rare occurrence. It is the core of the problem.

This blog explains how CbC submission works from a technical standpoint, why Digipoort operates differently here than it does for SBR annual financial statements, and which three approaches you can take in practice to makethe process workable .

How CbC istechnically submittedto the Tax Authority

CbC is submitted in XML, based on the OECD schema as implemented by the DutchTax Authority. For each jurisdiction , the file contains data on revenue, pre-tax profit, income tax paid and due, issued capital, retained earnings, number of employees, and tangible assets. Technically ,the submission takes place via Digipoort, the government ’s generic messaging channel for structured data exchange.

So far, nothing out of the ordinary. However, with SBR data flows such as the Chamber of Commerce annual financial statements, the submitting party can connect via an SBR software package with a known connection to Digipoort. With CbC, the situation is different.

Why There IsNo Standard Entry Point

Digipoortuses entry points for each reporting stream. For SBR annual financial statements (Chamber of Commerce), DORA reports (AFM/DNB) , and various tax returns , these entry points are publicly documented. Software vendors know exactly which connection point to use, which message formats apply , and which confirmation flows to expect in return.

For CbC, this public documentation is not available in the same way. The Tax and Customs Administration does receive the reports via Digipoort, but the connection is not set up as an open SBR channel that any party can subscribe to . In practice, this means that anyone wishing to build their own technical connection must follow a longer and more specific process than is customarywith SBR .

This is not a matter of unwillingness, but of policy. CbC involves confidential tax information subject to specific exchange agreements between tax authorities. Access is therefore more strictly defined than for public filings.

The three routes firms currently use

In practice, we see three ways in which tax offices and accounting firms handle their CbC submissions. Each route has its own trade-offs.

Approach 1: Build a Digipoort connection in-house

Some firms choose to implement the technical connection themselves . This requires a certificate infrastructure (PKIoverheid), agreements with the Tax and Customs Administration regarding submissions, and an in-house validation and logging environment.

Feasible? Yes, it’s technically possible. Cost-effective? Only if you have a significant volume of submissions and can maintain the necessary expertise in-house . For a firm submitting data on behalf of five to twenty clients , the costs and administrative burden are generally out of proportion to the volume. Furthermore ,any schema changes from the Tax Authority fall entirely on your shoulders.

Option 2: Have the client submit the data themselves

Some firms provide the validated XML to their clients and let them handle the filing themselves . In theory , this shifts the technical burden away from you. In practice ,however ,it creates a gray area: if something goes wrong during submission, who is responsible? And if the Tax Authority asks , how do you determine exactlywhich version was sent?

This approach works for large multinationals with strong internal tax and IT functions. For most firms’ client portfolios , it is not a sustainable solution. Clients choose a tax firm precisely because they do not want to bearthe compliance burden themselves .

Option 3: Submission via a service provider with an existing integration

The third approach is to partner with a provider that already has the Digipoort integration for CbC up and running . You submit the validated XML to a portal; the service provider handles the actual submission, validation against the schema , and feedback to you.

The trade-off here lies primarily in the choice of service provider: does that provider have a true technical integration or just a manual upload screen? Is the audit trail for each report usable in a client file? And can you work for multiple clients in a single environment without mixing upaccess rights ?

What to Check When Evaluating a Service Provider

If you ’re considering Route 3 , these are the questions you should askduring an initial meeting:

• Is the Digipoort integration for CbC actually operational or still under development?
• Is the XML validated against the Tax Authority’scurrent CbC schema before submission ?
• Does the Tax Authority ’s acknowledgment of receipt appear in the portal, visible for each report?
• Can you work for multiple clients within a single account , with separate permissions and files?
• Is every change recorded in an audit trail that you can presentduring an audit ?
• What happens when the Tax Authority updates the schema : does the service provider process these changes automatically, or do youhave to take action yourself?

Anyone who doesn’t receive concrete answers to these six points is choosing a service provider that, for CbC, essentially relies on Route 2 with a small portal on top of it.

Where SureSync fits in

SureSync provides Route 3 for CbC: validated submission to the Tax Authority via an operational Digipoort connection, all within a single portal where tax offices and accounting firms can work for multiple clients. Each submission is validated against the applicable CbC schema, status updates are displayed in the portal, and the audit trail is available for each report. For more information, visit our page on CbC submissions or schedule a consultation with our experts.