The Three Norwegian Billing Documents Peppol Does Not Have

Peppol BIS Billing 3.0 covers the invoice and the credit note. Norway uses three billing documents it does not cover: EHF Reminder 3.0 (purring), EHF Forward Billing 3.0 (gjennomfakturering) and EHF Payment Request 3.0 (betalingsforespørsel). All three are published by DFØ as part of EHF Post-Award G3, all three travel as a UBL invoice over the same Peppol network as your invoices, and each one is a separate opt-in in your Peppol address entry — because each declares its own specification identifier and its own process identifier, which is the pair Peppol uses to route a delivery.

That last point is the one that costs implementation time. A Norwegian trading partner whose invoices arrive perfectly may be unable to receive a reminder, and nothing about the invoice working tells you which. This page sets out what each document is for, what is genuinely different about it, and how to check a partner before you plan around an assumption.

What is EHF Reminder 3.0, and what does it change?

It is the electronic payment reminder, and DFØ's definition is one line: a document that reminds the customer that a payment is delayed. The current version is 3.0.1, and it reached its present form in the EHF Post-Award G3 release of 16 February 2023.

Mechanically it is Peppol BIS Billing 3.0 and EHF Billing 3.0 with the data model cut back to what is needed to recognise and pay the original invoice. Around twenty business terms and groups present on an ordinary invoice are removed — the invoice period, the purchase order and contract references, the whole delivery group, the document-level allowance group, and the line-level pricing detail among them. Two changes matter more than the subtractions:

• The reference to the invoice being chased becomes mandatory, and single. On a Peppol invoice the preceding-invoice-reference group is optional and repeatable. In a reminder its cardinality is 1..1. A reminder that does not say which invoice it is about is not valid, which is exactly right for a document whose only job is to be matched against something already in the buyer's ledger.
• The reminder fee has its own code. DFØ added a code list, Reminder charge reason code, containing one code — REM — used in the document-level charge reason term. The fee (gebyr) is expressed as a document-level AllowanceCharge with the charge indicator set true, the reason code REM, the amount, and a VAT category. There is nowhere else in Peppol BIS Billing to put it.

The reason a reminder is a regulated document rather than a courtesy email is Norwegian law. The conditions a supplier must satisfy before sending one come from inkassoloven, the debt-collection act of 13 May 1988 no. 26, and its section 3a covers the case where the reminder is sent electronically. That is why the Norwegian market treats purring as part of the billing chain and most of Europe does not.

What is EHF Forward Billing 3.0 actually for?

Electricity. Specifically: a grid company forwarding its network-services invoice to the end customer through that customer's power supplier.

This is worth stating plainly, because the name invites a general reading. The current version is 3.0.2, and the specification is written as forward billing in the abstract — but the only sector usage DFØ documents is the energy sector, and the regulatory basis for the document is electricity regulation. The Norwegian Water Resources and Energy Directorate set the basis in its report 48-2016, in force from 1 September 2016; enforcement passed to the Norwegian Energy Regulatory Authority (RME) on 1 November 2019. Under the settlement regulation Avregningsforskriften, section 7-4b, EHF Billing is the standard format for distributing the base data for invoices and credit notes on grid-owner services, and the metering point identifies the end user in the exchange.

Three design consequences follow, and they are what make this a different document rather than a differently-labelled invoice:

• It is an invoice or a credit note, not a new document type. The difference is declared in the specification identifier — the EHF forward-billing conformance clause on top of the Peppol BIS Billing 3.0 customisation — and in a process identifier that belongs to DFØ. Two Peppol rules are deliberately switched off to allow it, including the rule that would otherwise require the customer's legal-entity details.
• The customer may be a consumer. On an ordinary EN 16931 invoice the customer's legal-entity element is mandatory. Here it is optional, and its presence or absence is how a business customer is distinguished from a household one — except in the energy sector, where the same element identifies the power supplier instead.
• The grid company's original invoice rides along as a PDF. It is attached as base64 and identified as Original invoice (or Original credit note), and the settlement details — due date, account number and KID — are removed from the payment giro for household customers, because the end user pays the power supplier rather than the grid company. The PDF has to say on its face that it is not the valid invoice. One metering point per invoice, no more.

If you were hoping to use this to pass a supplier's cost through to a client in property management or shared services, it is the wrong instrument. That is an ordinary invoice with your own commercial terms on it.

What is EHF Payment Request 3.0, and why is it not an invoice?

Because nothing is being sold. A payment request asks an organisation's own payment function to pay somebody who is entitled to money, and entitlement is not a sale. The current version is 3.0.0, and it is built on UBL 2.2.

Its roles are the clearest way to see the difference. Instead of a seller and a buyer there are four: the payment party that organises the payment, the applicant entitled to the money, the review party that decides whether the entitlement exists, and the party acting on the applicant's behalf. DFØ's two worked examples are both public-sector disbursements: compensation ordered by a court for a victim of violence, routed by the Norwegian National Courts Administration to its own accounting system; and research funding approved by the Ministry of Education and Research and paid out to an applicant through a university.

