Selling to Danish public bodies means the invoice has to arrive as a structured OIOUBL document through Nemhandel, not as a PDF attached to an email. Most finance teams bridge that gap by hand: export the invoice, log into a portal or a third-party web client, retype the EAN/GLN receiver number, the requisitioner and order reference, upload, then hope. When something is rejected days later the accountant is reconciling an ERP that says posted against a network that says nothing arrived. Odoo out of the box gives you a UBL-shaped account.edi layer and a generic EN 16931 export, but it does not implement the Danish OIOUBL profile's identifiers and business rules, does not talk to a Nemhandel access point, and gives you nowhere to record a rejection against the invoice it belongs to.

We build a Danish localisation layer that sits on top of account.move rather than beside it. A models/ extension adds the fields the profile actually needs — receiver EAN/GLN endpoint and scheme, ContractDocumentReference, requisitioner and order reference, AccountingCost — with @api.depends computes that derive whatever can be derived from master data on res.partner and res.company, so users type as little as possible. Tax mapping is data, not code: your Danish VAT codes, reverse-charge and zero-rated cases map to the correct TaxCategory/TaxScheme identifiers through configurable records, so a new tax next year is a configuration change rather than a patch. On post, the document is generated once and rendered two ways — the machine-readable OIOUBL XML and a QWeb report humans and auditors read — from the same posting, so the two can never disagree.

Delivery runs as a queued send. The XML is schema- and Schematron-validated before it ever leaves the database, then handed to your chosen Nemhandel/Peppol access point over its API, with the transmission id, timestamp and payload hash written back onto the invoice. Failures are first-class: a rejection or negative message-level response lands on the invoice chatter with its reason codes parsed into readable lines, moves the record into a rejected state, and offers a guarded correction workflow producing a credit note plus a corrected invoice carrying the correct BillingReference back to the original — so the correction is legally linked, not an unrelated new document. An automated action retries transient transport errors on a backoff and escalates the rest as an activity on the responsible accountant. Access is scoped through ir.model.access.csv plus record rules so an invoicing clerk can send and read status while only a finance manager can force-resend or cancel, and every generated payload is retained as an immutable attachment with its hash — the archive and audit trail your retention rules expect. The same operations are reachable over XML-RPC/JSON-RPC, so an external portal or logistics system can trigger a send or read delivery status without a human opening Odoo.

The module runs on Community and Enterprise alike. Where Enterprise is present we hook into its accounting EDI screens instead of duplicating them; on Community we ship our own send and status views so nothing is Enterprise-gated. It is built for the exact series you run — a __manifest__.py targeting 17.0, 18.0 or 19.0 — against your real chart of accounts, tax configuration and partner data, not a generic demo database.

This is build-to-order, so there is nothing to download today. You request a quotation, we run a short scoping call to confirm your Odoo version and edition, hosting, access-point provider and which document flows are in scope, and we quote a fixed price against that written scope. Typical delivery is one working week from confirmed scope. You get the full source installed and tested on a staging copy of your database with your own invoices, a UAT round with your finance team, then a supervised go-live with a rollback plan, a post-go-live support window, and the git repository handed over to you.