From 1 January 2027, Norwegian companies must send e-invoices to each other. Not as a proposal: the Storting passed the bill in its first vote on 1 June 2026, adopted it finally on 8 June, and had it sanctioned on 19 June. The date is law.
The standard is not law. The Act requires a structured, electronic format, suitable for automated processing — and leaves it at that. Which format that is, who is exempt, and what the system must be able to do sits in a regulation the Norwegian Tax Directorate has not yet issued. The obligation enters into force on 1 January 2027.
In the last issue I wrote that the whole Danish bill falls due in December. Norway has a December too. But the two countries have swapped what is hard: we know the content and cannot make the calendar work. They have the calendar and are missing the content.
Three topics. The last one is about Denmark — because in the run-up to 15 December, Norway stands at the crossroads we passed in 2023, and I do not think the price of taking the wrong path has been calculated. Along the way I owe you this: I am a Danish adviser, not a Norwegian lawyer. I read their documents the way I would read ours.
Everything important is somewhere else
The Act establishes the obligation and the dates. Everything that determines what the obligation consists of sits in the Norwegian bookkeeping regulation — and that competence is delegated to the Tax Directorate. The Ministry writes it itself: format rules are set by regulation, exemptions by regulation or by individual decision.
Three things thus sit outside the Act:
01 — The format. EHF is the Directorate's own proposal from the consultation paper of 20 June 2025 and already the format Norwegian companies use among themselves. But a proposal is not a rule. The decision still rests with the Tax Directorate — in a regulation that has not yet been issued.
02 — The exemptions. The Directorate's proposal was narrow: sole proprietorships with less than NOK 50,000 in revenue and certain bankruptcy estates. In the consultation, several parties — the Brønnøysund Register Centre, GS1 Norway, TietoEvry, Virke — asked for consideration of those using other electronic formats, and some for outright postponement. Regnskap Norge said no. And the Ministry has itself written that smaller enterprises beyond the Directorate's proposal should perhaps be accommodated. Three voices, three answers — and none of them is the answer yet.
03 — The requirements for the system. The Act defines an electronic accounting system as something that can, among other things, process an e-invoice automatically. What that means in practice sits in the regulation. Section 7, fourth paragraph provides the authority. The rest is blank.
Where it does not hold
The regulation has no deadline. The assignment letter of 16 March 2026 merely asks for drafts "in good time before they are meant to enter into force". The same letter puts a hard date on the Directorate's other tasks: 15 December 2026. One task has a deadline. The other has a consideration. And "in good time" is not something you build a release plan on — least of all when it is the vendor, not the company, that owns the plan.
And the dangerous part is not the format. It is the exemptions. The format you can make a qualified guess at. But whether you are covered from day one? You cannot — the consultation bodies do not even agree among themselves. If you already send in another electronic format, you do not know whether you will get a postponement, and the difference between the two answers is a project. Add that exemptions can also be granted by individual decision: for some, the answer only comes in an individual ruling that must be applied for, processed and adapted to. That time is not in any calendar.
My assessment — the Norwegian regulation
The delegation is right. Format requirements do not belong in an act of parliament — they must be able to keep pace with technology. That is how it works in Denmark too, where the Bookkeeping Act carries the obligation and the executive orders carry the details. The construction is not the problem.
It is the coupling. Either the regulation gets a deadline a reasonable distance before 1 January 2027, or the obligation takes effect a fixed number of months after the regulation is issued. As it stands, the entire preparation window can vanish without anyone having decided it. Denmark made the mirror-image mistake in December: two fixed dates five weeks apart, and no one counting the work. The same omission, at opposite ends.
If I sat at a Norwegian vendor, I would not wait. I would build on EHF and write down what I had assumed and what would have to be redone if the assumption failed. That is the difference between a calculated risk and a surprise. But that only solves one of two questions. The other is worse: who are you even supposed to send to?
The answer exists. Just not in a rule
The common understanding is that Norway requires sending from 2027 and receiving from 2030. Read the Act, and it says something else.
Both obligations sit in the same provision. Section 10, second paragraph: sales to other entities subject to bookkeeping obligations must be issued in an electronic invoice format, and purchases must correspondingly be received in it. All of section 10 enters into force on 1 January 2027 — both sending and receiving. What only applies from 2030 is an entirely different provision: section 7, fourth paragraph, on the obligation to keep the books in an electronic system at all.
So the receiving obligation is not moved by the Act. It is moved by a transitional rule the Ministry has announced and, according to the publicly available sources, has not issued. And that rule has to carry more than a date, because that is where the answer to the question above lives: the bill explains that you must send e-invoices to the counterparties listed in the Elektronisk mottakerregister, ELMA — those who can receive. It is a good answer. It just sits in the preparatory works — and only there.
Where it does not hold
A delimitation of the obligation that is not a rule. If you are planning your invoicing from 2027, you cannot read from the Act that the obligation stops at ELMA. You have to read the bill. Preparatory works carry interpretive weight, but they are not something you build a system on — and if the transitional rule is worded differently, the wording is what counts.
The registry thereby becomes the reach of the obligation. It is the same question I asked in the last issue, with a harder consequence: there, a recipient outside the Nemhandel registry did not trigger the first choice. Here, she does not trigger the obligation.
And a detail with a long life: section 13, second paragraph requires an e-invoice to be stored in its original format. It sounds like archiving. It is a system requirement. If you convert incoming invoices to your own format and store the result, you do not meet it — and the provision enters into force together with the sending obligation.
My assessment — sending and receiving e-invoices
Right direction. Hardest possible order. Unfortunate placement of the answer.
The order first. Starting with the senders builds volume and is easier to enforce. But the value of a network depends on how many can receive — and the gain from the proposal is estimated at around NOK 10 billion over twenty years. An e-invoice that lands as an attachment because the recipient can do nothing else has cost the sender a transition and saved no one anything.
The ELMA delimitation solves exactly that: you are not required to send to anyone who cannot receive. The construction resembles the one the Danish Business Authority has in consultation at home, where the system looks up the Nemhandel registry. Both are unissued — but the Danish one is at least a draft with a wording you can read and object to. Move the sentence from the preparatory works into the transitional rule, and do it early enough that someone can build to it.
That leaves one question, and it is the most expensive of them all: who is actually supposed to be liable for the system being able to do all this? The Act has already answered — and I do not think the bill for that answer has been calculated.
Denmark has two executive orders. What does Norway get?
In the last issue I called the vendor regulation a decision landing before Christmas. A clarification: what lands on 15 December is a review. The Norwegian Ministry of Finance has asked the Tax Directorate to assess whether accounting systems and their vendors should be regulated — and if so, to write a consultation paper on how. Note who asked for it: the Ministry writes that several consultation bodies raised the need themselves. This is not something forced on the industry.
But look at what the Act has already chosen. There is no registration scheme, no public list and no vendor liability anywhere. Section 7, fourth paragraph: "Bookkeeping shall take place in an electronic accounting system … The Ministry may by regulation lay down further requirements for electronic accounting systems." The obligation rests on the company. The system requirements will be requirements the company must meet.
That is precisely one of our two models. Which is why this newsletter ends in Denmark.
01 — Track 1 — the registered. The vendor notifies the system to the Danish Business Authority before marketing it and is entered on a public list. The requirements address the vendor — the provisions open with "A provider … shall" — and the fine hits the vendor. The notification is checked in advance, and the authority can lean on an ISAE assurance report or an ISO 27001 certification.
02 — Track 2 — the non-registered. Here the formula is "The company shall ensure", and the fine hits the company. No notification, no list. Enforcement is risk-based and comes afterwards — and if a company fails to comply with an order to bring its system into conformity, the authority can order a switch to a registered one.
03 — And the choice is yours, not the authority's. Section 16(2) of the Bookkeeping Act: the company must ensure that the system is either registered or meets the requirements for non-registered systems. An either/or that you stand in yourself.
What Norway misses without a track 1
Track 2 exempts no one from the work. The requirements must be met whichever track you are in. The only question is how many times the work gets done — and every repetition costs hours and money that are ultimately society's.
If the responsibility sits with the vendor, the requirement is read, interpreted, built and tested once per system. If it sits with the company: once per company. And it is not just the code. It is the analysis first — what does the regulation mean for my system in particular, which fields are missing, what must be migrated, who does it, what does it cost. And that is the same task over and over: two companies on the same bookkeeping system must arrive at exactly the same answer about what the system lacks — but they pay to find it separately.
Denmark has a good hundred registered systems on its list, and they count the bulk of Danish business as customers. So the requirements have been analysed and built roughly a hundred times. Without a track 1, they must be built once per company subject to bookkeeping obligations. The same rule, two very different bills — and the difference is paid by business, not by the state. I have not seen anyone in Norway do that calculation.
The state then pays at the other end. Without a notification scheme there is no one to check the system with, so supervision becomes company-by-company inspection — where the question "does this system meet the requirements" is asked from scratch every time, even when the answer is the same because it is the same system.
If Norway does add a track 1, one thing from here is worth taking along: Denmark's two executive orders do not impose the same requirements. Only the registered track has an implemented IT security regime with risk assessment and seven minimum areas. A registered system must be able to generate the SAF-T file, export it to another provider and import it; a non-registered one must be able to generate it. And the requirement that the backup must sit with a party at arm's length hits only the non-registered. None of those differences is a trade-off anyone wrote down. They are the residue of two orders written thirteen months apart. Which leaves two questions unanswered: why does only one track have an IT security regime, when it is precisely the non-registered systems no one has inspected in advance? And why may the party who is itself liable not look after its own backup, when a commercial provider may?
My assessment — the two tracks
Two tracks is the right answer, and it is Denmark's most underrated move. Without track 2, every entity subject to bookkeeping obligations would be forced onto a registered standard system — the groups on SAP cannot do that, and neither can those who built their own. Without track 1, there is no one to carry the work on behalf of the many. Neither can do the job alone.
And that is what Norway must decide now. As the Act stands, Norway has track 2: the obligation rests on the bookkeeping entity, and the system requirements arrive as requirements on the company. The review due 15 December determines whether a track 1 is laid on top.
If Norway chooses only track 1, it shuts out the companies that cannot use a standard system — and that is not the small ones, it is the groups and those who built their own. If it stays with track 2 alone, it gets no advance control and no grip on the vendors, even though they are the ones actually building the e-invoice and the automated processing.
If Norway gets both tracks, it gets the Danish strength — and risks the Danish asymmetry. The difference is that Norway can still decide what the difference between the tracks should be before the second track is written. Denmark never made that decision. I have a clear view of where it should land; I will gladly take it up with those who have to make it.
Finally, what makes the two countries worth reading side by side. We know the content and cannot make the calendar work. They have the calendar and have not issued the content. Both are decided in December — the Danish notification duty enters into force on 30 November and must be executed by 1 January; the Norwegian review is delivered on 15 December. If you have to deliver in both countries, and a fair share of Danish software houses do, you get two sets of requirements that resemble each other enough to be mistaken for identical and differ enough to hurt. Both countries' answers will be written in the same month.
In the works
Norstella holds its collaboration forum, the samhandlingsarena, in Oslo on 3 September 2026, themed on the Norwegian simplification strategy "Fra plikt til flyt" ("From obligation to flow"). I am registered, and what the day yields belongs in one of the coming issues.
And then there are the conversations with European companies in the middle of the requirements — what it cost, what they underestimated, and what they would do differently. Those appear only here.