Norway B2B E-Invoicing Requirements 2027

Norway's B2B e-invoicing requirements for 2027 are best understood as a phased proposal, not a single switch where every business must both send and receive EHF on the same date. Under the current proposal, bookkeeping-obligated businesses must send structured e-invoices from 1 January 2027. The obligation to use an electronic accounting system, including the ability to receive e-invoices, starts separately from 1 January 2030.

That distinction matters because many English summaries compress the timeline into "mandatory e-invoicing from 2027." The official proposal is more precise. Norway's Ministry of Finance proposal on e-invoicing says bookkeeping-obligated businesses must send e-invoices from 1 January 2027 and use an electronic accounting system, including receiving e-invoices, from 1 January 2030.

For finance teams, the practical 2027 question is whether the business can issue a valid Norwegian e-invoice, normally EHF, to a business customer that can 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 if 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: March 2026 proposal, 2027 sending, 2030 accounting-system readiness

The timeline has four planning points, but only two of them are operational start dates for most businesses.

• 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 legislative proposal page gave the clearer phased framing: e-invoice sending from 2027, electronic accounting systems with receive capability from 2030.
• 1 January 2027: Proposed start date for the B2B e-invoice sending requirement for businesses within scope.
• 1 January 2030: Proposed start date for the electronic accounting-system requirement, including receiving e-invoices.

There is also a December 2026 watchpoint. Further assessments or clarifications from Skattedirektoratet are expected by 15 December 2026 on adjacent extensions and technical matters. That should be treated as a monitoring item for compliance owners, not as a separate deadline that every finance team must implement against in isolation.

The most useful internal project framing is therefore two-track. The 2026 work is to confirm whether the business is in scope, 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 proposal is built around bokføringspliktige businesses, meaning businesses subject to Norwegian bookkeeping obligations. For a Norwegian company or sole trader, that usually makes the scope question fairly direct: if the business is required to keep books under Norwegian rules and invoices other businesses, it should assume the e-invoicing proposal is relevant unless a specific exemption applies.

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.

The proposed small-business exemption is also easy to misread. The NOK 50,000 point is not a limit on invoice value. It is a turnover-level concept, connected to very small businesses that are below NOK 50,000 in turnover and are not otherwise accounting- or VAT-return obligated. Final regulation is expected to define the exact boundaries, so the safest wording is that the proposal is designed not to pull the smallest non-reporting businesses into EHF solely because they issue a small number of invoices.

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 is MVA-registered or otherwise reporting to Norwegian authorities should not assume the small-business exemption applies without checking the final rules.

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 e-invoice format for structured business documents. In the current generation, EHF Billing 3.0 sits inside the wider Peppol and European e-invoicing framework. A finance team does not need to read the full technical specification to prepare, but it does need to know 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.

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, answer every question about reverse-charge MVA on foreign services, the 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 receiver-registration concept many Norwegian practitioners still refer to when discussing whether an organisation can receive EHF. The practical question is whether the receiver is discoverable for Peppol routing and whether the registered endpoint points to the right receiving system. If the address is missing, wrong, or connected to an old provider, invoices can fail before the 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 in scope for the Norwegian proposal.
• 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.
• 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 proposal described in the Ministry material, 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. Supplier behavior can change before the legal receive date. Some Norwegian suppliers will update their invoicing workflows for 2027 and prefer EHF because their own sending process is already configured. 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 also help AP reviewers inspect supplier, VAT, payment, and line-item fields before posting. Import-related AP work may also need a separate TVINN import VAT reconciliation workflow to tie supplier invoices and forwarder bills to customs declarations and MVA reporting. 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.

Common misunderstandings to avoid when planning Norway EHF readiness

Misunderstanding 1: 2027 means universal mandatory receiving. The 2027 date is the proposed sending date. The 2030 date is the proposed electronic-accounting-system date, including receiving e-invoices. A company may choose to enable receiving earlier, but that is a readiness choice, not the same legal statement.

Misunderstanding 2: NOK 50,000 is a per-invoice threshold. The NOK 50,000 concept is about very small businesses and turnover, not the value of a single invoice. A business above the relevant annual threshold cannot treat individual low-value invoices as outside the e-invoicing rules for that reason alone.

Misunderstanding 3: A PDF invoice is an e-invoice if it was created electronically. A PDF may be digital, but it is not the structured EHF invoice the mandate is concerned with. The difference is whether invoice fields exist as machine-readable, validated data that can be routed and processed through the e-invoicing network.

Misunderstanding 4: SAF-T, digital bookkeeping, and EHF are the same thing. They belong to the same broader move toward structured finance data, but they solve different problems. SAF-T is about audit-file export, digital bookkeeping is about the accounting system and records, and EHF is about invoice exchange. Payroll-side structured reporting to Skatteetaten sits in yet another track — see the monthly A-melding obligation for foreign employers with Norwegian payroll for how that filing differs from invoice-side compliance.

Misunderstanding 5: Peppol capability automatically means legal scope. A company can be technically able to send Peppol invoices into Norway without being directly subject to Norwegian bookkeeping obligations. The technical capability may still be commercially necessary if Norwegian customers ask for EHF, but it should not be confused with legal scope.

These distinctions are not academic. They affect which entities are included in a project plan, which vendors must be contacted, what evidence compliance teams keep, and how much work must be finished before 1 January 2027 rather than before 2030.

A practical readiness checklist for 2026 and 2027

Use the remaining 2026 window to turn the Norway B2B e-invoicing requirements 2027 proposal 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 is relying on the proposed NOK 50,000 small-business exemption, and revisit that position when final regulations are published.

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.
• Keep evidence of vendor confirmation, test results, and internal process decisions.

Receiver and accounting-system readiness

• Confirm whether the business is already registered to receive EHF, and whether the endpoint still points to the right provider.
• Run an early receive test if suppliers are likely to switch before 2030.
• 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

• Track final regulations and any Skattedirektoratet clarifications before the 2027 start date.
• Re-check software-vendor statements after the final technical rules are known.
• Keep separate notes for 2027 send compliance and 2030 electronic-bookkeeping readiness so internal stakeholders do not collapse them into one deadline.