Country Guides

Denmark

Danish e-invoicing with Peppol BIS 3.0 UBL, EAS 0184 routing and the NemHandel transmission boundary; the domestic OIOUBL is described but out of scope.

Denmark’s e-invoicing landscape uses standard Peppol BIS Billing 3.0 UBL (EN 16931) on the cross-border path. Denmark’s own Peppol rules, the DK-R-* family, ride inside that shared rule pack. Danish endpoint addressing uses CVR (Centrale Virksomhedsregister, the Danish company register) via Peppol EAS 0184 DIGSTORG. Denmark also runs a domestic XML standard, OIOUBL 2.1, over NemHandel for trade within Denmark. 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 must file an annual report under årsregnskabsloven § 3, stk. 1, and use a registered standard bookkeeping system (which must be able to send and receive structured e-invoices) must keep their books digitally, for the first financial year starting on or after this date.
1 January 2025	The same duty for those businesses on a non-registered (custom or in-house) bookkeeping system, for the first financial year starting on or after this date.
1 January 2026	The duty extends to businesses with no annual-report obligation under årsregnskabsloven § 3, stk. 1, whose net turnover exceeded DKK 300,000 in two consecutive income years. The registered/non-registered split does not apply to this group.

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 on a registered standard system from 1 July 2024 and on a non-registered system from 1 January 2025, then businesses with no annual-report obligation whose net turnover exceeded DKK 300,000 in two consecutive income years from 1 January 2026. Denmark is pursuing capability-by-default rather than a hard B2B mandate. BEK nr 811 af 22/09/2026, in force since 29 September 2026, adds requirements for registered standard bookkeeping systems. From 1 March 2027 a provider must have each business customer confirm its identity with MitID. A customer that is not yet enrolled for e-invoicing over NemHandel is then told that it will be enrolled unless it declines within four weeks. The system must also show a user who invoices by hand when the recipient is in the NemHandel register and can take an e-invoice. The order binds system providers rather than the bookkeeping-obliged businesses whose dates this timeline tracks, so it carries no milestone here. On formats, Erhvervsstyrelsen announced on 14 January 2026 that there will be no OIOUBL 3.0, and its document strategy of 5 March 2026 keeps OIOUBL 2.1 until NemHandel moves invoices and credit notes to Nemhandel BIS 4, a Peppol BIS 4 format with Danish extensions, which it plans for 2028 to 2029.

Last verified against BEK nr 1342 af 24/11/2023, BEK nr 297 af 20/03/2025 and BEK nr 811 af 22/09/2026 in the Danish gazette, Erhvervsstyrelsen's guidance Ikke-registrerede digitale bogføringssystemer (last updated 11 February 2026), its NemHandel notice of 14 January 2026 that there will be no OIOUBL 3.0, and its Strategi for dokumentstandard for e-faktura i Nemhandel (5 March 2026) on 7 October 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" (profile peppol), addressed with the Danish CVR endpoint scheme (DK:DIGSTORG, Peppol EAS 0184). Secondary scheme 0096 (Danish Chamber of Commerce) is also accepted.
Validate Peppol BIS UBL against the full EN 16931 + Peppol BIS 3.0 Schematron (peppolVersion in the response). Parse reads its fields and runs no rules.
Validation depth on the Peppol path is Authority-checked: Beliq asserts verdict parity against OpenPeppol’s own unit-test corpus (335 cases) plus its 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 (137 cases) is vendored and asserted beside the shared one. See how verification works for the tier definitions and the verificationTier field that reports them.

OIOUBL and NemHandel

OIOUBL is out of scope today

OIOUBL 2.1 is Denmark’s domestic XML standard. Erhvervsstyrelsen’s guidance names OIOUBL for trade within Denmark and Peppol BIS for trade across borders, and both run over NemHandel. OIOUBL is NOT a Peppol BIS CIUS overlay: it is its own root element + namespace, a separate XML standard.

Erhvervsstyrelsen announced on 14 January 2026 that there will be no OIOUBL 3.0. Its document strategy of 5 March 2026 keeps OIOUBL 2.1 until NemHandel moves invoices and credit notes to Nemhandel BIS 4, a Peppol BIS 4 format with Danish extensions, which it plans for 2028 to 2029. Beliq covers the Peppol BIS path; OIOUBL generation / validation is out of scope today and not parked as a follow-up.

For Danish customers needing an OIOUBL-only domestic flow through NemHandel, that path is BYOC. If you need OIOUBL from Beliq, email hello@beliq.eu, which is the signal that brings it forward.

NemHandel itself is the Danish B2G gateway. It carries both OIOUBL and Peppol BIS. Routing via NemHandel for the Peppol path is Peppol-AP-routed BYOC, the same shape as Belgium’s transmission story.

What Beliq does not do (Peppol transmission boundary)

Denmark’s network is the Peppol Network for the Peppol BIS 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.

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	n/a
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 (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.

generate-denmark-peppol.sh

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.