Skip to main content

​
Introduction

NemHandel is Denmark’s national e-invoicing network, managed by the Danish Business Authority (Erhvervsstyrelsen). Invoices to Danish public authorities must be submitted through it — mandatory since 2005 — and Danish businesses exchange B2B invoices over the same infrastructure. Documents travel as OIOUBL 2.1, Denmark’s UBL-based national format. The NemHandel Denmark app converts GOBL invoices and credit notes to OIOUBL, delivers them over the network, and imports documents your suppliers receive. For onboarding suppliers, see the companion guide: Denmark: Supplier registration. Please refer to the docs of GOBL’s Denmark tax regime to learn about the specifics of Danish GOBL documents.

​
Prerequisites

In order to complete this guide, you will need:
  • A registered supplier: follow the NemHandel supplier registration guide to connect the NemHandel Denmark app, sign the authorization agreement, and register the supplier on the network before issuing.
  • Customer routing details: the EAN/GLN number for public institutions, or the CVR number for Danish companies.
  • Line and item details, including quantity, price, and description. Denmark applies a single 25% VAT rate (moms) with no reduced rates.

​
Setup

The supplier must already be registered on NemHandel — this is covered in the supplier registration guide.
All of the following steps must be carried out from the Invopop Console.
1

Create the send workflow

This workflow numbers and signs the invoice, converts it to OIOUBL 2.1, and submits it to the network, holding until the delivery is confirmed.

NemHandel send invoice workflow

Add to my workspace →
2

Create the import workflow

You can skip this step if you don’t plan to receive invoices.
This workflow runs once for each document delivered to one of your registered suppliers: it fetches the OIOUBL from the network, converts it to GOBL, and stores it as a new silo entry with the original XML and any embedded attachments.

NemHandel import invoice workflow

Add to my workspace →
3

Configure the NemHandel Denmark app

You can skip this step if you don’t plan to receive invoices.
In Configuration → Apps → NemHandel Denmark, select the import workflow you just created as the incoming workflow. Every document received on the network for one of your registered suppliers is handed to it automatically. See the NemHandel Denmark app page for the full list of actions it provides.

​
Send an invoice

Upload an invoice to the silo and run the NemHandel send invoice workflow on it, either from the Console or via the API.
The recommended approach for running jobs is to perform two steps: first upload the document to the silo, then create a job.
The workflow queues after submission until the delivery is confirmed, so an entry in the sent state means the recipient’s access point accepted the document.

​
Correct an invoice

There is no cancellation mechanism on the NemHandel network. To correct a delivered invoice, issue a credit note referencing the original in its preceding array and run the same send workflow on it — OIOUBL requires non-negative totals, so corrections are always credit notes in Denmark. See the example credit note below.

​
Example invoices

The following examples are GOBL documents you can copy and paste directly into the Invopop Console or store via the API as silo entries. Then, run the NemHandel send invoice workflow created during setup. GOBL Invoices sent to NemHandel require the following properties:
  • $schema to be set to https://gobl.org/draft-0/bill/invoice
  • supplier.tax_id.country to be set to DK, with the supplier’s 8-digit CVR number as the code
  • customer routing: an explicit GLN: endpoint for public institutions, or a Danish tax_id from which the participant is derived
  • the dk-oioubl-v2 addon; the app adds it automatically during conversion if it’s missing, but declaring it up front validates the document at upload time
In this example, we’re issuing an invoice from a Danish supplier to a public institution — the classic NemHandel use case. Public entities are identified by their EAN/GLN number in the NemHandelsregisteret.Notice:
  • The dk-oioubl-v2 addon validates and normalizes the document using the OIOUBL 2.1 rules, and pulls in the eu-en16931-v2017 addon automatically.
  • The customer carries a GLN legal identity and a GLN: endpoint — this is how the document is routed to the institution on the NemHandel network.
  • The supplier only sets its CVR number as the tax ID; the addon derives the DK:CVR endpoint from it automatically.
  • The debit-transfer payment key maps to UNTDID payment means 31 (IBAN transfer), one of the codes OIOUBL allows. A BIC is required alongside the IBAN.
  • There are no totals or calculations; all these will be made automatically when uploading.
In this example, we’re issuing an invoice from one Danish company to another. Both parties are identified by their CVR numbers alone.Notice:
  • Neither party declares endpoints or inboxes explicitly; the dk-oioubl-v2 addon derives each participant identifier (DK:CVR:<number>) from the Danish tax ID.
  • Only the VAT rate (standard) is specified on the lines; Denmark’s single 25% rate and the amounts are calculated on build.
  • There are no totals or calculations; all these will be made automatically when uploading.
In this example, we’re issuing a credit note that corrects a previously sent invoice. Corrections in Denmark are always credit notes — OIOUBL requires non-negative totals, so a negative invoice is not allowed.Notice:
  • The type is set to credit-note, which maps to UNTDID document type 381 on build.
  • The preceding array references the original invoice by series, code, and issue_date.
  • There are no totals or calculations; all these will be made automatically when uploading.

​
FAQ

Invoicing questions
Documents on NemHandel are addressed by participant identifier. If the customer declares an endpoint (for example GLN:5798009883735 for a public institution’s EAN/GLN number), that identifier is used. If a Danish customer only carries a CVR number in its tax ID, the dk-oioubl-v2 GOBL addon derives the participant identifier (DK:CVR:<number>) automatically. Explicit endpoints always win over derived ones.
Issue a credit note referencing the original invoice in the preceding array. OIOUBL requires non-negative totals, so corrections in Denmark are always credit notes — a negative invoice will fail validation. There is no cancellation mechanism on the network itself: once delivered, a document can only be countered by a credit note.
OIOUBL restricts the UNTDID 4461 payment means codes to a fixed list. The most common mappings from GOBL are debit-transfer for IBAN bank transfers (code 31, requires a BIC), domestic Danish bank transfers (code 42, account number plus bank registration number), Giro (code 50), and FIK (code 93). A generic credit-transfer (code 30) is rejected by the format.
The send step submits the OIOUBL document to the network and then queues until the delivery is confirmed by Invopop’s NemHandel access point. The workflow’s state only advances to sent once the network reports the document as delivered, so a sent entry means the recipient’s access point accepted it.
Receiving questions
Once a party is registered, documents addressed to its participant identifier are delivered to Invopop’s access point. Each delivery triggers the import workflow you selected in the NemHandel Denmark app’s configuration: the import step fetches the OIOUBL document, converts it to GOBL, creates the silo entry, and attaches the original XML along with any embedded binary attachments (such as PDFs).
Deliveries are only acknowledged to the network after the import completes, so a transient failure leaves the document ready to be retried. An hourly reconciliation loop also picks up any deliveries missed by the real-time path. Documents that can never be processed are flagged for review instead of being retried forever.
More available in our Denmark FAQ section

Participate in our community

Ask and answer questions about invoicing in Denmark →