Skip to main content

Register suppliers

Supplier registration guide ›

Issue invoices

Issuing guide ›

Receive invoices

Receiving guide ›
NemHandel is Denmark’s national e-invoicing network, run by the Danish Business Authority (Erhvervsstyrelsen). Denmark was the first country in Europe to mandate B2G e-invoicing, back in 2005: public authorities only accept electronic invoices, delivered over NemHandel or Peppol, and the Digital Bookkeeping Act now requires nearly every Danish business to be able to send and receive e-invoices as well.Documents travel on NemHandel as OIOUBL 2.1, Denmark’s national UBL dialect. This app owns the full journey in both directions: it converts GOBL invoices and credit notes to OIOUBL, validates them against the official schematron before anything is sent, delivers them over the network, and imports the documents your parties receive back into GOBL.Invopop has partnered with eCourier, a Danish NemHandel access point, to transmit documents and onboard suppliers onto the network. Registering a supplier includes a signing step: the supplier’s representative signs an authorisation agreement through a hosted wizard (or your own UI over the API), and the app completes the network registration once it’s signed.

Key features

  • Workflow automation: Register parties, issue invoices, and import received ones as steps in your workflows.
  • OIOUBL 2.1 both ways: GOBL → OIOUBL conversion for sending and OIOUBL → GOBL for received documents, including embedded attachments.
  • Schematron validation up front: Every generated document is validated against the official OIOUBL schematron (v1.17) before it leaves the platform.
  • Delivery confirmation: The send step waits until the network confirms delivery — submission alone doesn’t complete the job, and duplicates are never resubmitted.
  • Hosted supplier onboarding: The authorisation agreement is signed through a hosted wizard, with API endpoints for integrators building their own onboarding UI.
  • Push reception: Inbound documents are delivered by webhook the moment they arrive and handed to your import workflow.
Check out the guides below to get started:

FAQ

Invoicing questions
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.
Registering supplier questions
NemHandel registration runs through Invopop’s partner eCourier, which requires a signed authorisation agreement from the supplier before it can create the supplier’s NemHandel participant. That’s why the registration workflow has three steps: publish the agreement for signing, wait until the supplier’s representative signs it, and only then register the participant.
A representative of the supplier — typically a director or other authorized signatory. The registration workflow publishes a public signing link on the party’s silo entry; share it with the representative and they complete a short hosted wizard: confirm their details, review the agreement, and sign. If the party’s people list carries a person with a name and role, the wizard prefills them as the signer. Integrators building their own onboarding UI can drive the same flow over the API.
Its NemHandel participant identifier: the party’s first GOBL endpoints entry if it has one (for example a GLN: number), otherwise the DK:CVR identifier derived from the party’s Danish tax ID. NemHandel uses symbolic schemes (DK:CVR, DK:SE, GLN) rather than Peppol’s numeric ISO 6523 codes.
Each NemHandel participant can only be held by one Invopop workspace. If another workspace has already registered the same identifier, registration is refused — which workspace holds it is not disclosed. Re-running registration for a party your own workspace already registered is fine: it’s treated as a retry, not an error.
Yes. Run the unregister workflow on the party’s silo entry: it releases the NemHandel registration, removing the participant and the routing that delivered inbound documents to your workspace. To send or receive on behalf of that party again, you’ll need to register it again.
Receiving questions
By push, not polling. When a document addressed to one of your registered parties lands on the network, eCourier notifies Invopop by webhook, and the Denmark app starts your configured import workflow for it. The import step fetches the document, parses the OIOUBL, converts it to a GOBL invoice, and creates a silo entry carrying the GOBL document, the original XML, and any binary attachments embedded in it.
The one you select in the Denmark app’s configuration (ConfigurationAppsDenmarkConfigure). Every inbound document is handed to that workflow, so create it before registering any party — its first step must be the app’s import action, and everything after it is yours to shape: setting a state, filing into a folder, or any other processing.
The current release imports invoices and credit notes. If something else arrives — an OIOUBL ApplicationResponse or a Reminder — the app acknowledges it on the network once and fails the import job with a message naming the document type that arrived and the participant it was addressed to, so it’s visible rather than silently retried forever. Support for these document types is planned for a follow-up release.
The network redelivers its webhook until it is acknowledged, but the import step only acknowledges a document after it has been fully processed — and a document that was already imported isn’t imported again. A failure partway through leaves the document ready to retry rather than lost.
More answers in our Denmark FAQ section

Participate in our community

Ask and answer questions about the Denmark app →