SBR and Digipoort explained for accounting firms
How SBR and Digipoort relate, which filings run through them, how certificates work and how to organise status follow-up at your firm.
The short answer
SBR is the Dutch standard for digital business reporting and Digipoort is the government\'s delivery channel: SBR defines what a message looks like, Digipoort is the route it travels. For a firm filing returns and depositing annual reports for dozens or hundreds of clients, this is the infrastructure that carries virtually all formal traffic with the Dutch Tax Administration and the Chamber of Commerce (KVK). Understand how the chain works and you also understand why a rejection happens and how to organise the follow-up.
What SBR is
SBR stands for Standard Business Reporting: the standard that defines how financial reports are constructed digitally. Technically, SBR is based on XBRL, a format in which every data point (a revenue figure, a VAT box, a balance sheet item) has a defined meaning rather than a position on a form.
Those definitions live in the Dutch Taxonomy (NT), which is updated annually. The taxonomy describes, per report type, which elements exist, what they are called and which rules they must satisfy. For the firm, the annual update means something practical: a filing for a new year must be built against the correct taxonomy version, and software that lags behind produces messages that get rejected.
What Digipoort is
Digipoort is the government\'s digital delivery channel, operated by Logius. It is not a website you log in to, but a system-to-system connection: your software submits an SBR message, Digipoort validates and routes it to the receiving party, and sends return messages about its status.
Access comes with one hard requirement: submitting via Digipoort requires a PKIoverheid server certificate. The certificate proves who the submitter is and encrypts the traffic.
The relationship in one sentence: SBR is the language, Digipoort is the letterbox, the certificate is the key.
What runs through it
SBR and Digipoort carry, among other things:
- VAT returns: the periodic turnover tax return, see the VAT return step-by-step guide.
- EC Sales List (ICP): the listing of intra-Community supplies, which must reconcile with box 3b of the VAT return, see EC Sales List and the VAT return.
- Corporate income tax: the CIT return, see Preparing the corporate income tax return.
- Personal income tax: for intermediaries filing on behalf of clients.
- Filing the annual report with KVK: for micro and small legal entities, digital filing via SBR is mandatory.
- Payroll tax returns: the periodic payroll tax return also goes through Digipoort.
For a firm this means a single channel carries virtually the entire filing and deposit practice. That is an advantage (one way of working, one status administration) and a dependency: the setup has to be right.
How certificates work in practice
The PKIoverheid server certificate can sit in the chain in two ways, depending on the setup:
| Variant | How it works | Consideration |
|---|---|---|
| The firm\'s own certificate | The firm obtains its own PKIoverheid server certificate and the software submits with it | Own management and own responsibility for application, renewal and security |
| The software vendor\'s certificate | The vendor submits under its own certificate, on behalf of the firm | No certificate management for the firm; the vendor operates the technical chain |
Both variants exist and both are legitimate. The choice depends on the software you use and on how much technical management the firm wants to carry itself. Firms running their own certificate must manage one thing tightly: renewal. An expired certificate means nothing can be submitted from one day to the next, usually discovered on a deadline day.
Return messages and status follow-up
After submission, return messages follow, and this is where firm practice most often goes wrong: not in the sending, but in the follow-up. The chain has two kinds of feedback:
- Technical return messages: was the message received and technically sound? Think of a confirmation of receipt and a validation result.
- Substantive return messages: does the receiving party accept the message, or does a rejection with a stated reason follow?
The dangerous scenario is a filing that appears sent but was rejected, while nobody saw the return message. The filing has then not been made, with all the consequences that follow. Status follow-up should therefore be organised as a process, not as an occasional check:
- Sent is not done. A filing is only complete at an accepted status, and that moment is recorded.
- Rejections are work in progress. Every rejection gets an owner and a deadline, visible in the planning and not in a mailbox.
- Deadline monitoring looks at status, not at sending. On the deadline, only what has been accepted counts.
- The record keeps the message as sent, with timestamp, submitter and the return message received, so you can demonstrate afterwards what was filed and when.
Common rejection reasons
Most rejections fall into a small number of categories:
- Wrong or outdated taxonomy version: the message was built against a different NT version than the receiver expects for that period.
- Content validation errors: mandatory elements missing, amounts that violate the taxonomy\'s rules, or boxes that are internally inconsistent.
- Identifiers that do not match: a filing for a period or tax number the receiver does not expect, for instance through a wrong period or a changed registration.
- Certificate and authorisation problems: an expired certificate or a misconfigured chain, so the message fails at the technical stage.
- Duplicate submission: a message already filed for the same period.
The lesson for the setup: keep software current (taxonomy), verify reconciliations before sending (content) and monitor certificates with a generous renewal margin (technology).
Why this is the most reliable route for firms
For a single business owner, the Tax Administration\'s portal is a workable route. For a firm with dozens or hundreds of filings per period, it is not. Portal work means manually re-entering figures that already exist in the books, with retyping errors as the well-known result, no link between the filing and the underlying entries, and status information that has to be checked filing by filing.
The SBR route through software turns that around: the filing is built from the books themselves, the reconciliation between entries and return boxes remains verifiable, and the return messages arrive in the same place the filing came from. That makes the chain not only faster but demonstrable: from entry to box to sent message to accepted status.
Giroo files VAT returns and other messages directly via Digipoort and shows the status per administration in the firm overview: prepared, sent, accepted or rejected. On a deadline day, the question "is everything in?" becomes a glance at one screen instead of a tour of mailboxes and portals.