Denmark OIOUBL / Nemhandel E-Invoicing

Key Features

OIOUBL document generation from posted `Sales Invoice Header` and `Sales Cr.Memo Header` records, so the XML always reflects what was actually posted

Table and page extensions adding GLN/EAN receiver identifiers, Nemhandel registration and buyer reference to the Customer card, sales documents and posted documents

Pre-transmission validation in two layers: XSD/schema conformance plus Danish business rules (receiver identifier present, tax category mapped, buyer reference required for public-sector recipients)

Tax mapping driven from existing VAT Posting Setup and VAT Product Posting Groups to OIOUBL tax categories — no parallel tax table to maintain

Unit-of-measure and item identification mapping from BC master data (Item Reference, UNECE unit codes) with a per-customer override table

Access point transmission over a configurable HTTPS endpoint with certificate/API-key credential storage in isolated storage, never in plain setup fields

Job queue entries for send, status polling and retry, with bounded retries, exponential back-off and a dead-letter state that raises an operator task rather than looping silently

Human-readable rendering and the machine XML produced from one posting, so the customer-facing document and the transmitted document can never diverge

Rejection handling that records access point and receiver reason codes on the document, sets a rejected state, and drives a correct-and-resend or credit-and-reissue workflow

Immutable archive of every transmitted payload and response with timestamp, user, transport identifier and document version, retained per your retention policy

API pages (REST API v2.0 / OData v4) exposing transmission status and the archive for Power BI, Power Automate and Dataverse-connected reporting

Dedicated permission sets separating e-invoicing setup, day-to-day send/resend, and archive read-only access

Application Insights telemetry on every send, failure and retry so transmission health is observable outside the client

Event subscribers only — no modification of standard posting codeunits, keeping the extension upgrade-safe across Business Central release waves

Sandbox-first deployment path with an install/uninstall data-retention design so the extension can be removed without orphaning posted-document data

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Dynamics 365 Business Central.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Selling to Danish public-sector buyers means every invoice has to arrive as a valid OIOUBL document delivered over Nemhandel — not a PDF attached to an email. Teams that try to satisfy this from stock Business Central usually end up with a hybrid process: the invoice is posted in BC, then a finance user exports data to a spreadsheet, re-keys it into an access point portal or a bureau's web form, and manually files whatever acknowledgement comes back. Every hand-off is a place where the EAN/GLN receiver identifier, the buyer's reference (cbc:BuyerReference), the contract or order reference, or a VAT code can drift from what was actually posted. Business Central ships electronic-document plumbing and a Peppol-flavoured export, but a Danish OIOUBL profile with the country-specific identifier rules, the Nemhandel delivery path, the acknowledgement and rejection loop, and an auditable archive of exactly what was sent is not something you get by ticking a setup checkbox.

What we build is a per-tenant AL extension (or an AppSource-packaged app where you prefer that governance model) that treats the posted document as the single source of truth. Table and page extensions add the Danish e-invoicing fields where finance already works — GLN/EAN and Nemhandel registration on the Customer card, buyer reference and requisitioner on the sales order and posted invoice, and a document-status FactBox showing where each transmission stands. Codeunits build the OIOUBL XML from Sales Invoice Header/Sales Cr.Memo Header and their lines, mapping VAT posting setup, unit codes and item identifiers from your existing master data rather than from a parallel table you have to maintain. An event subscriber on the posting flow queues the document; a schema and business-rule validation pass runs before anything leaves the tenant, so a missing receiver identifier or an unmapped tax category is a clear error on the document, not a silent rejection days later.

Delivery runs through your chosen Nemhandel/Peppol access point over a configurable HTTP endpoint, driven by job queue entries so transmission, status polling and retries happen unattended with exponential back-off and a bounded retry count. Every attempt is logged: request, response, transport identifier, timestamp and user. The same posting produces both the machine format and the human-readable document your customer expects, so nobody has to reconcile two independent renderings. When an acknowledgement comes back negative, the extension records the reason codes against the document, moves it to a rejected state, and drives a correction workflow — correct and re-send, or credit and re-issue — with the full chain visible on the posted record. Sent XML and responses are retained in a compliant archive with an audit trail you can hand to an auditor, and the transmission log is exposed through API pages (REST API v2.0 / OData v4) so Power BI, a Power Automate flow, or a Dataverse-connected app can report on it without anyone opening the client.

Delivery is build-to-order. You request a quotation, we run a scoping call to confirm your Business Central deployment (SaaS or on-premises), your release wave, your access point, your document types and the localisation apps already installed. From confirmed scope, typical delivery is 2-4 weeks: we build on a sandbox copy of your environment, ship dedicated permission sets and telemetry, run UAT with your finance team against real transactions, then install into production with a rollback plan. You receive the AL source, a git repository handover, technical documentation and a user guide, plus a training session and a post-go-live support window. Nothing is downloaded from AppSource and nothing is pre-built on a shelf — the extension is built for your tenant, your data and your process.

What you get

Installable AL source code for your Business Central version and release wave (per-tenant extension or AppSource-packaged app), built against your deployment type

Installation and configuration in your sandbox, then production, including access point credentials, job queue setup and permission set assignment

Technical documentation: object ranges, table/page extensions, codeunit responsibilities, event subscribers, API page contracts, and the OIOUBL field mapping table

End-user guide covering send, resend, status monitoring, rejection handling and the correction workflow, plus a live training session for your finance team

UAT on a sandbox copy of your production environment with real transactions, an agreed acceptance script, and a documented rollback plan