Practically, the document carries payment means rather than tax: where payment is by credit transfer the payment account identifier is mandatory, the payment means code is the credit transfer code, and the remittance reference — in Norway, the KID — travels in the payment identifier. It is an instruction to pay, and the reason an invoice should not be used for it is that an invoice asserts a taxable supply that did not happen.

Why does each document need its own SMP opt-in?

Because Peppol routes on a pair of identifiers, and all three declare a different pair.

A Peppol delivery is resolved from the document type identifier and the process identifier advertised against a participant's address in a Service Metadata Publisher. EHF Billing, EHF Reminder, EHF Forward Billing and EHF Payment Request each declare their own specification and their own process, so each appears as a separate entry. Nothing about being Norwegian, or being on Peppol, or having working invoices implies any of the other three.

This is also where the national layer sits in the Peppol rulebook rather than outside it. Section 6 of the Norway Peppol Authority Specific Requirements — the document OpenPeppol approved for Norway on 17 September 2025 — points implementers at the local specifications on DFØ's site for exactly this reason: the invoice is Peppol's, and the documents around it are Norway's.

The useful consequence is that this is all public and checkable before you write any code. A participant's address entry lists every document type it accepts, and a lookup against the organisation number returns the list.

If you are not sure which number on a Norwegian company's paperwork is the one to look up, which Peppol identifier is yours covers that across the schemes we see most often, and how a Norwegian business becomes reachable for EHF invoices explains who publishes a Norwegian participant and why a private company files nothing with ELMA. You can run the lookup yourself from GoRoute's SMP registration and lookup page.

Where GoRoute stands on these three

EHF Billing invoices and credit notes are in production. Norwegian delivery went live on 16 September 2026. At the time of writing we have carried no Norwegian production traffic yet, which is a statement about volume rather than readiness.

The three documents on this page were built on 17 September 2026 and proved end to end on our test network — JSON in, EHF XML out, validated against the official EHF rules, and delivered to a receiver. They have not yet run in production, and we would rather say that than let it be discovered. The same day also covered EHF Selvfakturering (self-billing), Catalogue, Ordering, Order Agreement, Advanced Ordering and Despatch Advice.

Two areas we do not support, stated rather than left to discovery. The EHF pre-award G2 set — ESPD, supplier list, document folder — is public tendering rather than invoicing, and we do not implement it. The Payment domain, which carries ISO 20022 messages over Peppol, we do not implement either, and DFØ lists additional testing for it as still to be announced. EHF Punch Out 3.0 we validate but cannot route, because no Peppol network identifier exists for it.

What is still unsettled

The 2027 B2B date is an announcement with a bill behind it, not law. In March 2026 the Norwegian government moved mandatory B2B e-invoicing from 2028 to 1 January 2027, and the legislative proposal went to the Storting. Until Parliament passes it, that is a government proposal and this page treats it as one. Our Norway page keeps the dates and the scope question in one place.

Nothing published says the mandate extends to these three documents. The announcement is about issuing structured invoices. These specifications have been part of EHF independently of the mandate for years, and we read their status as unchanged rather than as confirmed — that is inference, marked as inference.

What this page does not cover

The invoice itself, and who falls inside the mandate. Both belong to the Norway page: the format, scheme 0192, the VAT category codes and the mandate scope.

Registration. Who publishes a Norwegian participant, what your provider must check first, and what happens when another provider already holds you are answered in how a Norwegian business becomes reachable for EHF invoices.

The ordering and logistics documents. EHF Catalogue, Ordering, Order Agreement, Advanced Ordering, Despatch Advice and Peppol Logistics are a procurement topic rather than a billing one, and they are not on this page.

What to do next

Look up your Norwegian counterparty's address entry before you scope anything. It takes one query and it turns four assumptions into four facts.

If you are building the integration, the document types, the lookup and the delivery endpoints are in the developer documentation, and the Peppol API integration guide is the shortest path from your own invoice data to a validated EHF document — you should not have to author UBL by hand. Recorded walkthroughs of the ERP connectors are on tutorials. If you would rather have somebody map your Norwegian document flows with you — which of the three you actually need, and in which direction — book a session.

Next read: how a Norwegian business becomes reachable for EHF invoices, which is the registration half of the same problem.

Sources: anskaffelser.dev, DFØ's specification site, for EHF Post-Award G3 and the implementation guidelines, rules, code lists and identifiers of EHF Reminder 3.0 (version 3.0.1), EHF Forward Billing 3.0 (version 3.0.2) and EHF Payment Request 3.0 (version 3.0.0), all read on 1 October 2026; the Norwegian debt-collection act of 13 May 1988 no. 26 and its section 3a for the legal frame of an electronically sent reminder; DFØ's forward-billing guideline for the Norwegian Water Resources and Energy Directorate report 48-2016, the transfer of enforcement to the Norwegian Energy Regulatory Authority on 1 November 2019, and section 7-4b of the settlement regulation; and docs.peppol.eu for what Peppol BIS Billing 3.0 itself covers. GoRoute's own release record is the source for the production date of 16 September 2026 and the test deliveries of 17 September 2026. The 1 January 2027 B2B date is the Norwegian government's March 2026 announcement, with the legislative proposal before the Storting. Last reviewed 2026-10-01.