Høringsfristen på Erhvervsstyrelsens ændring af kravbekendtgørelsen for digitale standard bogføringssystemer udløb 17. august 2026. Nu skal styrelsen læse, hvad den har fået.
Det interessante er ikke, at der kommer et høringsnotat. Det gør der altid. Det interessante er, hvilke indvendinger der bliver imødekommet — og hvilke der bliver taget til efterretning uden at der sker noget. De to ting ser ens ud på papiret, og forskellen mellem dem er hele forskellen for den, der skal bygge systemet.
Jeg har selv afgivet høringssvar med syv bemærkninger. Nedenfor tager jeg tre emner: hvad der foreslås, hvad der efter min vurdering ikke holder, og hvad jeg selv ville gøre.
Og så er der datoen. Uanset hvordan styrelsen lander de tre emner, samler de sig ét sted: december 2026. Det er dér, hele markedet skal varsles, indsigelser skal håndteres, og alt skal stå klar til 1. januar 2027 — i den ene måned, hvor både leverandørernes support og kundernes bogholderier er halvt lukkede. Det er ikke tre uafhængige sager. Det er tre sager med samme forfaldsdag.
Tilmeldingen sker af sig selv
Kort for den, der ikke følger det tæt: bogføringsloven skelner mellem registrerede og ikke-registrerede bogføringssystemer. For de registrerede er det udbyderens ansvar, at systemet lever op til kravene. For de ikke-registrerede er det virksomhedens eget. Det er kun de registrerede, ændringen her handler om — og det bliver vigtigt til sidst.
Udkastet træder i kraft 1. januar 2027 og gør tre ting.
01 — Udbyderen tilmelder kunderne. Efter de gældende regler skal systemet gøre det muligt at komme i Nemhandelsregistret. Kunden bliver spurgt og siger ja. Efter udkastet skal udbyderen tilmelde sine kunder, medmindre virksomheden aktivt frabeder sig det. Passivitet bliver selve tilmeldingsgrundlaget.
02 — Systemet skal pege på e-faktura først. Ved fakturering skal systemet slå op i Nemhandelsregistret og vise elektronisk fremsendelse som første valgmulighed, når modtageren er registreret.
03 — MitID på hele brugerbasen. Identiteten på nye og eksisterende kunder, slutkunder og brugere skal bekræftes med MitID. Dertil obligatoriske stamoplysninger på afsendte dokumenter, og låste felter, der fremover kun kan rettes på virk.dk.
Hvor det ikke holder
Tidsplanen kan ikke opfyldes efter sin ordlyd. Varslingspligten træder i kraft 30. november 2026. Virksomheden har fire uger til at gøre indsigelse. Tilmeldingen skal være sket senest 1. januar 2027. Sendes varslet den første mulige dag, udløber indsigelsesfristen 28. december 2026, og udbyderen har tre dage til at tilmelde hele sin kundebase. Sendes det ti dage senere, kan bestemmelsen slet ikke opfyldes.
Læg dertil, hvad opgaven er i praksis. Der står over hundrede registrerede systemer på styrelsens fortegnelse, og de har tilsammen hovedparten af dansk erhvervsliv som kunder. Hver enkelt udbyder skal på fem uger varsle hele sin base, modtage og registrere indsigelser fra dem, der siger nej, og tilmelde resten i et centralt register — i den periode af året, hvor både deres egen support og kundernes bogholderier er lukket ned. Det er ikke en teknisk opgave. Det er en logistisk.
Og hvem får egentlig varslet? Retten til at sige nej tilkommer slutkunden — den bogføringspligtige virksomhed. Men udkastet siger kun, at meddelelsen skal gives "ved direkte besked", ikke ad hvilken kanal. I en stor del af markedet er det revisoren eller bogholderiet, der bruger systemet, og ejeren logger aldrig ind. Gives beskeden i brugerfladen, rammer den bogholderen — ikke den, der har retten til at sige nej.
Opslaget peger på ét register, ikke på infrastrukturen. Nemhandelsregistret er efter styrelsens egen tekniske beskrivelse en central SMP — en af flere mulige adressetjenester i Peppol-arkitekturen. Den generelle vej til at finde en modtager går gennem SML til dét SMP, modtageren er tilknyttet. En modtager, der er fuldt tilgængelig i infrastrukturen, men registreret et andet sted, udløser derfor ikke førstevalget. Set fra brugeren ligner det, at systemet ikke kan sende elektronisk til en, der kan modtage elektronisk.
Og så MitID. Kravet er fornuftigt i sit sigte. Men lad os sige det, som det er: MitID bruges i praksis gennem en app, og den app findes i to butikker — Apples og Googles. Alternativet er kodeviseren, som fungerer, men som ingen udbyder ønsker at bygge et onboardingflow op om. Vi står altså med et krav, der skal styrke kontrollen med danske virksomheders data, og som leveres gennem to amerikanske platforme. Jeg peger ikke på det for at være vanskelig. Jeg peger på det, fordi suverænitet er noget, man taber i små skridt, og fordi det sjældent bliver nævnt, når kravene skrives.
Min vurdering — kravbekendtgørelsen
Retningen er rigtig. Opt-out er efter min vurdering det enkeltgreb, der reelt kan flytte udbredelsen af e-faktura, og udbredelsen er hele forudsætningen for gevinsten — en e-faktura er kun værd noget, hvis modtageren kan tage imod den. Det bør styrelsen stå fast på, også når der kommer pres imod.
Det, jeg ville ændre, er tidsplanen, og det er også det ene af mine syv punkter, jeg helst vil have igennem. Enten rykkes varslingspligten frem, eller også bindes tilmeldingen til fire uger efter varslet frem for til en fast dato den 1. januar 2027. Som det står nu, er indsigelsesfristen formelt fire uger og reelt noget kortere — og retsvirkningen af at overse den er, at man er tilmeldt en offentlig infrastruktur uden at have taget stilling.
Og hvis jeg sad hos en udbyder i dag, ville jeg ikke begynde med koden. Jeg ville begynde med at finde ud af, hvem vi overhovedet skal varsle. Ved vi, hvilke af vores brugere der er slutkunder, og hvilke der bogfører for andre? Har vi en kontaktvej til dem, der ikke logger ind? Det er en kedelig kortlægning, der ikke kan demonstreres for nogen og ikke giver releasenoter. Det er formentlig derfor, den ikke er begyndt ret mange steder.
To versionsnumre, to frister, ingen validering
Erhvervsstyrelsen sendte 15. juni 2026 et ændringsforslag til SAF-T i høring med frist 29. juni 2026. Der kom to høringssvar. To — på en ændring, der rammer samtlige registrerede bogføringssystemer i Danmark. Notatet med styrelsens svar kom 3. juli 2026.
Det er værd at læse, for det er et af de steder, hvor man kan se en myndighed tænke højt.
Det centrale er feltet Deductibles, som deler momsbeløbet på den enkelte posteringslinje i en fradragsberettiget og en ikke-fradragsberettiget del. Det var oprindeligt foreslået obligatorisk. Efter høringen lægger styrelsen op til MIFU — mandatory if used — med frist 1. januar 2027, og derefter obligatorisk fra 1. januar 2028. Bemærk, at det er notatets udspil — ændringen er ikke vedtaget endnu.
Hvad styrelsen svarede — og hvad den ikke gjorde
Styrelsen imødekom to ting. Navnekonflikten rettes: elementet hed DeductibleAmount og kolliderede med feltet inde i sin egen struktur, så det kommer til at hedde Deductibles. Og kravet deles i to frister, så systemer, der endnu ikke understøtter opdelingen, får tid til "at finde en god løsning".
To ting blev ikke imødekommet. Der blev bedt om, at XSD-skemaerne bliver offentliggjort under høringen, så udbydere kan afprøve konsekvensen, mens de stadig kan nå at svare. Styrelsen kan ikke love det, men vil arbejde hen imod det.
Og så blev der bedt om schematroner — de regelfiler, der gør det muligt maskinelt at kontrollere, om en fil faktisk overholder standarden ud over det, skemaet selv fanger. Svaret er kort: "Der er ikke på nuværende tidspunkt planer om at lave og frigive schematroner, ønsket er taget til efterretning."
Dertil kommer det, jeg skrev om i sidste nummer og har peget på i mit eget høringssvar: kravbekendtgørelsen henviser slet ikke til et versionsnummer, men til "en standardfil, som er defineret af myndighederne". Styrelsens nyhed fra februar siger 2.0 fra 1. januar 2027; styrelsens egen tekniske dokumentation beskriver standarden som 2.1. Begge dele er rigtige, og ingen af dem står i bekendtgørelsen.
Min vurdering — SAF-T 2.1
Det største i SAF-T 2.x er ikke Deductibles. Det er springet fra 1.0.
Efter den gældende 1.0 kan en virksomhed nøjes med at kunne danne en headerfil — reelt et forsideark. Med 2.0 bliver Masterfiles og GeneralLedgerEntries obligatoriske. Fra et forsideark til det fulde stamdata- og posteringsudtræk. Dertil kommer MIFU-begrebet, en række felter bundet direkte op på kravbekendtgørelsen, felter beregnet til indberetning til Skattestyrelsen og Danmarks Statistik, og en ny håndtering af tomme værdier.
For en udbyder er det ikke en tilføjelse. Det er en omskrivning af eksportlaget, og det er dét, høringssvaret mente, da der stod, at store dele af systemet skal skrives om.
For en virksomhed betyder det noget andet og mere konkret: den dag du bliver udtaget til kontrol, er forskellen mellem 1.0 og 2.x forskellen mellem at aflevere et forsideark og at aflevere hele din bogføring på transaktionsniveau. Det er værd at have set sit eget udtræk igennem inden da — ikke fordi der nødvendigvis er noget galt, men fordi det er en dårlig dag at opdage det på.
Schematron-svaret er det, der bekymrer mig mest. Uden en bindende, versioneret testpakke bliver et standardformat udfyldt forskelligt af hver udbyder. Resultatet er filer, der hver for sig overholder skemaet, men ikke kan sammenlignes eller behandles automatisk hos modtageren — altså netop ikke den automatisering, hele øvelsen er sat i verden for. At overlade den del til markedet betyder i praksis, at hver leverandør bygger sin egen fortolkning og opdager uenigheden den dag, en myndighed læser filerne ved siden af hinanden.
Her mener jeg, styrelsen skal ombestemme sig. Ikke fordi det er urimeligt at prioritere — men fordi en standard uden en fælles prøve ikke er en standard. Den er en anbefaling.
2027 bliver året med tomme felter. Deductibles bliver MIFU, så det skal kun udfyldes af den, der har oplysningen. Samtidig er det året, hvor leverandørerne skal have bygget det split, alle skal levere året efter. Det er en fornuftig trappe, hvis man bruger den. Bruger man den ikke, bliver 1. januar 2028 en mur.
Og så er der en principiel usikkerhed, som ingen har taget stilling til: splittet er ikke en fast størrelse. Fradragsprocenten efter momslovens § 38 er foreløbig i løbet af året og reguleres først ved årsafslutningen, så linjesplittet i filen er et øjebliksbillede. Filen validerer upåklageligt — men den og momsangivelsen fortæller ikke samme historie, før reguleringen er bogført.
Fordi der ikke kommer schematroner, har jeg bygget en validator. Du trækker din SAF-T-fil ind i browseren og får at vide, hvor den fejler. Filen forlader ikke din maskine — valideringen kører lokalt i browseren. Resultatet er gratis og fuldt synligt.
Danmark venter på en specifikation, det ikke selv styrer
OIOUBL 3.0 blev opgivet, og Danmark går i stedet til Peppol — nærmere bestemt til PINT, Peppols internationale model, med nationale udvidelser ovenpå. Det danske resultat kommer til at hedde Nemhandel Faktura. Styrelsen skriver ærligt hvorfor: den "ønsker ikke at anvende navngivning som er ejet og kontrolleret af private aktører", og henviser til, at Norge gør det samme med EHF og Singapore med InvoiceNow.
Overgangen er bekræftet i høringsnotatet af 27. maj 2026, hvor tolv høringssvar blev behandlet.
Tre ting, der ikke er løst
Tidsplanen hænger i en specifikation, styrelsen ikke ejer. Migrationen er sat til 18 måneder, delt ligeligt mellem test, indfasning og udfasning, og uret begynder først at løbe, når Nemhandel Faktura sættes i produktion. Det kan først ske, når OpenPeppol har udgivet den underliggende specifikation — et arbejde, styrelsen ikke selv styrer. Styrelsen skriver, at de samlede 18 måneder "kun vanskeligt kan udvides", og bagenden er låst af ViDA, der kræver e-fakturering på tværs af EU-grænser fra 1. juli 2030. Skrider startskuddet, skrider hele rækken — og der er ikke luft i den anden ende.
De nationale udvidelser er besluttet nødvendige, ikke undgået. Høringssvarene bad om det modsatte: så få danske særkrav som muligt. Styrelsens vurdering er, at tilpasninger er nødvendige for at sikre datakvalitet og bevare funktionalitet. Det er formentlig rigtigt. Men så er spørgsmålet ikke om der bliver dansk særpræg, kun hvor meget — og den styringsmekanisme, der skal holde udvidelserne i skak bagefter, findes endnu ikke.
Her savner jeg ét tal, som ingen har lagt frem: hvad kommer det til at koste dansk erhvervsliv at bygge, vedligeholde og bruge de særlige felter? Ikke prisen på selve migrationen, men den løbende omkostning ved at have en national variant af et internationalt format. Den regning betales af leverandørerne først og af virksomhederne bagefter, og jeg mener, styrelsen bør regne på den og lægge den frem, før udvidelserne fastlægges. Det er ikke et argument imod tilpasninger. Det er et argument for at vide, hvad de koster.
Og fakturaen er kun det første dokument. Strategien tager fakturaen først, men Nemhandel bærer i dag en hel portefølje: ordrer, kataloger, kreditnotaer, rykkere, forsyningsspecifikationer og svardokumenter. Styrelsen forventer, at de relaterede dokumenter kan fortsætte uændret, men skriver samtidig, at der ikke er truffet beslutning om at opgradere dem. Det samme gælder de offentlige indkøbsdokumenter, hvor Danmark i forvejen har bundet sig til Peppol-standarder. Hvert af de dokumenter rejser det samme spørgsmål om nationale udvidelser en gang til — og den styringsmekanisme, der skal svare på det, er stadig ikke bygget.
Min vurdering — OIOUBL og Peppol
Lad mig først sige, hvor kæden hænger sammen, for det er ikke indlysende udefra.
Bunden er standardkontoplanen: den bestemmer, hvordan en postering kan klassificeres. Ovenpå ligger SAF-T, som er den fil, posteringerne forlader systemet i. Og ovenpå den igen ligger alt det, der udleder noget af tallene — momsindberetningen, Regnskab Basis, Danmarks Statistiks udtræk. E-fakturaen føder den anden ende: det er dér, posteringerne kommer fra. Kort sagt hviler hele automatiseringsdagsordenen på, at de to formater og kontoplanen passer sammen.
Styrelsens eget klimakontoplan-projekt er den bedste illustration. Det afsluttede sin første fase i juni 2026 med ti virksomheder og fem systemleverandører, og pointen med det er netop, at klimatal udledes af bogførte posteringer i stedet for at blive indsamlet ved siden af. Det virker kun, hvis klassifikationen i bunden er stabil. Når kontoplan, filformat og fakturaformat er i bevægelse samtidig, arver alt det ovenpå bevægelsen — også de projekter, der ellers ikke har noget med e-faktura at gøre.
Og så er der den gruppe, ingen taler om. Både kravbekendtgørelsen og SAF-T 2.x rammer kun de registrerede systemer. Det lyder rimeligt, indtil man ser efter, hvem der så står udenfor.
På Erhvervsstyrelsens egen fortegnelse står godt hundrede systemer — Dynamics 365, e-conomic, Visma, Uniconta, Odoo, Xledger og mange flere. Men SAP står der ikke. Det gør Sage, NetSuite og Oracle heller ikke. Altså: en pæn del af de systemer, der kører de største danske koncerner og deres udenlandske søsterselskaber, ligger i det ikke-registrerede spor. Dertil kommer specialbyggede systemer — og den gruppe bliver ikke mindre, nu hvor det er blevet realistisk for en almindelig virksomhed at bygge sit eget med AI-hjælp. Det er præcis den fleksibilitet, bekendtgørelsen for ikke-registrerede systemer er skrevet for at give plads til.
De virksomheder skal stadig kunne sende og modtage e-faktura, og det er dem selv — ikke en udbyder — der hæfter. Alligevel står der ingen steder, hvordan de skal forholde sig til de krav, der nu bliver stillet i det andet spor, eller hvornår noget tilsvarende rammer dem.
Det synes jeg er en fejl, og den er større, end den ser ud. En virksomhed, der bliver presset til en uplanlagt migrering væk fra sit koncernsystem og over på et registreret standardsystem, som ikke kan det, forretningen har brug for, står ikke med en it-opgave. Den står med en risiko for hele driften. Man kan ikke pålægge en virksomhed, der har bygget sit eget system, en udbyderregulering — det ville være forkert. Men man kan godt fortælle den, hvad man har tænkt sig.
Læg dertil asymmetrien i selve infrastrukturen: den samme e-faktura kan sendes ind i den samme infrastruktur, i det ene tilfælde efter MitID-legitimation og med låste stamoplysninger fra CVR, i det andet uden nogen af delene. Adgangspunkterne, der transporterer dokumenterne, kender ikke forskellen — de ser to gyldige dokumenter. Hvis identitetssikring er begrundelsen for kravet i det ene spor, bør man kunne forklare, hvorfor det ikke er nødvendigt i det andet.
Det, jeg ville holde fast i, hvis jeg sad på den anden side af bordet: opt-out, den fælles infrastruktur og overgangen til Peppol. De tre ting er rigtige, og de kommer under pres, fordi de er ubekvemme på kort sigt.
Det, jeg ville give mig på: tidsplanerne. Både varslingsvinduet i december og de 18 måneder, der "kun vanskeligt kan udvides". En tidsplan, der kun kan holde, hvis intet går galt, er ikke en tidsplan. Det er et håb med datoer på.
I støbeskeen
Jeg arbejder på et nummer om de kommende norske regler — forskriftsarbejdet, sendepligten fra 2027 og spørgsmålet om, hvorvidt leverandørerne af regnskabssystemer overhovedet skal reguleres. Det er en beslutning, der falder inden jul, og den ligner den danske mere, end man skulle tro.
Der kommer også samtaler 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.