Denmark
Danish B2G + B2B e-invoicing with Beliq, Peppol BIS 3.0 UBL, EAS 0184 DIGSTORG / CVR routing, and the NemHandel / Erhvervsstyrelsen transmission boundary; the legacy OIOUBL format is documented but out of scope.
Denmark’s e-invoicing landscape uses standard Peppol BIS Billing 3.0 UBL (EN 16931) on the cross-border path. There is no national CIUS. Danish endpoint addressing uses CVR (Centrale Virksomhedsregister — the Danish company register) via Peppol EAS 0184 DIGSTORG. Denmark also maintains a legacy domestic XML format, OIOUBL, used historically for B2G via NemHandel — Beliq does not implement OIOUBL (see the OIOUBL section below). Authority: Erhvervsstyrelsen (Danish Business Authority).
So a Danish invoice in Beliq is a Peppol BIS invoice with Danish parties (EAS 0184). See the Peppol BIS format reference for the full element layout.
Mandate timing
Danish public-sector e-invoicing has run over NemHandel for years. The Bookkeeping Act (Bogføringsloven) then phased in a digital-bookkeeping capability requirement: businesses must run a registered system able to send and receive structured e-invoices, though it is not an obligation to actually exchange B2B e-invoices.
| Date | What changes |
|---|---|
| 2005 | Public-sector e-invoicing goes live over NemHandel, later aligned to EN 16931. |
| 1 July 2024 | Businesses that file annual reports must keep their books in a registered digital bookkeeping system able to send and receive structured e-invoices. |
| 1 January 2026 | The digital-bookkeeping requirement extends to smaller (class A) businesses above a turnover threshold, on a registered system. |
| 1 July 2026 | The final phase: businesses on custom or in-house systems must comply. Entities already on a registered system are enrolled in the NemHandel register to receive structured e-invoices unless they opt out. |
The Bookkeeping Act (Bogføringsloven) requires a digital bookkeeping system capable of structured e-invoicing; it is not an obligation to actually exchange B2B e-invoices. The phase-in is complete: annual-report filers from 2024, class A businesses above the turnover threshold on 1 January 2026, and custom or in-house systems on 1 July 2026. Denmark is pursuing capability-by-default rather than a hard B2B mandate — NemHandel registration is now opt-out, and a consultation that closed on 17 August 2026 proposed making software providers enrol their business customers by default. Re-confirm the current thresholds and the outcome of that consultation with Erhvervsstyrelsen.
Last verified against Erhvervsstyrelsen (the Danish Business Authority) on the completed Bookkeeping Act phase-in and the NemHandel opt-out registration, and the European Commission eInvoicing Denmark country page on 24 August 2026. Official source.
If you sell to Danish public-sector buyers today, you are already in scope. On the B2B side, the phased requirement is about your bookkeeping system’s capability, not a duty to exchange e-invoices. Denmark also converges with the EU-wide ViDA framework for cross-border B2B. For the dates Beliq tracks across every covered country, see the mandate calendar.
What Beliq does today
- Generate Danish Peppol invoices via
standard: "peppol-bis"(profilepeppol), addressed with the Danish CVR endpoint scheme (DK:DIGSTORG, Peppol EAS0184). Secondary scheme0096(Danish Chamber of Commerce) is also accepted. - Validate and parse Peppol BIS UBL against the full EN 16931 + Peppol BIS 3.0 Schematron (
peppolVersionin the response). - Validation depth on the Peppol path is Authority-checked: Beliq asserts verdict parity against OpenPeppol’s own unit-test corpus (62 testSets, 335 cases) plus its 10 published example invoices. Denmark’s own Peppol rules ride that same pinned Schematron as the
DK-R-*family, and OpenPeppol’s Danish unit-test suite (14 testSets, 137 cases) is vendored and asserted beside the shared one. See how verification works for the tier definitions and theverificationTierfield that reports them.
OIOUBL and NemHandel
NemHandel itself is the Danish B2G gateway. It accepts both OIOUBL (legacy) and Peppol BIS (modern). Routing via NemHandel for the Peppol path is Peppol-AP-routed BYOC — same shape as Belgium’s transmission story.
What Beliq does not do (Peppol transmission boundary)
Denmark’s network is the Peppol Network for the modern path. Beliq is not a Peppol Access Point. It does not:
- Transmit invoices over Peppol or register you as a Danish Peppol participant.
- Operate the 4-corner exchange on your behalf.
- Submit invoices to NemHandel on your behalf (NemHandel submission is Peppol-AP-routed for the Peppol path; OIOUBL-only routing is BYOC).
- Generate or validate OIOUBL documents.
Today you send Beliq’s UBL output through your chosen Access Point (BYOC). Managed delivery over Peppol is in build, targeting Q4 2026 and subject to certification.
Integration architecture (Beliq vs Peppol Access Point vs NemHandel)
| Concern | In Beliq today | Outside Beliq (your stack / partner) |
|---|---|---|
| Peppol BIS 3.0 UBL invoice XML | Generate, Validate, Parse | — |
| Peppol Network transmission (4-corner) | Not offered, see boundary above | Your Access Point provider |
| NemHandel B2G submission (Peppol path) | Not offered (Peppol-AP-routed BYOC) | Your Access Point provider |
| OIOUBL generation / validation | Not offered (legacy, BYOC) | Your domestic invoicing software |
| NemHandel OIOUBL-only routing | Not offered | Your domestic invoicing software |
Generating a Danish Peppol invoice
Address both parties with the Danish CVR endpoint scheme (DK:DIGSTORG, EAS 0184) via the peppol block. It is required for Danish parties: the id is the 8-digit CVR, and a Danish VAT id carries a DK prefix that 0184 does not register, so Beliq will not derive the endpoint from vatId alone. Use DKK for the invoice currency. Provide either a buyerReference or an orderReference.
curl -X POST https://api.beliq.eu/v1/generate \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"standard": "peppol-bis",
"profile": "peppol",
"output": "xml",
"invoice": {
"number": "2026-0001",
"issueDate": "2026-06-04",
"currencyCode": "DKK",
"buyerReference": "DK-PO-5511",
"seller": {
"name": "Test Sælger ApS",
"vatId": "DK12345678",
"peppol": { "schemeId": "0184", "id": "12345678" },
"address": { "street": "Vesterbrogade 1", "city": "København", "postalCode": "1620", "countryCode": "DK" }
},
"buyer": {
"name": "Test Køber ApS",
"peppol": { "schemeId": "0184", "id": "87654321" },
"address": { "street": "Strøget 2", "city": "Aarhus", "postalCode": "8000", "countryCode": "DK" }
},
"lines": [
{
"description": "Professional services",
"quantity": 1,
"unitCode": "C62",
"unitPrice": 800.00,
"lineTotal": 800.00,
"vatRate": 25,
"vatCategoryCode": "S"
}
],
"taxSummary": [
{ "vatCategoryCode": "S", "vatRate": 25, "taxableAmount": 800.00, "taxAmount": 200.00 }
],
"totalNetAmount": 800.00,
"totalTaxAmount": 200.00,
"totalGrossAmount": 1000.00
}
}'Validation behaviour
On /v1/validate and /v1/generate, Danish invoices run the full EN 16931 + Peppol BIS 3.0 Schematron; failures carry the relevant BR-* / PEPPOL-* rule id. The response reports profileDetected: "peppol" and a peppolVersion. CreditNote payloads are supported (documentType: "creditnote"). DKK currency round-trips cleanly through cbc:DocumentCurrencyCode.