Skip to main content

​
Introduction

NemHandel is the Danish e-invoicing network all public authorities — and a large share of businesses — receive their invoices through. Documents travel as OIOUBL 2.1, Denmark’s national UBL dialect. The Denmark app converts GOBL invoices and credit notes to OIOUBL, validates them against the official schematron, and delivers them over the network through Invopop’s partner eCourier. For onboarding suppliers, see the companion guide: NemHandel supplier registration. For importing the invoices your parties receive, see NemHandel receiving invoices.

​
Prerequisites

  • A registered supplier: follow the NemHandel supplier registration guide to connect the Denmark app, have the supplier sign the authorisation agreement, and register their NemHandel participant before issuing.
  • The dk-oioubl-v2 addon declared in $addons on every invoice, so the OIOUBL rules are validated before signing.
  • A routable customer: the customer must resolve to a NemHandel endpoint. Public entities carry their EAN/GLN number as an endpoint (GLN:5798000000000-style); a Danish business with only a tax ID gets its DK:CVR endpoint derived automatically.
  • OIOUBL-compatible payment data, if you include payment instructions: OIOUBL supports IBAN transfers plus the Danish channels (Giro, FIK, domestic bank transfer with its four-digit registration number, and NemKonto).
OIOUBL has no VAT-exempt category: invoices are standard-rated, zero-rated, or reverse-charge. An exempt VAT key is rejected up front — state the supply as zero-rated instead.

​
Setup

All of the following steps must be carried out from the Invopop Console.
1

Create the send workflow

Send NemHandel invoice workflow

Add to my workspace →

​
Send an invoice

Upload the invoice as a silo entry and run the send workflow on it.
The recommended approach for running jobs is to perform two steps: first upload the document to the silo, then create a job.
The workflow’s two app steps split the work:
  • Generate OIOUBL converts the signed GOBL envelope into an OIOUBL 2.1 document, validates it against the official schematron (v1.17), and stores the XML as an attachment on the entry under the oioubl file key. An invoice that would be rejected by the network fails here, before anything leaves the platform.
  • Send to NemHandel submits that attachment and then waits: the job stays queued until eCourier confirms the document is delivered, re-checking whenever the network reports a status change. Delivery — not submission — is what completes the job.
The bytes stored on the entry are exactly the bytes that reached the network, so you can always download the OIOUBL file that was actually delivered.

​
Duplicates are skipped

Running the send workflow again on an invoice that was already delivered skips with a Duplicated Invoice result instead of resubmitting, so a retried or repeated run never delivers the document twice.

​
Generating without sending

The convert step also works on its own: a workflow that ends after Generate OIOUBL produces the validated XML attachment without submitting anything, which is useful for previewing the exact document a customer will receive.

​
Example invoices

In this example, we’re invoicing a Danish public institution, the segment where e-invoicing is mandatory.Notice:
  • the $addons field is set to dk-oioubl-v2, which layers the OIOUBL 2.1 rules on top of the European EN 16931 baseline,
  • the customer carries its EAN/GLN number as an endpoint (GLN:5798009883735) — this is how public entities are identified in the NemHandelsregisteret,
  • the supplier declares no endpoint: the addon derives its DK:CVR endpoint automatically from the Danish tax ID,
  • the ordering.purchases block carries the order reference the receiving institution asked for,
  • the payment instructions use a SEPA credit transfer with an IBAN, and,
  • there are no calculations in some fields; these will be made automatically when uploading.
In this example, we’re issuing a B2B invoice from a Danish supplier to another Danish business.Notice:
  • both parties are identified by their CVR number as the GOBL tax_id.code; the addon derives each party’s DK:CVR endpoint from it,
  • the payment instructions describe a Danish domestic bank transfer (UNTDID payment means 42): the account number plus the four-digit bank registration (clearing) code the OIOUBL rules require, and,
  • there are no calculations in some fields; these will be made automatically when uploading.
In this example, we’re issuing a domestic invoice for a zero-rated supply — newspapers, one of the few zero-rated categories under Momslovens §34.Notice:
  • the line’s tax uses the zero VAT key: the supply is taxable at 0% with input VAT recovery, unlike an exempt supply,
  • OIOUBL has no exempt category on the wire, so genuinely exempt supplies (healthcare, education, financial services) cannot be invoiced through NemHandel as “exempt” — the addon rejects the exempt key and zero-rated is the closest the format supports, and,
  • everything else works exactly like the standard B2B invoice.
In this example, we’re issuing a domestic reverse charge invoice for copper scrap — one of the supplies (along with certain metals and electronics) where Denmark shifts the VAT liability to the buyer.Notice:
  • the line’s tax uses the reverse-charge VAT key, so no VAT is charged and the customer accounts for it instead,
  • the cef-vatex extension carries the exemption reason code VATEX-EU-AE (reverse charge), which OIOUBL maps to its reverse-charge tax category, and,
  • both parties are Danish businesses identified by their CVR numbers.
In this example, we’re invoicing a VAT-registered business in another EU member state — an intra-Community supply of goods, zero-rated under Momslovens §34.Notice:
  • the line’s tax uses the intra-community VAT key with the VATEX-EU-IC exemption reason code,
  • the customer carries its own country’s tax ID (a German VAT number here) and a GLN endpoint so NemHandel can route the document, and,
  • no Danish VAT is charged; the customer self-accounts for the acquisition in their own country.
In this example, we’re invoicing a customer outside the EU — an export of goods, zero-rated under Momslovens §34.Notice:
  • the line’s tax uses the export VAT key with the VATEX-EU-G exemption reason code,
  • the customer is a Norwegian business with its organisation number as tax ID and a GLN endpoint for routing, and,
  • no Danish VAT is charged on exports outside the EU.
In this example, we’re issuing a credit note that corrects a previously issued invoice.Notice:
  • the type is set to credit-note, which OIOUBL maps to its own CreditNote document (type code 381),
  • the preceding array references the original invoice by its series, code, and issue_date, along with a reason, and,
  • there are no calculations in some fields; these will be made automatically when uploading.

​
FAQ

Invoices and credit notes, as OIOUBL 2.1 documents. Declare the dk-oioubl-v2 addon in $addons on the GOBL invoice: it layers the OIOUBL rules on top of the European EN 16931 baseline and rejects documents that would fail on the network before anything is sent. Reminders and invoice responses (OIOUBL ApplicationResponse) are not supported yet — they are planned for a follow-up release.
The send step doesn’t report success on submission — it submits the OIOUBL document and then waits until the network confirms delivery. The job stays queued, re-checking the document’s status when eCourier reports a change (and every few minutes on its own), and only completes when the document is delivered. If delivery fails, the job fails and your workflow’s rescue steps run.
Not as “exempt”. OIOUBL’s tax category codelist supports standard-rated, zero-rated, and reverse-charge VAT, but has no exempt category on the wire. The dk-oioubl-v2 addon rejects an exempt VAT key up front rather than silently relabelling it — state the supply as zero-rated instead.
Nothing bad. A later run that finds the entry already delivered skips with a Duplicated Invoice result instead of resubmitting, so the receiver never gets the document twice.
Yes. The convert step works on its own: it converts the GOBL invoice to OIOUBL 2.1, validates it against the official schematron, and stores the XML as an attachment on the silo entry under the oioubl file key. A workflow that only converts lets you inspect or download the file without submitting anything to the network.
More available in our Denmark FAQ section

Participate in our community

Ask and answer questions about invoicing in Denmark →