Fra 1. januar 2027 skal norske virksomheder sende e-faktura til hinanden. Ikke som forslag: Stortinget traf lovvedtaket 1. juni 2026, vedtog loven endeligt 8. juni og fik den sanktioneret 19. juni. Datoen er gældende ret.
Standarden er ikke gældende ret. Loven kræver et struktureret, elektronisk format, egnet til automatiseret behandling — og lader det blive ved det. Hvilket format det så er, hvem der slipper, og hvad systemet skal kunne, ligger i en forskrift, Skattedirektoratet endnu ikke har udstedt. Pligten træder i kraft 1. januar 2027.
I sidste nummer skrev jeg, at hele den danske regning forfalder i december. Norge har også en december. Men de to lande har byttet om på, hvad der er svært: vi kender indholdet og kan ikke få kalenderen til at gå op. De har kalenderen og mangler indholdet.
Tre emner. Det sidste handler om Danmark — for Norge står frem mod 15. december ved den skillevej, vi passerede i 2023, og jeg tror ikke, prisen for at gå den forkerte vej er regnet ud. Undervejs skylder jeg at sige, at jeg er dansk rådgiver og ikke norsk jurist. Jeg læser deres dokumenter, som jeg ville læse vores.
Alt det vigtige står et andet sted
Loven fastslår pligten og datoerne. Alt det, der afgør, hvad pligten går ud på, ligger i bokføringsforskriften — og den kompetence er delegeret til Skattedirektoratet. Departementet skriver det selv: formatregler fastsættes i forskrift, undtagelser i forskrift eller ved enkeltvedtak.
Tre ting ligger dermed uden for loven:
01 — Formatet. EHF er direktoratets eget forslag fra høringsnotatet af 20. juni 2025 og allerede det format, norske virksomheder bruger indbyrdes. Men et forslag er ikke en regel. Beslutningen ligger stadig hos Skattedirektoratet — i en forskrift, der endnu ikke er udstedt.
02 — Undtagelserne. Direktoratets forslag var snævert: enkeltpersonforetak med under 50.000 kroner i omsætning og visse konkursboer. I høringen bad flere — Brønnøysundregistrene, GS1 Norway, TietoEvry, Virke — om hensyn til dem, der bruger andre elektroniske formater, og nogle om ren udsættelse. Regnskap Norge sagde nej. Og departementet har selv skrevet, at mindre foretak uden for direktoratets forslag måske bør tilgodeses. Tre stemmer, tre svar — og ingen af dem er svaret endnu.
03 — Kravene til systemet. Loven definerer et elektronisk regnskabssystem som noget, der blandt andet kan behandle en e-faktura automatisk. Hvad det betyder i praksis, står i forskriften. § 7 fjerde ledd giver hjemlen. Resten er blank.
Hvor det ikke holder
Forskriften har ingen frist. Oppdragsbrevet af 16. marts 2026 beder blot om udkast "i god tid før de er ment ikraftsatt". Samme brev sætter en skarp dato på direktoratets øvrige opgaver: 15. december 2026. Den ene opgave har en frist. Den anden har et hensyn. Og "i god tid" er ikke noget, man lægger en releaseplan efter — slet ikke når det er leverandøren og ikke virksomheden, der ejer planen.
Og det farlige er ikke formatet. Det er undtagelserne. Formatet kan man gætte kvalificeret på. Men om man er omfattet fra dag ét? Det kan man ikke — høringsinstanserne er ikke engang enige indbyrdes. Sender du allerede i et andet elektronisk format, ved du ikke, om du får udsættelse, og forskellen mellem de to svar er et projekt. Dertil kommer, at undtagelser også kan gives ved enkeltvedtak: for nogle kommer svaret først i en individuel afgørelse, som skal søges, behandles og indrettes efter. Det tidsforbrug står ikke i nogen kalender.
Min vurdering — den norske forskrift
Delegationen er rigtig. Formatkrav hører ikke hjemme i en lov — de skal kunne følge med teknologien. Sådan er det også i Danmark, hvor bogføringsloven bærer pligten og bekendtgørelserne bærer detaljerne. Det er ikke konstruktionen, der er problemet.
Det er koblingen. Enten skal forskriften have en frist et rimeligt stykke før 1. januar 2027, eller også skal pligten indtræde et fast antal måneder efter, at forskriften er udstedt. Som det står nu, kan hele forberedelsestiden forsvinde, uden at nogen har besluttet det. Danmark lavede den spejlvendte fejl i december: to faste datoer med fem uger imellem, og ingen der regnede på arbejdet. Samme udeladelse, hver sin ende.
Sad jeg hos en norsk leverandør, ville jeg ikke vente. Jeg ville bygge på EHF og skrive ned, hvad jeg havde antaget, og hvad der skulle laves om, hvis antagelsen brast. Det er forskellen på en kalkuleret risiko og en overraskelse. Men det løser kun det ene af to spørgsmål. Det andet er værre: hvem skal du overhovedet sende til?
Svaret findes. Bare ikke i en regel
Den gængse forståelse er, at Norge kræver afsendelse fra 2027 og modtagelse fra 2030. Læser man loven, står der noget andet.
Begge pligter står i samme bestemmelse. § 10 annet ledd: salg til andre bogføringspligtige skal udstedes i elektronisk fakturaformat, køb skal tilsvarende modtages i det. Hele § 10 træder i kraft 1. januar 2027 — altså både det at sende og det at modtage. Det, der først gælder fra 2030, er en helt anden bestemmelse: § 7 fjerde ledd om pligten til overhovedet at bogføre i et elektronisk system.
Modtagepligten flyttes altså ikke af loven. Den flyttes af en overgangsregel, som departementet har varslet og efter de offentligt tilgængelige kilder ikke har udstedt. Og den regel skal bære mere end en dato, for det er dér, svaret på spørgsmålet ovenfor ligger: proposisjonen forklarer, at man skal sende e-faktura til de modparter, der står i Elektronisk mottakerregister, ELMA, og altså kan tage imod. Det er et godt svar. Det står bare i forarbejderne — og kun der.
Hvor det ikke holder
En pligtafgrænsning, der ikke er en regel. Skal du planlægge din fakturering fra 2027, kan du ikke læse ud af loven, at pligten stopper ved ELMA. Du skal læse proposisjonen. Forarbejder har fortolkningsvægt, men de er ikke noget, man bygger et system efter — og formulerer overgangsreglen sig anderledes, er det ordlyden, der gælder.
Dermed bliver registret til pligtens rækkevidde. Det er samme spørgsmål, jeg stillede i sidste nummer, med hårdere konsekvens: dér udløste en modtager uden for Nemhandelsregistret ikke førstevalget. Her udløser hun ikke pligten.
Og en detalje med lang levetid: § 13 annet ledd kræver, at en e-faktura opbevares i sit oprindelige format. Det lyder som arkiv. Det er systemkrav. Konverterer du indgående fakturaer til dit eget format og gemmer resultatet, opfylder du det ikke — og bestemmelsen træder i kraft samtidig med sendepligten.
Min vurdering — at sende og modtage e-faktura
Rigtig retning. Vanskeligste rækkefølge. Uheldig placering af svaret.
Rækkefølgen først. At starte med afsenderne bygger volumen op og er lettere at kontrollere. Men værdien af et netværk afhænger af, hvor mange der kan tage imod — og gevinsten ved forslaget er anslået til omkring 10 milliarder norske kroner over tyve år. En e-faktura, der lander som vedhæftet fil, fordi modtageren ikke kan andet, har kostet afsenderen en omstilling og sparet ingen noget som helst.
ELMA-afgrænsningen løser præcis det: du skal ikke sende til nogen, der ikke kan modtage. Konstruktionen ligner den, Erhvervsstyrelsen har i høring herhjemme, hvor systemet slår op i Nemhandelsregistret. Begge er uudstedte — men det danske er dog et udkast med en ordlyd, man kan læse og gøre indsigelse mod. Flyt sætningen fra forarbejderne ind i overgangsreglen, og gør det tidligt nok til, at nogen kan nå at bygge efter den.
Så er der ét spørgsmål tilbage, og det er det dyreste af dem alle: hvem skal egentlig hæfte for, at systemet kan alt det her? Loven har allerede svaret — og jeg tror ikke, regningen for det svar er blevet regnet ud.
Danmark har to bekendtgørelser. Hvad får Norge?
I sidste nummer kaldte jeg leverandørreguleringen en beslutning, der falder inden jul. Præcisering: det, der falder 15. december, er en udredning. Det norske finansdepartement har bedt Skattedirektoratet vurdere, om regnskabssystemer og deres leverandører bør reguleres — og i givet fald skrive et høringsnotat om hvordan. Bemærk, hvem der bad om det: departementet skriver, at flere høringsinstanser selv rejste behovet. Det er ikke noget, branchen har fået trukket ned over hovedet.
Men se, hvad loven allerede har valgt. Der er ingen registreringsordning, ingen fortegnelse og intet udbyderansvar nogen steder. § 7 fjerde ledd: "Bokføring skal skje i et elektronisk regnskapssystem … Departementet kan i forskrift fastsette nærmere krav til elektroniske regnskapssystemer." Pligten ligger på virksomheden. Kravene til systemet bliver krav, virksomheden skal opfylde.
Det er præcis den ene af vores to modeller. Derfor ender dette nyhedsbrev i Danmark.
01 — Spor 1 — de registrerede. Udbyderen anmelder systemet til Erhvervsstyrelsen, før det markedsføres, og kommer på en offentlig fortegnelse. Kravene retter sig mod udbyderen — bestemmelserne begynder "En udbyder … skal" — og bøden rammer udbyderen. Anmeldelsen kontrolleres på forhånd, og styrelsen kan læne sig på en ISAE-erklæring eller en ISO 27001-certificering.
02 — Spor 2 — de ikke-registrerede. Her hedder formlen "Virksomheden skal sikre", og bøden rammer virksomheden. Ingen anmeldelse, ingen fortegnelse. Kontrollen er risikobaseret og kommer bagefter — og efterlever man ikke et påbud om at lovliggøre sit system, kan styrelsen påbyde et skifte til et registreret.
03 — Og valget er dit, ikke myndighedens. Bogføringslovens § 16, stk. 2: virksomheden skal sikre, at systemet enten er registreret eller opfylder kravene til de ikke-registrerede. Et enten-eller, du selv står i.
Hvad Norge går glip af uden et spor 1
Spor 2 fritager ingen for arbejdet. Kravene skal opfyldes, uanset hvilket spor man er i. Spørgsmålet er kun, hvor mange gange arbejdet skal laves — og hver gentagelse koster timer og kroner, som i sidste ende er samfundets.
Ligger ansvaret hos udbyderen, bliver kravet læst, fortolket, bygget og testet én gang pr. system. Ligger det hos virksomheden: én gang pr. virksomhed. Og det er ikke bare koden. Det er analysen først — hvad betyder forskriften for netop mit system, hvilke felter mangler, hvad skal migreres, hvem gør det, hvad koster det. Og dét er den samme opgave igen og igen: to virksomheder på det samme bogføringssystem skal nå frem til nøjagtig det samme svar om, hvad systemet mangler — men de betaler for at finde det hver for sig.
Danmark har godt hundrede registrerede systemer på fortegnelsen, og de har hovedparten af dansk erhvervsliv som kunder. Kravene er altså analyseret og bygget omkring hundrede gange. Uden et spor 1 skal de bygges én gang pr. bogføringspligtig virksomhed. Samme regel, to helt forskellige regninger — og forskellen betales af erhvervslivet, ikke af staten. Det regnestykke har jeg ikke set nogen lave i Norge.
Staten betaler så i den anden ende. Uden anmeldelsesordning er der ingen at kontrollere systemet hos, så tilsynet bliver en virksomhedskontrol, én ad gangen — hvor spørgsmålet "lever dette system op til kravene" stilles forfra hver gang, også når svaret er det samme, fordi det er det samme system.
Lægger Norge et spor 1 oven på, er der én ting værd at tage med herfra: Danmarks to bekendtgørelser stiller ikke de samme krav. Kun det registrerede spor har et udmøntet it-sikkerhedsregime med risikovurdering og syv minimumsområder. Et registreret system skal kunne generere SAF-T-filen, eksportere den til en anden udbyder og indlæse den; et ikke-registreret skal kunne generere den. Og kravet om, at sikkerhedskopien skal ligge hos en ikke nærtstående part, rammer kun de ikke-registrerede. Ingen af de forskelle er en afvejning, nogen har skrevet ned. De er en rest af to bekendtgørelser, skrevet med tretten måneders mellemrum. Derfor står to spørgsmål ubesvarede: hvorfor har kun det ene spor et it-sikkerhedsregime, når det netop er de ikke-registrerede systemer, ingen har set på forhånd? Og hvorfor må den, der selv hæfter, ikke passe på sin egen sikkerhedskopi, når en kommerciel udbyder gerne må?
Min vurdering — de to spor
To spor er det rigtige svar, og det er Danmarks mest undervurderede greb. Uden spor 2 ville enhver bogføringspligtig blive tvunget over på et registreret standardsystem — det kan koncernerne på SAP ikke, og det kan den, der har bygget sit eget, heller ikke. Uden spor 1 er der ingen til at bære arbejdet på vegne af de mange. Ingen af dem kan klare opgaven alene.
Og det er dét, Norge skal tage stilling til nu. Som loven er vedtaget, har Norge spor 2: pligten ligger på den bogføringspligtige, og systemkravene kommer som krav til virksomheden. Udredningen til 15. december afgør, om der skal lægges et spor 1 oven på.
Vælger Norge kun spor 1, lukker man de virksomheder ude, der ikke kan bruge et standardsystem — og det er ikke de små, det er koncernerne og dem, der har bygget deres eget. Bliver man kun ved spor 2, får man ingen forhåndskontrol og intet greb om leverandørerne, selvom det er dem, der rent faktisk bygger e-fakturaen og den automatiserede behandling.
Får Norge begge spor, får man den danske styrke — og risikerer den danske asymmetri. Forskellen er, at Norge kan nå at beslutte, hvad forskellen mellem sporene skal være, før det andet spor skrives. Danmark tog aldrig den beslutning. Jeg har en klar holdning til, hvor den bør lande; den tager jeg gerne med dem, der skal træffe den.
Til sidst det, der gør de to lande værd at læse ved siden af hinanden. Vi kender indholdet og kan ikke få kalenderen til at gå op. De har kalenderen og har ikke udstedt indholdet. Begge dele afgøres i december — den danske varslingspligt træder i kraft 30. november og skal være eksekveret 1. januar, den norske udredning afleveres 15. december. Skal du levere i begge lande, og det skal en pæn del af de danske softwarehuse, får du to sæt krav, der ligner hinanden nok til, at man tror de er ens, og adskiller sig nok til, at det gør ondt. Begge landes svar bliver skrevet i den samme måned.
I støbeskeen
Norstella holder samhandlingsarena i Oslo den 3. september 2026 med den norske forenklingsstrategi "Fra plikt til flyt" som tema. Jeg er tilmeldt, og det, dagen giver, hører hjemme i et af de kommende numre.
Og så er der samtalerne med europæiske virksomheder, der står midt i kravene — hvad det kostede, hvad de undervurderede, og hvad de ville gøre om. De udkommer kun her.