Skip to main content

​
Compliance questions

Denmark
No. As of 2026, Denmark has no B2B or B2C e-invoicing transmission mandate. The Digital Bookkeeping Act requires businesses to use certified systems that are capable of sending and receiving structured e-invoices (Peppol BIS 3.0 and OIOUBL), but it does not require that every invoice is actually sent electronically. You must be ready to e-invoice, but you are not yet obligated to do so for B2B or B2C transactions.E-invoicing is only mandatory for B2G — all invoices to Danish public authorities must be submitted electronically via NemHandel or the Peppol network. A domestic e-reporting obligation covering B2B is expected by approximately 2028.
NemHandel
Yes. OIOUBL 2.1 remains Denmark’s national e-invoicing standard and is accepted alongside Peppol BIS Billing 3.0 for invoicing public authorities. What Erhvervsstyrelsen cancelled in January 2026 was OIOUBL 3.0, the planned successor that never left its release-candidate stage. Denmark is converging on a single Peppol-aligned standard in the longer term, but until that is specified and rolled out, OIOUBL 2.1 stays in mandatory use — with updated schematron validation rules (v1.17) applying from May 15, 2026, which the Denmark app already validates against.
Danish public authorities only accept electronic invoices, delivered over NemHandel or the Peppol network — paper and PDF invoices are rejected. Public entities are identified by their EAN/GLN number in the NemHandelsregisteret (NHR). The Denmark app delivers OIOUBL 2.1 invoices over NemHandel; for Peppol BIS delivery, the Peppol app covers the same receivers through the Peppol network.
Peppol
Mandatory dates vary by country. Belgium requires structured B2B e-invoicing — Peppol BIS by default — from January 2026. Germany is phasing in B2B e-invoicing between 2025 and 2028. France’s Factur-X via Peppol applies once the PA reform takes effect. Outside mandates, Peppol delivery is voluntary but increasingly expected for B2G and cross-border trade.
Yes. Every document exchanged on Peppol BIS uses a UBL or CII syntax that conforms to the EN16931 European e-invoicing standard, plus the relevant Peppol BIS specification. Invopop generates compliant XML automatically when you use the Peppol app.
Peppol is a federated network — anyone could otherwise register a Participant ID for a company they don’t represent. Proof of ownership ties the Participant ID to a verifiable contact at the company, which is what allows the registration to be published on the SML.
Requirements vary by Authority. In Belgium, for example, the supplier must provide a recent extract from the Banque-Carrefour des Entreprises (KBO/BCE) plus a signed mandate. Invopop walks the registering party through the local requirements during the registration wizard.
Yes — a Peppol BIS document delivered through a certified Access Point is treated as the legal e-invoice in any country that recognises Peppol. The signed UBL or CII XML is the authoritative record; archive it alongside any human-readable rendering you generate.
Retention is set by each country’s tax authority — typically 7 to 10 years in the EU. Invopop preserves the original XML and any generated PDF in the silo entry so you can satisfy local archival requirements wherever you operate.

​
Invoicing questions

NemHandel
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.
Peppol
In countries where Peppol is the standard but not mandatory, you may still need to issue an e-invoice when the recipient isn’t on the network. Both parties can agree on an alternative transfer method, but the invoice must still be EN16931 compliant.Recommended approach:
  • Set up a separate workflow that generates the XML without the send-Peppol-document step
  • Or reuse your existing workflow without the customer Peppol ID — the send step is automatically skipped
  • Fetch the generated XML and deliver it through the agreed channel, typically email
B2C invoices typically lack the structured customer information required for Peppol delivery, and most consumers don’t have inboxes. Use a conditional workflow:
  1. Add an If/Else step that checks for a customer inbox using count(customer.inboxes, true) > 0.
  2. On the false branch, generate a PDF and email it to the customer, then stop the flow.
This routes B2B invoices through Peppol while keeping a smooth path for consumers.
If a job fails with KO and receiver not found in the peppol network, treat it like an invalid email address — the recipient simply isn’t reachable on Peppol. Add the Lookup Participant ID step (ideally in a separate validation workflow run against customer data) so you catch missing IDs before generating the invoice.
No. The regime is automatically derived from the supplier’s settings, which is the recommended approach for Peppol — leave it unset on the document.
See the eu-en16931-v2017 addon for the field and validation rules Peppol BIS Billing 3.0 builds on, and the Peppol app reference for supported document types and Participant ID schemes.

​
Registering supplier questions

NemHandel
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.
Peppol
Upload the company as a party (Console → Parties → Suppliers → + New Supplier, or via the Create an Entry API) with name, tax_id, address, and email. Then run it through the party registration workflow — the contact will receive a registration wizard link to provide proof of ownership.Once approved, the party is registered on the Peppol network (SMP+SML+Peppol visibility by default with the ubl-invoice doc group) and ready to receive invoices.
A supplier with that Participant ID already exists in your workspace. Either reuse the existing party or, if it really is a new entity, check whether it should be registered under an alternative scheme (for example Belgium’s 9925 VAT scheme rather than the default 0208).
Register them through different silo entries, even though they represent the same legal party. The supplier must upload proof of ownership for each inbox.
Unique identifiers for entities on the Peppol network, made up of two parts:
  • Scheme — identifies the type of identifier (e.g. 9920 for Spanish VAT, 0208 for Belgian KBO/BCE)
  • Code — the actual identification number
Participant IDs are usually based on VAT numbers or local business identifiers, and Invopop can derive them automatically from a Tax ID. Some countries support multiple schemes — Belgium, for example, defaults to 0208 but some entities are only registered under 9925 (VAT). If you hit a “receiver not found” error, the recipient may be registered under an alternative scheme.
Peppol Party visibility determines what you can send and receive:
  • smp — SMP only, for testing
  • smp+sml — SMP and SML, useful when you only want to send
  • smp+sml+peppol — SMP, SML, and the Peppol Directory, recommended for both sending and receiving (and for being discoverable in the Directory)
In general, use the highest visibility available.

​
Receiving questions

NemHandel
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 (Configuration → Apps → Denmark → Configure). 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.
Peppol
Register the recipient as a Peppol participant with Invopop as their Access Point. Incoming documents are routed through your configured Import workflow, which converts the UBL or CII payload to GOBL and stores the entry in the Expenses folder.
Yes. Either format can be removed based on your needs. The default template includes both for comprehensiveness, but if you’re certain you’ll only receive invoices in one syntax, dropping the other simplifies the workflow and reduces the apps you need to activate.
The Import workflow’s UBL and CII parser steps map the inbound XML into a GOBL invoice. From there you can route it to webhooks, Google Drive, accounting integrations, or any other destination — the GOBL representation is the single source of truth for downstream processing.

Participate in our community

Ask and answer questions about Denmark’s regulation →