Norway B2B E-Invoicing Requirements 2027

Norway's B2B e-invoicing requirements for 2027 are now law, and they work in two phases rather than as a single switch where every business must both send and receive EHF on the same date. From 1 January 2027, a bookkeeping-obligated business must issue structured e-invoices for its sales to other bookkeeping-obligated businesses. From 1 January 2030, every bookkeeping-obligated business must keep its books in an electronic accounting system, which includes being able to receive e-invoices.

That distinction matters because many English summaries compress the timeline into "mandatory e-invoicing from 2027." The rules are more precise. Skatteetaten's statement on the new e-invoicing regulations, published on 30 September 2026, sets out the phases and adds the condition that shapes the first three years: until 1 January 2030, the duty to issue e-invoices in practice applies only where the bookkeeping-obligated customer can receive them, meaning it is registered in ELMA/Peppol. The statement follows the amending Act of 19 June 2026 (LOV-2026-06-19-39) and the amendment to the bookkeeping regulation of 29 September 2026 (FOR-2026-09-29-1933), which sets the formats, exemptions and start dates.

For finance teams, the practical 2027 question is whether the business can issue a valid Norwegian e-invoice, normally EHF, to each business customer that is registered to receive it. For AP teams, the practical 2030 question is whether the accounting system can receive and process e-invoices as part of electronic bookkeeping. Many companies will still test receiving earlier, especially as suppliers begin sending EHF before 2030, but the legal planning should keep the two dates separate.

EHF is not a PDF invoice sent by email. It is structured invoice data in Norway's Peppol and EN 16931 ecosystem, designed for machine validation, routing, and downstream processing. A PDF rendering may still be useful for humans, but it is not the compliance object the mandate is trying to standardize.

The timeline: from the March 2026 proposal to law, 2027 sending, 2030 receiving

The timeline has eight dated points, but only three of them are operational start dates for most businesses: 2027, 2028 and 2030.

• 16 March 2026: The Ministry of Finance announced the political proposal to accelerate e-invoicing and digital bookkeeping requirements for business.
• 20 March 2026: The Ministry's legislative proposal on e-invoicing set out the phased framing: e-invoice sending from 2027, electronic accounting systems with receive capability from 2030.
• 19 June 2026: The amending Act made both duties law: sales documentation to other bookkeeping-obligated businesses must be issued in an electronic invoice format, and bookkeeping must take place in an electronic accounting system. Formats, exemptions and start dates were left to regulation.
• 29 September 2026: The amendment to bokføringsforskriften set those details, and Skatteetaten published its statement on the rules the next day.
• 1 January 2027: The B2B e-invoice sending requirement starts, together with the approved formats and the NOK 50,000 exemption. Until 2030 it applies in practice only to customers registered in ELMA.
• 1 January 2028: A sales document to a bookkeeping-obligated buyer must state the buyer's organisation number, and the parties can no longer agree that all or part of the sales document will not be sent.
• 31 December 2029: Last day on which seller and buyer may agree to use an electronic invoice format other than the approved standards.
• 1 January 2030: The electronic accounting-system requirement starts, including the ability to receive e-invoices. From then every bookkeeping-obligated business must be able to receive, so the ELMA condition no longer narrows the send duty.

The most useful internal project framing is therefore two-track. The 2026 work is to confirm whether the business is in scope, which of its customers are registered in ELMA, whether its invoicing system can create valid EHF, and whether Peppol sending has been tested. The longer 2030 work is to make sure the accounting environment can hold electronic records and receive e-invoices in a way that supports bookkeeping and audit access.

This also explains why some vendor pages sound more urgent than the law itself. A software vendor may reasonably advise enabling both send and receive capability before 2027 because it reduces operational risk. That is different from saying receiving is legally mandatory for all businesses from 2027.

Who is in scope, and how the NOK 50,000 exemption works

The law is built around bokføringspliktige businesses, meaning businesses subject to Norwegian bookkeeping obligations, and the duty attaches to a sale from one of them to another. For a Norwegian company or sole trader that invoices other businesses, the scope question is usually direct: if the business keeps books under Norwegian rules and so does its customer, the sale is inside the e-invoicing rules unless an exemption applies. Until 2030 the practical scope is narrower, because the duty reaches only customers registered in ELMA to receive e-invoices.