Post-go-live support window for defect fixes and configuration adjustments on the delivered scope

Git repository handover with full commit history, branch strategy and build pipeline notes so your team or another partner can maintain it

Telemetry and monitoring setup guidance (Application Insights queries for send failures and stuck transmissions)

Who this is for

Finance Manager / Controller (Danish entity)

Owns the invoice-to-cash cycle and is accountable for OIOUBL compliance on public-sector sales. Needs invoices to leave Business Central validated and delivered without a re-keying step, and needs to see at a glance which documents are sent, acknowledged or rejected.

Accounts Receivable Team Lead

Handles the day-to-day sending and the fallout when a document is rejected. Needs plain reason codes on the document, a clear correct-and-resend path, and confidence that a resend will not create a duplicate at the receiver.

Business Central Solution Architect / IT Manager

Responsible for keeping the tenant upgrade-safe across release waves. Wants event-subscriber-based integration rather than base-app modification, dedicated permission sets, credentials in isolated storage, telemetry, and the AL source in a repository they control.

External Auditor or Compliance Officer

Needs to prove that what was transmitted matches what was posted. Relies on the immutable archive, the timestamped transmission log and the audit trail linking each posted document to its exact payload and response.

How Denmark OIOUBL / Nemhandel E-Invoicing Compares

Criterion	ECOSIRE	Custom Build	Competitor	Dynamics 365 Business Central Native
Danish OIOUBL profile coverage	Built to your document types and validated against the OIOUBL profile agreed in scoping	Depends entirely on how well your developer researches the profile	Broad Peppol coverage with Danish specifics varying by vendor	Generic Peppol-flavoured export; no full Danish OIOUBL profile
Nemhandel delivery	Integrated with your chosen access point over a swappable configured endpoint	You build and maintain the access point integration yourself	Usually tied to the vendor's own access point and contract	No Nemhandel transmission; export the file and send it elsewhere
Rejection and correction workflow	Reason codes on the document, rejected state, correct-and-resend or credit-and-reissue paths	Commonly deferred to phase two and handled by email in practice	Portal-side status list; correction often happens outside BC	No feedback loop — a rejection surfaces only when the customer chases payment
Tax and master-data mapping	Driven from your VAT Posting Setup and item master with per-customer overrides	Often hardcoded to today's chart of accounts and brittle when it changes	Vendor mapping tables you maintain in parallel to BC master data	Limited mapping; gaps are filled manually per document
Audit archive	Immutable payload and response archive with timestamps, user and transport identifiers	Whatever logging was budgeted for, typically thin	Archive lives in the vendor's portal, exported on request	No archive of transmitted documents inside Business Central
Upgrade safety across release waves	Event subscribers and extensions only; no base-app modification, with a compatibility pass per wave	Risk depends on the developer's discipline; base-app edits are common	Vendor handles it, on the vendor's release schedule	Microsoft-maintained, but the functional gap remains after every upgrade
Source code and ownership	Full AL source plus git repository handover — no runtime-only lock-in	You own it, and you also own every future fix	Runtime package only; behaviour changes require a vendor ticket	Base application; not yours to extend without an extension
Commercial model	One build-to-order fee, then optional maintenance; access point contracted separately by you	Open-ended development cost plus permanent internal maintenance	Per-tenant or per-document subscription, often bundled with transmission	Included in your BC licence, with the compliance gap unaddressed

Frequently Asked Questions about Denmark OIOUBL / Nemhandel E-Invoicing

How long does delivery take?

This is a build-to-order extension, not an AppSource download. Typical delivery is 2-4 weeks from confirmed scope. The clock starts once the scoping call has settled your Business Central deployment type and release wave, your access point, the document types in scope and any localisation apps already installed — not from the day you request a quotation.

Does ECOSIRE act as the Nemhandel access point?

No. The extension transmits through your chosen Nemhandel/Peppol access point over a configurable endpoint, and we integrate against that provider's API during the build. If you have not selected a provider yet, we will scope against a candidate and keep the endpoint configuration swappable so switching later is a setup change, not a rebuild.

What happens to support and updates after go-live?

Every engagement includes a post-go-live support window for defect fixes and configuration adjustments on the delivered scope. Beyond that, you can take a maintenance agreement covering Business Central release-wave compatibility testing, OIOUBL profile updates and access point API changes — or maintain it yourself, since you receive the full AL source and the git repository.

Will this survive Business Central upgrades?

The extension integrates exclusively through event subscribers, table and page extensions, and API pages — no base application objects are modified. That is what keeps it upgrade-safe. We still recommend a release-wave compatibility pass twice a year, because Microsoft can change event signatures and the OIOUBL profile itself is versioned by the Danish authorities.

Does it work on Business Central on-premises as well as SaaS?

Yes. We support current release waves for both. SaaS deployments receive a per-tenant extension (or an AppSource-packaged app where your governance requires it); on-premises deployments receive the same AL source built for your version, with outbound network access to the access point configured on your infrastructure. The deployment model is confirmed during scoping because it affects credential storage and telemetry setup.

Do we get the source code?

Yes. You receive the complete AL source for your version plus a git repository handover with commit history and build notes. There is no runtime-only package and no vendor lock — your team or another partner can maintain the extension without us.

How are rejections from the receiver handled?

Negative acknowledgements are captured against the posted document with the returned reason codes, and the document moves to a rejected state visible in the status FactBox. From there the workflow branches: correct the underlying data and re-send with a new transmission record, or credit and re-issue. Both paths keep the original payload in the archive, so the audit chain stays intact.