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 one working week: 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.