Den 8. september 2026 opdaterede Erhvervsstyrelsen siden om standardkontoplanen og SAF-T. Én sætning er ændret: fra 1. januar 2027 skal registrerede bogføringssystemer understøtte version 2.1. Ikke 2.0.
I nummer 2 skrev jeg, at kravbekendtgørelsen slet ikke nævner et versionsnummer, og at styrelsens nyhed fra februar 2026 sagde 2.0, mens den tekniske dokumentation beskrev 2.1. Den ene af de to sider er nu rettet. Den anden står der stadig — med 2.0.
Tre emner i dette nummer: versionsnummeret og den beslutning om opt-out, vi stadig venter på · grønne klimadata, der skal komme ud af en finansiel proces · og hvad norske virksomheder efter min vurdering får brug for, når datoen rammer dem.
De ender samme sted, og det er derfor overskriften lyder, som den gør. Datoer kan rykke sig, versionsnumre kan rettes, og forskrifter kan komme sent. Oprydningen i dine egne stamdata bliver hverken mindre eller lettere af nogen af delene — og den er det eneste i hele billedet, du selv bestemmer, hvornår du går i gang med.
Ét tal er rettet. Det andet står der stadig
Kort for den, der ikke følger det tæt: SAF-T er det standardfilformat, et bogføringssystem skal kunne aflevere din bogføring i. Den oprindelige hensigt var at gøre det nemmere at skifte system — bogføringen skal kunne følge med ud, uden at den nye leverandør behøver kende den gamles database. At en myndighed kan læse de samme posteringer, kom til bagefter. Bogføringsloven skelner samtidig mellem registrerede systemer, hvor udbyderen hæfter for kravene, og ikke-registrerede, hvor virksomheden selv gør.
Tre ting er værd at have styr på efter opdateringen den 8. september 2026:
01 — To sider, to versionsnumre. Siden ["Standardkontoplan og SAF-T"](https://erhvervsstyrelsen.dk/standardkontoplan-saf-t) blev opdateret 8. september 2026 og siger nu version 2.1 fra 1. januar 2027. Siden ["SAF-T version 2 og rettelser til standardkontoplanen"](https://erhvervsstyrelsen.dk/saf-t-version-2-og-rettelser-til-standardkontoplanen), opdateret 10. februar 2026, siger stadig: "De registrerede bogføringssystemer skal fra den 1. januar 2027 understøtte version 2.0." Begge sider ligger offentligt på erhvervsstyrelsen.dk.
02 — Bekendtgørelsen nævner fortsat intet versionsnummer. Kravet er en standardfil, som er defineret af myndighederne. Det er ikke en forglemmelse — det er en bevidst konstruktion, der gør det muligt at opdatere formatet uden at ændre en bekendtgørelse. Men det betyder også, at det bindende indhold kan skifte, uden at nogen skal høres om det.
03 — Datoen har ikke flyttet sig. 1. januar 2027 står uændret på begge sider. Og for ikke-registrerede systemer er kravet fortsat version 1.0 — reelt en headerfil, altså et forsideark uden posteringer.
Hvor det ikke holder
Den anden beslutning er der stadig ikke. Ændringen af kravbekendtgørelsen — automatisk tilmelding til Nemhandelsregistret, e-faktura som førstevalg og MitID-legitimering af hele brugerbasen — havde høringsfrist 17. august 2026. I en orientering til høringsparterne den 25. august 2026, som jeg har modtaget som høringspart, skrev styrelsen, at beslutningen var udsat under henvisning til høringssvarene, og at bekendtgørelsen forventedes udstedt medio september 2026. Vi venter stadig, og den må være lige op over. Læg mærke til, at udkastet selv har to datoer: bekendtgørelsen træder i kraft 1. januar 2027, men varslingen forud for tilmeldingen til Nemhandelsregistret allerede 30. november 2026.
Og en udsættelse forlænger ikke forberedelsen — den forkorter den. Kommer bekendtgørelsen senere, uden at 1. januar 2027 rykker med, er der færre uger tilbage til det samme arbejde. Rykker datoen derimod, vinder kun den, der allerede er i gang. Det er værd at sige højt, fordi udsættelser sjældent bliver læst sådan. De bliver læst som tilladelse til at vente.
Min vurdering — SAF-T-versionen og udsættelsen
Det er rimeligt, at en myndighed retter et versionsnummer på en vejledningsside. Det er ikke rimeligt, at rettelsen kun kan opdages ved at lægge to sider ved siden af hinanden og se, at de ikke siger det samme. Når bekendtgørelsen bevidst peger på "det, myndighederne har defineret", er vejledningssiderne reelt dér, kravet bor — og så bør versionsnummeret stå ét sted og bære en dato for, hvad der blev ændret.
Men det er ikke dér, den store regning ligger. Springet fra 1.0 til 2.x er ikke en tilføjelse af felter. Det er skiftet fra at aflevere et forsideark til at aflevere hele bogføringen på transaktionsniveau — stamdata og posteringer, altså kontoplan, kunder, leverandører, momskoder og dimensioner. Og det er dér, en udsættelse ikke hjælper nogen.
For hvad er det egentlig, der tager tid? Ikke koden. Det er dubletterne i kundekartoteket, leverandørerne uden CVR-nummer, konti der aldrig er blevet mappet til standardkontoplanen, momskoder der er brugt forskelligt i 2019 og i 2025, og dimensioner, hvis betydning kun findes i hovedet på én person. Intet af det forhindrer dig i at bogføre i morgen. Alt sammen bliver synligt den dag, filen forlader systemet.
Derfor er mit råd det samme, uanset hvad styrelsen lander på: træk et SAF-T-udtræk ud af dit system i den version, det kan i dag, og læs det igennem. Ikke for at godkende det — for at se, hvad der står. Det er en dårlig dag at opdage sine egne stamdata på, den dag en myndighed beder om filen.
Og har du brug for et sted at begynde, er det her: et værktøj, der siger, hvor filen fejler. Filen forlader ikke din maskine — valideringen kører lokalt i din browser.
Klimatallet falder på et felt, der ikke findes
Klimakontoplan-projektet, som Erhvervsstyrelsen driver sammen med Ressource City i Næstved, afsluttede sin første fase 12. juni 2026 med ti virksomheder og fem leverandører af bogføringssystemer. Metoden er det interessante: deltagernes posteringsudtræk for 2025 blev trukket ud, hver postering klassificeret efter UNSPSC-koder — en international standard for at kategorisere varer og ydelser — og derefter beriget med emissionsfaktorer og aktivitetsdata.
Styrelsens egen formulering er værd at hæfte sig ved: det var første gang i initiativet, at klimadata udledes direkte fra virksomhedernes eksisterende, bogførte data. Anden fase handler om at få klimakontoplanen ind i de bogførings- og ERP-systemer, der allerede er i brug.
Retningen er spændende, og der er et tal, der forklarer hvorfor. Projektbeskrivelsen henviser til opgørelser, hvorefter dataindsamling og -behandling kan udgøre op til 80 procent af omkostningerne ved klimaregnskaber. Bemærk, hvad de 80 procent er: omkostningsandelen — ikke hvor meget af klimadataene der kan udledes af finansdata. Pointen er, at selve rapporteringen er den billige del. Det dyre er at skaffe tallene.
Så vidt myndighedssiden. Fra dem, der sidder med implementeringen til daglig — integratorer, lagerfolk og ERP-konsulenter — hører jeg til gengæld det samme igen og igen. Det er ét problem set fra tre sider:
01 — På fakturaen er emballage et beløb. I fakturamatchet optræder emballage som en tillægslinje med et beløb — altså en pris. Men det danske producentansvar og EU's emballageforordning spørger ikke om en pris. De spørger om materiale og vægt, og den oplysning kan fakturaen i dag ikke bære.
02 — På lageret findes tallet — men lageret er ikke bogføringen. Lagersystemerne er begyndt at registrere emballagen dér, hvor den opstår: ved pakkebordet, med materiale, vægt og CO2 pr. gram, og med særskilt markering af genbrugte kasser. Det er den rigtige kilde. Den ligger bare i et andet system end det, regnskabet aflægges fra.
03 — Felterne er en afhængighed, ikke en opsætning. Emballage- og CO2-felter findes endnu ikke som standard i bogføringssystemerne, og det er ikke noget, en integrator kan beslutte sig ud af. Man er henvist til at følge, hvad leverandøren lægger ind — typisk gennem release notes — og i mellemtiden bygge brugerfelter, dimensioner eller en tabel ved siden af, som skal overleve næste opgradering. Tallet, jeg oftest hører sat på konsekvensen, er fire til syv systemer, der skal køres sammen, før der kan indberettes.
Hvor det ikke holder
En emissionsfaktor er ikke et tal. Det er en årgang. Faktorerne bliver opdateret. Bliver de opdateret ind over historikken, ændrer sidste års klimatal sig, uden at nogen har bogført noget. Spørgsmålet, du skal stille din leverandør, er derfor meget konkret: kan jeg genskabe en indberetning med den faktor, der gjaldt dengang? Kan systemet ikke det, er det et estimeringsværktøj — og det er hele forskellen på et tal, der holder i en kontrol, og et tal, der ikke gør.
Dataene opstår tre steder og skal afstemmes ét. Emballagen opstår fysisk ved pakningen, omkostningen opstår på leverandørfakturaen, og klassifikationen hører hjemme i kontoplanen. Når de tre kilder er uenige, skal noget vinde — og bliver uenigheden stille afstemt væk, inden nogen ser den, er revisionssporet væk med den. Det er samme problem som i første emne, bare med et andet felt: et tal, der ikke kan føres tilbage til en transaktion, er ikke dokumenteret.
Og regelbilledet ovenpå er allerede i gang. EU's emballageforordning PPWR har fundet anvendelse siden 12. august 2026 og flytter, hvem i værdikæden der regnes som producent. Det danske producentansvar kræver registrering og årlig indberetning pr. materialefraktion. Og Omnibus-forenklingen tager børsnoterede små og mellemstore virksomheder helt ud af CSRD-bæredygtighedsrapporteringen og hæver tærsklen for de øvrige til over 1.000 ansatte og 450 mio. euro i omsætning; den danske gennemførelse ventes at gælde fra 1. januar 2027. Tilbage står, at langt de fleste danske virksomheder ikke selv skal rapportere — men bliver spurgt af store kunder, banker og udbud. Kort sagt: kravet rammer dig som leverandør, ikke som rapporteringspligtig.
Min vurdering — de grønne data
Lad mig først sige, hvor jeg mener potentialet ligger. At udlede klimatallet af posteringen i stedet for at indsamle det ved siden af er den billigste af de veje, der er i spil, fordi den genbruger noget, der i forvejen skal være rigtigt. Det er også den vej, der har den bedste chance for at give tal, man kan sammenligne på tværs af virksomheder.
Og så er der en reel uenighed mellem markedet og myndighederne, som jeg synes fortjener at blive sagt uden at tage parti. Myndighedernes halvdel: skal klimatallet kunne sammenlignes og kontrolleres, skal klassifikationen være ensartet helt nede på posteringen — ellers opfinder hver leverandør sin egen. Leverandørernes halvdel: en kontoplan er en regnskabsmæssig klassifikation, og en postering fortæller, hvad noget kostede — ikke hvad det vejede, hvad det var lavet af, eller hvor det fysisk blev af. Skal det med, taler vi ikke om et felt, men om nye stamdata på tusindvis af varenumre og lagerlokationer. Begge har ret om hver deres halvdel.
Derfor mener jeg, at det afgørende spørgsmål bør stilles højt, før nogen skriver et krav: skal klimadataene udledes af posteringen, eller skal de bæres af den? Udledes de, kan klassifikation og emissionsfaktorer ligge centralt og versioneres, og leverandørens opgave er mapning. Bæres de, skal hvert varenummer have ny stamdata, og så er det virksomheden, der skal levere oplysninger, den ikke har i dag. De to svar koster vidt forskellige beløb, og de lander på hver sin part.
Anden fase er præcis det sted, hvor spørgsmålet kan besvares — den handler om at komme ud i de systemer, der allerede er i brug, og det er leverandørerne, der ved, hvad det koster. Det, jeg ville ønske mig, er ikke at den ene side giver sig. Det er, at regnestykket bliver lagt frem, før kravet bliver skrevet.
Læg i øvrigt mærke til, at de to første emner rammer det samme problem i hver sin variation. I SAF-T-udtrækket er det kontoplanen, kunderne, leverandørerne og momskoderne, der ikke er ryddet op. I klimatallet er det materiale og vægt pr. varenummer, som aldrig er blevet registreret nogen steder. Forskellige felter, samme mangel: stamdata, der er gode nok til at bogføre med, og som først falder igennem den dag, de skal forlade systemet og læses af en anden.
Norge er slet ikke nået til de grønne data endnu — dér handler det om e-fakturaen og en forskrift, der ikke er udstedt. Men den tredje variation venter allerede: kunderegistret, og om det kan svare på, hvem der overhovedet kan modtage en faktura.
Norge venter på forskriften. Forberedelsen kan ikke vente
I nummer 3 skrev jeg, at Norge har kalenderen og mangler indholdet. Det billede er uændret: pligten til at sende e-faktura mellem virksomheder gælder fra 1. januar 2027, formatreglerne skal fastsættes i forskrift, senest til december.
Den 3. september 2026 var jeg til samhandlingsarena i Oslo, hvor temaet var regeringens forenklingsstrategi og dens målbillede "fra plikt til flyt". Tre ting tog jeg med derfra, og de handler alle om, hvad der sker efter datoen:
01 — Samtalen handler ikke længere kun om fakturaen. Peppol — netværket, e-fakturaen sendes gennem — blev bygget til dokumenterne i offentlige indkøb, men bærer i dag også logistikdokumenter. En stor del af dagen handlede om fragt- og leverancedokumentation, ikke om bogføring. Det e-fakturaspor, Norge starter i 2027, er altså indgangen til noget bredere end det, loven handler om.
02 — »Fra plikt til flyt« er en pointe, ikke en overskrift. Det praktiske indhold er, at pligten først betaler sig, når data kan bevæge sig videre af sig selv. En e-faktura, der lander som en vedhæftet fil og skal tastes, har kostet afsenderen en omstilling og sparet ingen noget.
03 — Hæftelsesspørgsmålet har ingen adresse endnu. Jeg spurgte fra salen, hvem der hæfter, når en EHF-faktura er forkert — adgangspunktet, der transporterede den, eller systemudbyderen, der dannede den. Efter de gældende regler er svaret den enkelte virksomhed. Det er værd at holde fast i, for det er også svaret i Danmark for de ikke-registrerede systemer.
Hvor det ikke holder
Pligtens rækkevidde afhænger af et register, ikke af en regel. Efter forarbejderne skal man sende e-faktura til de modparter, der står i ELMA, det norske modtagerregister, som drives af Digitaliseringsdirektoratet. Det svar står i proposisjonen — ikke i loven, og endnu ikke i nogen forskrift. Det er en dårlig placering for den oplysning, der afgør, hvem du overhovedet skal sende til.
Og modtagesiden kommer i en anden ombæring. Departementet har varslet overgangsregler, så modtagepligten først skal opfyldes 1. januar 2030, hvor også kravet om et elektronisk regnskabssystem træder i kraft. Bygger man i 2027 kun til at sende, så skal man bygge igen i 2030.
Og leverandørspørgsmålet er stadig et spørgsmål. Udredningen om, hvorvidt regnskabssystemer og deres leverandører skal reguleres, har frist 15. december 2026. Falder den ud som et dansk registreringsspor, flytter en del af arbejdet fra virksomheden over på udbyderen. Falder den ikke, bliver det liggende, hvor det er. Ingen virksomhed kan vente på det svar — men alle kan spørge deres leverandør, hvad leverandøren regner med.
Min vurdering — Norge efter datoen
Jeg er dansk rådgiver og ikke norsk jurist; jeg læser deres dokumenter, som jeg ville læse vores. Men spørgsmålet om, hvad man skal gøre, når man ikke kan læse reglen endnu, er ikke et juridisk spørgsmål. Det er et driftsspørgsmål, og der er fire ting, jeg mener norske virksomheder får brug for.
Et rent kunderegister med organisationsnummer og ELMA-status. Det er den ene forberedelse, der kan laves nu, fordi den ikke afhænger af forskriften: hvem af mine kunder kan modtage, med hvilken identifikator, og hvor mange af mine kartotekskort er dubletter. Det er ikke et projekt. Det er en oprydning — og den er den samme som den, danske virksomheder skal lave til SAF-T.
Et skriftligt svar på, hvem der hæfter. Når reglen ikke placerer ansvaret hos adgangspunktet eller udbyderen, ligger det hos virksomheden. Så bør virksomheden købe det tilbage i kontrakten: hvad garanterer systemudbyderen om formatet, hvad garanterer adgangspunktet om leveringen, og hvem dokumenterer at fakturaen kom frem.
Et arkiv i oprindeligt format. Loven kræver, at en e-faktura opbevares i det format, den kom i. Konverterer systemet indgående fakturaer til sit eget format og gemmer resultatet, er kravet ikke opfyldt — og det træder i kraft samtidig med sendepligten.
Og en plan, der regner 2030 med fra begyndelsen. To datoer, ét system. Det er billigere at bygge modtagesiden ind i arkitekturen nu end at bygge den ovenpå i 2030.
Så er der det, jeg ikke ved, og som er værd at sige højt: jeg kender ikke forskriftens ordlyd, og jeg kan tage fejl af, hvor snæver undtagelsesadgangen bliver. Men ingen af de fire ting ovenfor bliver forkerte, uanset hvordan forskriften lander. Det er præcis derfor, de er værd at gå i gang med.
Og dermed er de tre emner det samme emne. Et versionsnummer kan rettes, en bekendtgørelse kan udsættes, en forskrift kan komme sent, og et klimakrav kan ende med at blive skrevet på den ene eller den anden måde. Datakvaliteten i dit eget system er den eneste forberedelse, der ikke bliver spildt, uanset hvilken vej beslutningerne falder.
I støbeskeen
Jeg er inviteret til at holde oplæg for Regnskap Norges medlemmer i oktober 2026 om, hvad Danmark lærte af at gå først. Erfaringerne derfra deler jeg her i nyhedsbrevet — og vil du høre nærmere allerede nu, er du velkommen til at [booke en halv time](https://book.strukturacompliance.dk/kbr/30min).
SAF-T-validatoren læser i dag din fil og siger, hvor den fejler. Jeg arbejder på at lade den sige mere: hvad i dine stamdata der falder fra, når filen skal bære 2.x i stedet for en headerfil. Har du interesse i den, så skriv til mig, så siger jeg til, når den er klar.
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.