e-invoicing in Denmark

Regional spotlight

Formats? Mandates?
We've got you covered!

• Overview of B2G, B2B and B2C e-invoicing in Denmark.
• Key formats, networks and channels you may need to support.
• High-level regulatory and compliance considerations.

Read the Regional spotlight

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.

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.

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 with the recipient’s CVR number and show the result in your invoice view.

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.

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.

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.

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.

{
  "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.

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

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 GLNGlobal Location Number — an international identifier for business locations instead of its CVR number, using scheme 0088. Pass both the scheme and the identifier explicitly:

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

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 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.

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

[
  {
    "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 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 (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.
4. Deregister end-customers who ask for it with DELETE /v1/company/profiles/{id}.

Scanning

Both Scan Network and AutoScan are supported 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 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.

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. Peppol BIS Invoice Response implementation guidelines.
• If the supplier is not registered in Peppol, the ERP instead calls Maventa’s endpoint POST /v1/invoices/{id}/responses/nemhandel 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).

Accounts receivable services

Ropo’s reminder and collection service 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 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.

e-invoicing formats used in Denmark