Danish public-sector buyers will not accept a PDF. If you invoice a municipality, a region, or a state institution in Denmark, the document has to arrive as a structurally valid OIOUBL XML delivered through Nemhandel — and increasingly through Peppol BIS, which Danish practice now runs alongside OIOUBL. ERPNext gives you a clean Sales Invoice, a tax template, a customer master and a print format, but nothing that produces a schema-valid OIOUBL-2.1 invoice, resolves the receiver's endpoint, transmits it, or tells you what happened after it left. Most finance teams close the gap with a portal: someone re-keys the invoice into a web form, downloads a receipt, and files it in a shared drive. That works until volume rises, until a credit note has to reference the original invoice, or until an auditor asks you to prove which exact XML was sent for a given posting.

We build a proper Frappe app — its own repo, its own module, installed with bench get-app and bench install-app — that closes the loop inside ERPNext. A Danish E-Invoicing Settings single DocType holds the sender endpoint (CVR/GLN scheme identifiers), access-point credentials, environment (test/production) and per-company defaults. A child mapping DocType translates ERPNext master data into UBL semantics: Item Tax Templates to Danish VAT categories and rates, UOM to UN/ECE Rec 20 codes, Payment Terms to UBL payment means, and Company Address into the AccountingSupplierParty block. Fields we add live on Customer and Sales Invoice as custom fields shipped in fixtures — EAN/GLN, EndpointID scheme, buyer reference (Rekvirent/contract reference), and the order reference a public buyer requires — so nothing is stored in a stray text field the next upgrade will lose.

Generation and delivery are driven by hooks.py doc events. on_submit on Sales Invoice enqueues a background job that renders the UBL from a Jinja/lxml builder, validates it against the OIOUBL/Peppol BIS schema plus the Schematron business rules, and refuses to transmit on a hard failure — the invoice stays submitted in ERPNext while the delivery record shows exactly which rule broke and on which field. Transmission goes through your chosen Nemhandel access point over its REST/AS4 interface; a dedicated E-Invoice Transmission DocType is the audit spine, storing the generated XML as a private File, the message identifier, timestamps, and every status transition. A scheduler event polls for message-level responses and delivery states, so a rejection lands as a comment and a notification on the invoice rather than in someone's inbox. Rejections open a correction workflow: the app links the corrective Credit Note or re-issued invoice back to the original transmission, carries the correct BillingReference, and keeps both documents in the archive chain. The same posting produces both machine and human output — the validated XML and a matching print format — so what the customer reads and what the system sent can never drift. Whitelisted methods expose retry, re-validate and download-XML to the Frappe REST API and to client-script buttons, and role profiles keep transmission and retry rights separate from ordinary invoice entry.

Delivery is build-to-order, not a marketplace download. After a scoping call we confirm your Frappe/ERPNext version (v15 or v16), your access-point provider, whether you also need inbound Purchase Invoice ingestion, and your VAT and archiving requirements. We then build the app against your version, install it on a staging bench, run UAT with your own invoices and your provider's test endpoint, and only then deploy to production with a rollback plan. Typical delivery is one working week from confirmed scope. You receive the full source in a git repository you own, so nothing about your compliance path is locked to us.