Foreign suppliers need a more careful reading. A company outside Norway may need to send Peppol or EHF invoices to satisfy a Norwegian customer's procurement process, but that does not automatically mean the foreign company is itself subject to the Norwegian bookkeeping-law obligation. Legal scope depends on whether the supplier has Norwegian bookkeeping obligations, for example through a Norwegian establishment, registration position, or other facts that bring it inside the Norwegian rules. Skatteetaten's statement on the regulations does not address foreign suppliers separately.

The small-business exemption is also easy to misread. The NOK 50,000 point is not a limit on invoice value. Under the regulation's new § 1-2, a bookkeeping-obligated business whose turnover does not exceed NOK 50,000 in a calendar year is exempt, provided it is not subject to the Accounting Act and has no duty to file VAT returns. The exemption ends from the point in the year at which turnover passes NOK 50,000. Skatteetaten also lists certain bankruptcy estates, financial institutions, insurers and pension funds among the exemptions.

That distinction matters in practice:

• A Norwegian business with annual turnover well above NOK 50,000 should not treat a single small invoice as exempt just because the invoice value is low.
• A foreign supplier with limited Norway-bound sales still needs to separate legal scope from customer requirements. The customer may ask for EHF even if the supplier is not directly caught by the Norwegian bookkeeping-law change.
• A business that files VAT returns (mva-melding) or is subject to the Accounting Act is outside the small-business exemption, whatever its turnover.

The compliance question is not simply "Do we invoice Norwegian customers?" It is "Are we inside the Norwegian bookkeeping-law scope, and do our customers require structured e-invoices even where the law does not directly attach to us?"

What EHF means in practice: Peppol, EN 16931, and structured XML

EHF, short for Elektronisk Handelsformat, is Norway's structured XML format for invoices, credit notes and other business documents, exchanged between businesses over the Peppol network. EHF Billing 3.0 is the current generation. A finance team does not need to read the full technical specification to prepare, but it does need to know which formats the rules accept and what changes compared with PDF-by-email.

The change is from a document that a person can read to invoice data that a system can validate and route. A PDF invoice shows the supplier name, invoice number, totals, tax amounts, and bank details in a visual layout. An EHF invoice carries those fields as structured XML, so the receiving system can check the data, import it, match it, and post it without relying on manual keying or OCR.

EHF Billing 3.0 is closely aligned with Peppol BIS Billing 3.0, which itself follows the EN 16931 semantic model for European e-invoices. UBL is the syntax layer commonly used to express that data. In plain terms: EN 16931 defines the invoice information that should exist, Peppol BIS Billing 3.0 describes how that information is exchanged in the Peppol network, and Norway's EHF rules adapt that framework for Norwegian use.

The 2026 regulation names the formats that satisfy the B2B rules: EHF Fakturering (EHF Billing), Peppol BIS Billing, EHF Selvfakturering (self-billing) and Peppol BIS Self-Billing, all in version 3.0 or newer. From 1 January 2027 to 31 December 2029, seller and buyer may instead agree to use another electronic invoice format. Skatteetaten reads that as a structured electronic format suited to automated processing, and states that a PDF invoice does not have those properties and cannot be used where the bookkeeping-obligated buyer can receive e-invoices.

EHF is not new for suppliers to the Norwegian public sector. Since 2 April 2019, the regulation on electronic invoicing in public procurement has required contracting authorities covered by the Public Procurement Act to demand e-invoices in an approved standard format in their contracts, and to be able to receive them through Peppol. EHF Billing and Peppol BIS Billing, version 3.0 or newer, are the approved formats, with other EN 16931 formats also accepted for procurements above the EEA thresholds. The 2027 rules carry the same formats into invoicing between businesses.

That is why the mandate belongs with other e-invoicing formats and mandates, not with ordinary email automation. The compliance artefact is not the message body or the attached PDF. It is the structured invoice payload, validated against the relevant format rules and delivered through the expected network path.

This also keeps EHF separate from deeper finance-system obligations. The invoice format changes how invoice data is transmitted and received. It does not, by itself, settle questions about reverse-charge MVA on foreign services, mandatory invoice content fields under Bokføringsforskriften §5-1-1, booking logic, archive policy, or audit-file export.

Peppol delivery basics: Access Points, ELMA, and Norwegian organisation numbers

Peppol is the delivery network, not the invoice format. The format is the structured EHF invoice. The network part is handled through Peppol Access Points, which send and receive business documents on behalf of participants. A sender's system hands the invoice to its Access Point, the Access Point routes it through Peppol, and the receiver's Access Point delivers it to the receiving system.

