---
title: "e-invoicing in Denmark"
canonical: https://documentation.maventa.com/services-and-reach/denmark/
---

Denmark is one of the most mature e-invoicing markets in Europe. E-invoicing has been mandatory for the public sector since 2005, and the country has since built a strong digital infrastructure around electronic document exchange.
Both Peppol and Denmark’s national network Nemhandel are supported, with ongoing developments driven by the new Danish accounting law and broader EU initiatives such as ViDA (VAT in the Digital Age).

In Denmark, most of the e-invoicing is routed through Nemhandel, the national infrastructure for electronic documents. Instead of connecting directly to Nemhandel, Maventa uses Sproom as an intermediary.

Sproom is a Danish e-invoicing platform and part of Visma. It acts as a technical access point and a routing directory, enabling companies to send and receive electronic invoices via Nemhandel. This ensures proper delivery of e-invoices across Denmark. Currently only invoices and credit notes are supported in the Danish set-up.

> [!NOTE]
> **From 1st of March 2027, bookkeeping system providers must register their end-customers to Nemhandel**
>
> Erhvervsstyrelsen (the Danish Business Authority) has published new requirements for registered digital bookkeeping systems in executive order no. 811 of 22nd of September 2026. From 1st of March 2027, providers of registered bookkeeping systems must register their end-customers to receive e-invoices via Nemhandel, unless the customer opts out within four weeks of being informed.
>
> Maventa does not register companies to Nemhandel automatically, and this does not change on 1st of March 2027. Informing end-customers, handling opt-outs and registering them through the Maventa API is the responsibility of the bookkeeping system provider.
>
> See [Registering end-customers to Nemhandel from 1st of March 2027](#registering-end-customers-to-nemhandel-from-1st-of-march-2027) for what this means for ERPs integrating with Maventa.

## Danish company account registration

When registering a new Danish company via the API, the CVR number (Central Business Registration Number) must be used as the company identifier. Visma Sign supports Danish customer authentication using either a personal ID or MitID.

| Identifier | Description | Format | Validation |
|------------|-------------|--------|------------|
| CVR number | Central Business Registration Number | `31000000` | Structural validation |

## Sending in Denmark

### Supported delivery channels and routing order in Denmark

For B2B and B2G, the routing order depends on where the sender is based.

**Danish senders** — domestic traffic is delivered in the following priority order: Nemhandel (Sproom), then Maventa’s internal network, and finally the Peppol network.

**Senders outside Denmark** — cross-border traffic to a Danish or Faroese recipient tries the Peppol network before Nemhandel (Sproom). Two things have to be true for the invoice to go over Peppol:

* The invoice carries a full Peppol endpoint ID such as `0184:31000000`. An invoice addressed only by a bare CVR number is delivered through Nemhandel (Sproom), because Maventa does not add a Peppol scheme prefix to a plain CVR.
* The recipient is registered in Peppol with a cross-border profile, meaning Peppol BIS Billing 3.0. A recipient registered only with OIOUBL profiles cannot receive cross-border Peppol traffic, so the invoice is delivered through Nemhandel (Sproom) instead.

For this traffic the Peppol lookup also takes precedence over a stored Nemhandel route in the address book. Whenever the Peppol lookup finds no usable match, Maventa falls back to Nemhandel.

Email and postal delivery (printing) are available as fallback options in both cases. Printing is handled in Norway, and all postal deliveries are sent from Norway.

For B2C, invoices are delivered via email and print only.

### Showing whether the recipient is in Nemhandel

From 1st of March 2027, registered bookkeeping systems must show clearly whether the recipient is registered in Nemhandel when a user creates an invoice manually, so that sending it as an e-invoice is an easy choice. Use the [Nemhandel lookup](#checking-whether-a-company-can-receive-from-nemhandel) with the recipient's CVR number and show the result in your invoice view.

GET /v1/lookup/receivers?network=SPROOM&bid=31000000

### Recipient identifiers and address resolution

Domestic Danish invoices are primarily routed through Nemhandel (Sproom), where the CVR number is sufficient for delivery. To route an invoice via Peppol instead, the full Peppol endpoint ID with scheme `0184` must be included in the invoice XML.

| Identifier type | Format | Example | Delivery channel |
|-----------------|--------|---------|------------------|
| CVR number | 8-digit number | `31000000` | Nemhandel (Sproom) |
| Peppol endpoint ID | `0184:` + CVR number | `0184:31000000` | Peppol network |
| GLN (Global Location Number) | `0088:` + GLN | `0088:1234567890128` | Peppol network |

Maventa does not automatically add a Peppol scheme prefix to a plain CVR number. If only the CVR number is provided, the invoice is delivered through Nemhandel — Peppol routing is not attempted.

> [!NOTE]
> For the most reliable Peppol delivery, include the full endpoint ID `0184:CVRnumber` in the invoice XML. For Nemhandel delivery, the plain CVR number is sufficient.

### Sproom and Nemhandel

Whenever your company sends invoices to Denmark to a participant in Nemhandel (which includes most of the Danish companies), the process depends on whether the sending company already has an existing Sproom account:

* No existing Sproom account → The invoices are automatically handled through Maventa’s parent account in Sproom. No additional actions are required from the sender.
* Existing Sproom account → The company must explicitly approve Maventa (Visma Software AS) as a parent account in Sproom. This approval links the company’s existing Sproom profile with Maventa, ensuring invoices continue to be routed correctly through Nemhandel.

A company can have multiple parent accounts in Sproom, which makes it possible for several software vendors to send and receive invoices on behalf of the same company.

When an invoice is sent from a company that already has a Sproom account, Sproom automatically sends an approval request email. This email is sent to the sender's company email address registered in Maventa, so it’s important to keep it up to date. The email contains a link that the company must follow and sign using MitID (Business or Private, depending on the signatory rights) to complete the approval. Currently, Sproom will continue sending approval requests after each invoice until the approval is completed. At the moment, invoice sending still works, but in the near future, invoices will fail if the approval is not completed after the first attempts.

Today, the approval emails come from Sproom address `notification@sproom.net`. But in the future, Maventa may take over sending these emails, which would then come from Maventa's own domain.

#### email fallback route with Sproom

When an invoice is sent to Sproom, the routing settings or disabled delivery routes defined in Maventa do not necessarily apply on Sproom’s side. This means that Sproom may send the invoice by email if e-invoice delivery fails. The email fallback is triggered when the recipient’s email address is included in the customer party details of the XML file. In Maventa, such invoices are still classified as e-invoices and appear as “e-invoice sent.”

By default, when a company does not have an existing Sproom account and is added as a child company of Maventa, the email sending route is not enabled on the Sproom side. This means that only the e-invoice route is active through Sproom, and if e-invoice delivery fails, Maventa decides whether to use the default delivery route.

For companies that already have an existing Sproom account and it is later linked under Maventa, if they had previously enabled the email sending option, it will remain active. In those cases, Sproom will handle the email sending, and such invoices will still be billed by Maventa as e-invoices.

Maventa recommends disabling the email sending setting on the Sproom side to ensure consistent and predictable delivery behaviour.

## Receiving in Denmark

In Denmark, companies can receive invoices through different channels. If a company has activated e-invoice receiving, they can receive invoices via Maventa’s internal network. Additionally, if the company is registered with Peppol, Peppol receiving is available. To receive from Nemhandel, the company needs a separate receiving activation for that network.

| Address Type              | Description                                                                                      | Example address    | Activation Requirement                                                         |
| ------------------------- | ------------------------------------------------------------------------------------------------ | ------------------ | ------------------------------------------------------------------------------ |
| Peppol address            | Official identifier for the Peppol network. Uses the CVR number with scheme `0184`.              | 0184:31000000      | Created when the company registers to receive from Peppol                      |
| Nemhandel address         | Identifier registered in the Nemhandel register (NHR). Uses the CVR number with scheme `9902`.   | 9902:31000000      | Created when the company registers to receive from Nemhandel                   |
| Nemhandel GLN address     | Identifier registered in the Nemhandel register (NHR) using a GLN with scheme `0088`.            | 0088:1234567890128 | Registered on request — see [Registering with a GLN](#registering-with-a-gln)  |

### Registering to receive from Nemhandel

Nemhandel receiving is activated separately from Peppol. Register a company using the company profiles endpoint with `NEMHANDEL` as the network.

POST /v1/company/profiles

```json
{
  "network": "NEMHANDEL",
  "profiles": ["INVOICE_AND_CREDIT_NOTE"]
}
```

The company is registered with its CVR number and scheme `9902`. Both are resolved from the company account, so no identifier needs to be passed in the request.

| Field | Value |
|-------|-------|
| `network` | `NEMHANDEL` |
| `profiles` | `INVOICE_AND_CREDIT_NOTE` is the only supported profile for Nemhandel |

Use `GET /v1/company/profiles` to check the status of a registration, and `DELETE /v1/company/profiles/{id}` to deregister.

> [!WARNING]
> The company must already have an active registration on Maventa's internal network (`VISMA`) before registering to Nemhandel. Without it, the request fails with `visma_network_not_enabled`.

Nemhandel and Peppol use different schemes for the same CVR number. Use `9902` for Nemhandel and `0184` for Peppol. `9902` is deprecated in Peppol and should not be used there.

Registering with the CVR number also means the end-customer owns the identifier in the Nemhandel register, which Erhvervsstyrelsen recommends. This makes it easier for the company to move its registration to another system later.

#### Registering with a GLN

A company can also be registered to Nemhandel with a **GLN** (Global Location Number — an international identifier for business locations) instead of its CVR number, using scheme `0088`. Pass both the scheme and the identifier explicitly:

```json
{
  "network": "NEMHANDEL",
  "profiles": ["INVOICE_AND_CREDIT_NOTE"],
  "scheme": "0088",
  "endpoint_id": "1234567890128"
}
```

> [!WARNING]
> GLN registration cannot be self-served. The GLN must first be verified and linked to the company account by Maventa, because GLN numbers are checked manually for now. Contact Maventa support to have a GLN enabled before calling the endpoint.
>
> Until the GLN is linked to the company, the request fails with `profile_eia_bid_conflict` and a message listing the identifiers that are associated with the company.

Scheme `9902` and scheme `0088` are the only values Nemhandel registration accepts. Any other scheme fails with `invalid_parameters`.

#### Checking whether a company can receive from Nemhandel

Use the lookup endpoint [GET /v1/lookup/receivers](https://swagger.maventa.com/?urls.primaryName=STAGE%20-%20AutoXChange%20API#/lookup/getV1LookupReceivers) with **`SPROOM`** as the network. Nemhandel reachability is resolved through Sproom, so `SPROOM` is the network value to use — `NEMHANDEL` is not a valid value for this endpoint and always returns an empty result.

GET /v1/lookup/receivers?network=SPROOM&bid=31000000

A match is returned with the recipient's Nemhandel address and `SPROOM` as both the network and the operator:

```json
[
  {
    "eia": "9902:31000000",
    "network": "SPROOM",
    "operator": "SPROOM",
    "document_types": [
      { "document_type": "INVOICE" },
      { "document_type": "CREDIT_NOTE" }
    ]
  }
]
```

An empty array means the recipient cannot be reached over Nemhandel.

Keep the following in mind when using this lookup:

* Search by `bid` or `eia`. Searching by `name` alone returns an empty result, even though the endpoint accepts the request.
* Only CVR and GLN identifiers are supported. As `eia`, use `9902:`, `0184:`, or `0088:` — a `DK` prefix on the CVR is removed automatically.
* The lookup reports whether the recipient is reachable through Sproom. To check the registrations Maventa itself holds for a company, use [GET /v1/company/profiles](https://swagger.maventa.com/?urls.primaryName=STAGE%20-%20AutoXChange%20API#/company/getV1CompanyProfiles) with `?network=NEMHANDEL` and `company` scope instead.

#### Registering end-customers to Nemhandel from 1st of March 2027

Executive order no. 811 of 22nd of September 2026 requires providers of registered digital bookkeeping systems to register their end-customers to Nemhandel unless the end-customer opts out. This is an obligation on the bookkeeping system provider, not on Maventa. From 1st of March 2027, providers of registered digital bookkeeping systems must:

* ask each end-customer to confirm their company details (stamoplysninger) with MitID, at the latest from 1st of March 2027. This is a one-time check, requested when the end-customer or their bookkeeper logs in to the system.
* inform each end-customer that they will be registered to receive e-invoices via Nemhandel, either together with the MitID check or in a separate message
* give the end-customer four weeks to opt out
* register the end-customers who do not opt out within four weeks of informing them
* deregister the end-customer at any time they ask, and register them again if they later ask for it

Erhvervsstyrelsen explains the change for Danish companies on [Virksomhedsguiden](https://virksomhedsguiden.dk/content/temaer/optimer-din-forretning/ydelser/e-fakturering/e83c3f01-2cbc-48a4-a5dc-9a4e5a2976b5/) (in Danish).

Maventa does not register companies to Nemhandel automatically, before or after 1st of March 2027. Maventa provides the API for registering and deregistering companies; the notice to end-customers, the four-week period, the record of who opted out, and the registration calls themselves are the responsibility of the bookkeeping system provider. To prepare for this with Maventa:

1. Make sure each company has an active registration on Maventa's internal network (`VISMA`).
2. Inform your end-customers, and keep track of the four-week period and any opt-outs.
3. Register the end-customers who did not opt out with `POST /v1/company/profiles`, as described in [Registering to receive from Nemhandel](#registering-to-receive-from-nemhandel).
4. Deregister end-customers who ask for it with `DELETE /v1/company/profiles/{id}`.

### Scanning

Both Scan Network and AutoScan are supported [scanning](https://documentation.maventa.com/integration-guide/invoice-receiving/scanning/) solutions in Denmark.

For Scan Network, invoices can be sent to the company’s scan email address in the format `CVRnumber@autoinvoice.dk`, where CVRnumber is the company’s CVR number.

### Invoice response messages

Denmark has introduced a new [accounting law](https://www.pwc.dk/en/publikationer/assets/the-new-danish-bookkeeping-act.pdf) requiring ERP systems to support invoice response messages, XML-based business acknowledgements that communicate the processing status of an invoice between buyer and supplier (e.g. accepted, rejected, pending).

This requirement applies to invoices received through both the Peppol network and Denmark’s national network Nemhandel. The response formats follow:

* Peppol BIS Invoice Response for Peppol
* OIOUBL Application Response for Nemhandel (generated automatically by Sproom when requested via Maventa API)

### How messages responses work with Maventa

When a customer receives an invoice from a Danish sender via Maventa, ERP must handle invoice responses according to the sender’s registered network:

1. Verify whether the sender wants to receive responses via Peppol by using the lookup API endpoint [GET /v1/lookup/receivers](https://swagger.maventa.com/?urls.primaryName=STAGE%20-%20AutoXChange%20API#/lookup/getV1LookupReceivers).

2. Send the invoice response

* If the supplier is registered in Peppol to receive invoice responses, the ERP creates and then sends a Peppol BIS Invoice Response via Maventa’s endpoint: [POST /v1/documents](https://swagger.maventa.com/?urls.primaryName=STAGE%20-%20AutoXChange%20API#/documents/postV1Documents). [Peppol BIS Invoice Response implementation guidelines](https://docs.peppol.eu/poacc/upgrade-3/profiles/63-invoiceresponse/).
* If the supplier is not registered in Peppol, the ERP instead calls Maventa’s endpoint [POST /v1/invoices/{id}/responses/nemhandel](https://swagger.maventa.com/?urls.primaryName=STAGE%20-%20AutoXChange%20API#/invoices/postV1InvoicesIdResponsesNemhandel) with invoice id and response they want to communicate back to the sender. Maventa will then forward the information to the Sproom API to generate and deliver an OIOUBL Application Response to Nemhandel on behalf of the ERP. If the supplier is registered in Nemhandel, Sproom generates and sends the response, which then Maventa returns as a success (200 OK). If the supplier is not registered, the request is ignored and an appropriate error status is returned.

To comply with Danish requirements, ERPs integrating with Maventa should:

* Implement support for generating and sending Peppol BIS 3 invoice response XMLs.
* Implement logic to determine whether the supplier want to receive responses via Peppol.
* Call the appropriate Maventa API endpoints based on the lookup result. Last status should be either accepted or declined.
* Prevent duplicate or invalid response submissions (follow the response order defined in the standards).

> [!NOTE]
> For step-by-step instructions on enabling receiving, registering for Peppol, and setting up scanning, see the [invoice receiving integration guide](https://documentation.maventa.com/integration-guide/invoice-receiving/).

## Accounts receivable services

> [!NOTE]
> Accounts receivable services for Denmark are coming at a later date (timeline TBD).

[Ropo's reminder and collection service](https://documentation.maventa.com/integration-guide/accounts-receivable/ropo-debt-collection/) will be available for Danish companies, offering reminder and debt collection services through Ropo. The service allows you to transfer overdue invoices to Ropo for reminder handling and collection directly through the Maventa API. For more details on how the service works, see the [Accounts receivable](https://documentation.maventa.com/integration-guide/accounts-receivable/) section in the Integration Guide.

## Peppol SMP registration

When a Danish company registers to receive invoices via Peppol through Maventa, the following document types are registered in the SMP (Service Metadata Publisher). These registrations determine which document formats the company can receive over the Peppol network.

<details>
<summary>Peppol BIS Billing 3.0 — Invoice</summary>

**DocumentIdentifier**
`urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1`

**ProcessIdentifier**
`urn:fdc:peppol.eu:2017:poacc:billing:01:1.0`
</details>

<details>
<summary>Peppol BIS Billing 3.0 — Credit Note</summary>

**DocumentIdentifier**
`urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2::CreditNote##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1`

**ProcessIdentifier**
`urn:fdc:peppol.eu:2017:poacc:billing:01:1.0`
</details>

> [!NOTE]
> OIOUBL is not registered on the Peppol network. It is used for domestic Danish traffic through Nemhandel (Sproom).

## e-invoicing formats used in Denmark

| Format | Standard | Network | Notes |
|--------|----------|---------|-------|
| [Peppol BIS Billing 3.0](https://docs.peppol.eu/poacc/billing/3.0/) | EN16931 | Peppol | Used for cross-border and Peppol traffic |
| [OIOUBL](https://digst.dk/it-loesninger/nemhandel/det-tekniske-setup-for-nemhandel/oioubl/) | UBL 2.0 | Nemhandel | Danish national format, used for domestic traffic through Nemhandel (Sproom). Not registered on Peppol |

> [!NOTE]
> Erhvervsstyrelsen plans to replace OIOUBL and Peppol BIS in Nemhandel with a single Peppol-based format. The transition is planned to start in mid-2028, and OIOUBL is planned to be phased out by mid-2029.