EHF is Norway's e-invoicing format, and EHF Billing 3.0 is Peppol BIS Billing 3.0 with the Norwegian national rules layered on. Those NO-R rules fire the moment a party is Norwegian: the VAT number has to end in MVA, the organisation number has to check out. InvoiceXML creates EHF documents from JSON, runs the Norwegian rules, and detects the profile automatically on the files you receive.
curl -X POST https://api.invoicexml.com/v1/create/ubl \ -H "Authorization: Bearer YOUR_API_KEY" \ -d '{ "invoice": { ... }, "options": { "profile": "ehf" } }'
{
"valid": true,
"data": {
"profile": "ehf",
"customizationId": "urn:cen.eu:en16931:2017#compliant#
urn:fdc:peppol.eu:2017:poacc:billing:3.0"
}
}
EHF Billing 3.0 does not change the CustomizationID or the document shape: it is Peppol BIS Billing 3.0. What changes is the rule set that fires for Norwegian parties. These are the pieces that send an otherwise-valid BIS invoice back in Norway.
| What it is | Detail | Why it matters |
|---|---|---|
| Authority & artifact | EHF Billing 3.0, governed by DFOe and published on anskaffelser.dev | The same artifact Norwegian buyers validate against, vendored unmodified |
| CustomizationID | urn:fdc:peppol.eu:2017:poacc:billing:3.0 | Identical to plain Peppol BIS: EHF is BIS, so detection keys on the parties, not a separate identifier |
| Seller VAT (NO-R-001) | BT-31 must read NO + nine-digit org number + MVA, e.g. NO123456785MVA |
The single most common reason a Norwegian invoice is rejected when it would pass elsewhere |
| Organisation number | Scheme 0192 for both the Peppol endpoint and the legal registration, with a mod-11 check digit |
A wrong or mistyped org number is a fatal error, not a warning |
| Document types | UBL 2.1 Invoice and CreditNote | Same coverage as every other profile on the platform |
PROFILE-DETECTION notice, never a false rejection.
The same endpoints that power every profile, set to the Norwegian rule set. Each has a free in-browser companion tool, the same auth, and the same NO-R validation behind it.
JSON in, validated EHF Billing out. Profile-stamped and NO-R-checked before delivery.
Open toolDrop any Norwegian UBL file; the profile is detected and the verdict names the rules it applied.
Open toolSame invoice, other syntax, revalidated on the way out.
Open toolA human-readable preview of any Norwegian UBL file, for approvals and archives.
Open toolTurn received EHF into clean JSON your ERP can import.
Open toolLet AI agents draft, validate, and fix Norwegian invoices over MCP.
Open toolWhen a Norwegian rule objects, the finding says so: the NO-R rule ID, a plain-language message, the EN 16931 BT code involved, and the JSON field path to highlight in your form.
"Passes BIS elsewhere but a Norwegian buyer rejects it" is a debugging genre we retired.
{
"valid": false,
"data": {
"profile": "ehf",
"customizationId": "urn:cen.eu:en16931:2017#compliant#
urn:fdc:peppol.eu:2017:poacc:billing:3.0"
},
"errors": [
{
"rule": "NO-R-001",
"layer": "cius",
"message": "A Norwegian seller's VAT identifier must
be NO, then the nine-digit organisation
number, then MVA (e.g. NO123456785MVA).",
"btCodes": ["BT-31"],
"fields": ["seller.vatIdentifier"]
}
]
}
Norway has one of the highest e-invoicing adoption rates in Europe, driven by an early and firm public-sector requirement. Here is where EHF sits today.
Norway implements Directive 2014/55/EU through EHF. See the Mandate Map for how the Norwegian timeline compares with the rest of Europe.
Because EHF Billing is Peppol BIS, it follows the same spring and autumn release cadence, each with a mandatory date. We vendor the artifact unmodified, regression-test it, and flip the switch server-side on the day it becomes mandatory. Your code never changes.
Read the versioning policy and the exact artifact versions running nowThe Peppol May 2026 release becomes mandatory across the network, EHF included, and goes live here the same day.
Validate, convert and embed compliant e-invoices through one API. Start your 30-day free trial. No credit card required.