For Norwegian receivers, the routing identity is tied to the organisation number, the organisasjonsnummer. Norway uses the participant identifier scheme associated with 0192, the ICD code for Norwegian organisation numbers. In practical vendor conversations, that is why teams may see references to 0192 and NO ORGNR when setting up or testing EHF delivery.

ELMA is the Norwegian Peppol address register, run by the Norwegian Digitalisation Agency (Digdir). A sender's Access Point looks the receiver up there to learn whether it can receive EHF and where to deliver it. Under the 2026 rules ELMA also marks the edge of the send duty until 2030, so checking each customer's ELMA registration is a supplier's working scope test. If a registration is missing, wrong, or connected to an old provider, invoices can fail before the customer's AP team ever sees them.

Foreign suppliers should not confuse the Norwegian receiver identifier with their own sender identity. A Swedish, Danish, German, or UK supplier sending Peppol invoices into Norway normally uses an identifier scheme appropriate to its own jurisdiction or Peppol setup, while addressing the Norwegian customer through the customer's Norwegian participant identifier. The supplier does not become a Norwegian entity simply by sending to a Norwegian Peppol address.

Testing is therefore part of readiness, not an optional technical detail. A business should confirm that its software can create a valid EHF invoice, that the intended receiver can be found, that the Access Point route works, and that validation errors are visible to the team responsible for fixing master data or invoice-content problems.

What issuers should prepare before 1 January 2027

For issuers, the readiness question is concrete: can the invoicing system create and send a valid EHF invoice to a Norwegian business recipient? If the answer is unclear, the first task is not to redesign the whole finance stack. It is to ask the accounting software, ERP provider, or e-invoicing provider which EHF version is supported, how Peppol sending is activated, and how failed validations are reported.

Norwegian SMBs already using local accounting platforms may find that EHF sending is available in the existing product, but it may still need to be activated, configured, or tested against live customer data. Mid-market and multinational teams using SAP, Microsoft Dynamics 365, NetSuite, or another shared ERP usually need to confirm the Norway localisation path. That may involve an e-invoicing connector, a Peppol Access Point, or a local service provider that converts the ERP's invoice output into the expected EHF structure.

Foreign suppliers have two parallel questions. The legal question is whether the supplier is subject to Norwegian bookkeeping obligations. The operational question is whether Norwegian customers will expect EHF invoices from 2027 because their own finance processes are moving away from PDF intake. A supplier can be outside direct Norwegian bookkeeping-law scope and still need Peppol sending capability to avoid customer friction.

The issuer workstream should cover:

• Confirm whether the entity is bookkeeping-obligated in Norway and outside the small-business exemption.
• Check which business customers are registered in ELMA. Until 2030, that list is the practical scope of the send duty.
• Confirm whether the invoicing system supports EHF Billing 3.0 and Peppol sending.
• Register or confirm the sender's Peppol identity with the relevant provider.
• Record any customer that has agreed a different structured format for the transition period, and plan its move to an approved format before 31 December 2029.
• Test a real invoice flow with a customer or test receiver, including credit notes and tax scenarios where relevant.
• Decide how PDF copies will be handled, if customers still ask for human-readable versions.
• Document where validation errors land and who fixes master-data issues.

Norway is part of a wider European move from unstructured invoice exchange toward structured B2B invoice data. Teams already preparing for Germany's B2B e-invoicing requirements should still treat Norway as its own implementation, because EHF, local scope rules, and the 2027/2030 phase split are country-specific.

What receivers should prepare for 2030, and why earlier testing still matters

The receiver-side obligation should not be moved forward by assumption. Under the law and the 2026 regulation, 2030 is the date tied to electronic accounting systems, including the ability to receive e-invoices. That is different from saying every Norwegian business must receive EHF from every supplier on 1 January 2027.

Still, AP teams should not ignore receiving until late 2029. The rules themselves give a reason to register earlier. Until 2030, a supplier's duty to send an e-invoice reaches a customer only once that customer is registered in ELMA. A business that registers early therefore receives e-invoices from its bookkeeping-obligated suppliers as a matter of their duty, not their choice; one that waits leaves the format to each supplier. Multinational groups may also decide to enable send and receive together for consistency, even where the statutory dates differ.

The receiver workstream is less about invoice creation and more about intake, validation, and posting. An AP team should know where incoming EHF invoices arrive, how exceptions are surfaced, whether the accounting system imports line-level and tax data correctly, and whether approval workflows still work when the source is XML rather than a PDF in an email inbox. Payment-side fields deserve particular attention, since the structured EHF payload carries cbc:PaymentID and bank-account data that need to flow cleanly into Norwegian payment files; a clear EHF XML to Excel field mapping can help AP reviewers inspect supplier, VAT, payment, and line-item fields before posting. Teams still receiving PDFs from non-EHF suppliers should also have a reliable way to pull the KID, kontonummer, and forfallsdato out of unstructured Norwegian invoices and validate the MOD 10 or MOD 11 checksum before payment.

The 2030 accounting-system requirement also sits near, but not inside, Norway's existing audit-file framework. Norway SAF-T requirements concern accounting data export for tax authority requests. EHF concerns invoice transmission and receipt. Electronic bookkeeping concerns the system and recordkeeping environment. They are related because all three push finance data toward structured records, but they should not be treated as one obligation with one deadline.

For a receiver, a sensible 2026 or 2027 test is narrow: register or verify the receiving endpoint, ask a known supplier or provider to send a test EHF invoice, confirm that the invoice lands in the expected workflow, and check that the imported fields support posting, approval, and audit evidence without manual re-keying.

Quick distinctions to keep straight

• 2027 is the send date, and until 2030 only to customers registered in ELMA; 2030 is the receive-and-electronic-accounting date. Receiving earlier is a readiness choice, not the legal obligation. Likewise, technical Peppol capability does not by itself mean a foreign supplier is in Norwegian bookkeeping-law scope.
• NOK 50,000 is an annual turnover limit, not a per-invoice threshold. It exempts only a business that is also outside the Accounting Act and files no VAT returns, and a business above the limit cannot treat individual low-value invoices as outside the e-invoicing rules.
• A PDF is not an EHF invoice, even if generated electronically. The mandate is concerned with structured, machine-readable, validated invoice fields routed through the e-invoicing network.
• SAF-T, digital bookkeeping, and EHF are not the same thing. SAF-T is audit-file export, digital bookkeeping is the accounting system and records, and EHF is invoice exchange. They share a direction of travel toward structured finance data, but they solve different problems and have different deadlines.

A practical readiness checklist for 2026 and 2027

Use the remaining 2026 window to turn the law into named tasks, owners, and evidence. The checklist should be short enough to manage, but specific enough that it catches both legal-scope and invoice-routing problems.

Scope assessment

• Identify Norwegian entities, branches, or registrations that may be subject to Norwegian bookkeeping obligations.
• Identify foreign suppliers or group companies that invoice Norwegian business customers.
• Check whether any entity relies on the NOK 50,000 exemption, and confirm all three conditions: turnover not above NOK 50,000 in the calendar year, no obligation under the Accounting Act, and no duty to file VAT returns.
• List which business customers are registered in ELMA, since until 2030 they set the practical reach of the send duty.

Issuer readiness for 2027

• Confirm whether the invoicing system supports EHF Billing 3.0 and Peppol sending.
• Confirm the sender's Peppol identity and Access Point arrangement.
• Test invoice creation, validation, routing, and rejection handling before the deadline.
• Test common edge cases such as credit notes, VAT treatment, customer references, and corrected invoices.
• Prepare for 1 January 2028, when invoices to bookkeeping-obligated buyers must carry the buyer's organisation number and the sales document must always be sent.
• Keep evidence of vendor confirmation, test results, and internal process decisions.

Receiver and accounting-system readiness

• Confirm whether the business is already registered in ELMA to receive EHF, and whether the endpoint still points to the right provider.
• Decide when to register, knowing that registration brings bookkeeping-obligated suppliers' invoices inside their send duty, and run an early receive test before it.
• Check that incoming EHF invoices can be matched, approved, posted, and archived without losing required field detail.
• Treat 2030 as an accounting-system and receive-capability milestone, not merely as a later IT upgrade.

Monitoring

• Re-check customers' ELMA registrations through 2027 to 2029, since a customer that registers moves into the send duty.
• Track any agreement to use another structured format, none of which can run past 31 December 2029.
• Watch for updated Skatteetaten guidance, and re-check software-vendor statements against the approved formats.
• Keep separate notes for 2027 send compliance and 2030 electronic-bookkeeping readiness so internal stakeholders do not collapse them into one deadline.