Mange virksomheder tror, at danske krav i Business Central mest handler om moms og kontoplan. I praksis handler det om mere end det, og Naviteam møder typisk kravene i projekter, hvor virksomheder vil implementere, opgradere eller rydde op i deres Business Central-opsætning.
Resumé
- Hvis I bruger Business Central i Danmark, skal løsningen kunne håndtere digital bogføring, e-fakturering og danske formater som OIOUBL og Peppol BIS, og det er netop den type krav Naviteam ofte hjælper virksomheder med at afklare i implementeringer og opgraderinger.
- Et PDF-bilag er ikke en e-faktura. Ifølge Erhvervsstyrelsen skal e-faktura være struktureret data, som systemer kan behandle automatisk.
- Cloududgaven af Business Central er beskrevet som registreret digitalt bogføringssystem i Danmark, og Learn beskriver understøttelse af NemHandel, OIOUBL og Peppol BIS.
- Fra 1. juli 2030 bliver e-faktura et krav ved handel med virksomheder i andre EU-lande, så opsætningen bør vurderes før kravet rammer drift, integrationer og kunderelationer.
- Kig især efter fem ting: korrekt format, korrekt identifikator, dokumenteret opsætning, realistisk test og klar plan for SAF-T, data og ansvar.
Kernen er enkel: Et system, der fungerer regnskabsmæssigt, er ikke nødvendigvis sat op til danske formatkrav, e-fakturering og digital bogføring. Hvis opsætning, add-ons og arbejdsgange ikke passer sammen, får I manuelle mellemled, fejl i data og sværere compliance.
Hvad betyder danske krav i Business Central helt konkret?
Det betyder, at Business Central skal håndtere bogføring, dokumentation og e-faktura efter danske regler. Erhvervsstyrelsen og Learn peger især på digital bogføring, OIOUBL, Peppol BIS og korrekt elektronisk udveksling via NemHandel.
Når danske krav bliver overset, sker det tit, fordi virksomheden ser systemet som et økonomiprogram og ikke som en del af en samlet dokument- og transaktionskæde. Kravene handler ikke kun om at kunne bogføre en salgsfaktura. De handler om, hvordan fakturaen oprettes, sendes, modtages, arkiveres og senere kan dokumenteres.
På Erhvervsstyrelsens vejledning til udbydere af digitale standard bogføringssystemer fremgår det, at systemer automatisk skal kunne håndtere e-fakturaer i både OIOUBL og Peppol BIS. Learn-siden om danske compliancefunktioner i Business Central beskriver samtidig, at cloududgaven af Business Central er registreret som digitalt bogføringssystem i Danmark. En typisk misforståelse er, at en faktura sendt som PDF på mail opfylder e-faktura-kravet. Det gør den ikke.
“Naviteam arbejder med Business Central fra A-Z, så dataflytning, UAT og cutover kan planlægges sammen med danske compliancekrav i stedet for bagefter.”
Skal jeres Business Central være et registreret digitalt bogføringssystem?
Ja, for de fleste danske virksomheder er et registreret digitalt bogføringssystem den sikre vej. I cloud-opsætninger bruger Naviteam typisk Business Central som udgangspunkt, fordi platformen er beskrevet som registreret i Danmark på Learn.
Det vigtige her er ansvarsfordelingen. Erhvervsstyrelsen beskriver, at virksomheder med et registreret digitalt bogføringssystem kan lade systemudbyderen bære ansvaret for, at systemet opfylder de tekniske standardkrav. Det fritager ikke virksomheden for korrekt brug, men det reducerer risikoen for at bygge kritiske processer på et system, der ikke er lavet til danske regler.
For virksomheder, der ikke aflægger årsregnskab efter årsregnskabsloven, træder kravet om digital bogføring i kraft 1. januar 2026, ifølge Erhvervsstyrelsens vejledning til bogføringsloven. Praktisk tip: Tjek ikke kun, om selve platformen er registreret. Tjek om jeres konkrete opsætning, integrationer og udvidelser stadig følger den model, I regner med.
Hvilke 7 danske krav skal jeres Business Central håndtere?
De syv vigtigste krav handler om format, identifikation, sporbarhed og dokumentation. Hvis bare ét led mangler, får I en løsning, der bogfører korrekt, men ikke nødvendigvis lever op til danske proceskrav.
Når virksomheder laver en intern vurdering, giver det mening at tænke i kravgrupper frem for funktioner. I skal ikke kun spørge, om systemet “kan sende faktura”. I skal spørge, hvilket format det sender i, hvordan modtager identificeres, og hvordan processen kan dokumenteres ved kontrol.
- Digital bogføring: Transaktioner og bilag skal kunne håndteres digitalt efter bogføringslovens krav.
- Registreret bogføringssystem eller tilsvarende setup: Cloududgaven af Business Central er relevant her, men jeres konkrete brug skal stadig vurderes.
- E-faktura i OIOUBL: Det er den danske standard, som systemet skal kunne håndtere automatisk.
- E-faktura i Peppol BIS: EU-standarden er central ved bredere handel og bliver endnu vigtigere frem mod 2030.
- NemHandel eller tilsvarende transportvej: Fakturaen skal kunne sendes og modtages som struktureret data, ikke som mailbilag.
- Danske identifikatorer: CVR-nummer, GLN-nummer, P-nummer og SE-nummer skal kunne bruges korrekt i afsendelse og modtagelse.
- SAF-T og dokumentationsspor: Data skal kunne udtrækkes og forklares, hvis myndigheder eller revisor efterspørger det.
Hvad er forskellen på OIOUBL og Peppol BIS?
OIOUBL er den danske e-fakturastandard, mens Peppol BIS er den europæiske standard for strukturerede forretningsdokumenter. Begge formater er relevante i Business Central, fordi danske krav og grænseoverskridende handel peger i hver sin retning.
OIOUBL har længe været centralt i dansk offentlig og privat elektronisk fakturering. Peppol BIS er designet til bred interoperabilitet på tværs af lande og netværk. Hvis jeres kunder primært er danske, vil OIOUBL ofte være det første format, der skal fungere stabilt. Hvis I handler på tværs af EU, bør Peppol BIS være en del af arkitekturen fra start.
En klassisk fejl er at tro, at valget står mellem de to. I praksis skal mange virksomheder kunne begge dele. Kravet fra Erhvervsstyrelsen peger netop på, at digitale standard bogføringssystemer skal kunne håndtere begge formater automatisk. Det er ikke et enten-eller, men et både-og i den tekniske opsætning.
Hvordan vurderer I, om jeres opsætning kan sende og modtage e-faktura korrekt?
Start med en teknisk og procesmæssig test i tre trin: format, kanal og modtagerdata. Business Central kan konfigureres til NemHandel med relevante apps og certificerede adgangspunkter, men funktion på papiret er ikke det samme som drift i praksis.
Tjek formatet. Faktura og kreditnota skal kunne genereres som strukturerede e-dokumenter i OIOUBL og, hvis relevant, Peppol BIS. Learn-artiklen om NemHandel i Business Central beskriver den grundlæggende opsætning med E-Document Core, connector og OIOUBL-relaterede komponenter.
Tjek transportvejen. En faktura er ikke compliant, bare fordi den kan eksporteres. Den skal kunne sendes gennem korrekt kanal, typisk via NemHandel eller Peppol-adgangspunkt, og den skal kunne modtages retur uden manuel omformning.
Tjek modtagerdata. Hvis CVR-nummer, GLN-nummer eller P-nummer er forkert placeret eller mangler, fejler afsendelsen ofte først sent i forløbet. Praktisk tip: Test med rigtige kundetyper og ikke kun med interne demodata.
“Naviteam lægger vægt på små leverancer og træning af superbrugere, fordi korrekt e-fakturering i Business Central først giver værdi, når processerne faktisk bliver brugt i hverdagen.”
Hvordan håndterer I danske identifikatorer som CVR-nummer, GLN-nummer og P-nummer?
I skal håndtere identifikatorer som forretningskritiske datafelter, ikke som almindelige stamdata. Erhvervsstyrelsen nævner konkret CVR-nummer, GLN-nummer, P-nummer og SE-nummer som relevante modtageridentifikatorer i e-fakturering.
CVR-nummer identificerer virksomheden juridisk. P-nummer identificerer produktionsenheden. GLN-nummer bruges ofte i elektronisk samhandel som adressérbar identifikator. Det fremgår også af Ballonmand.dk’s guide til EAN og fakturering, hvor forskellen mellem korrekt modtageridentifikation og en faktura, der reelt kan behandles i offentlige systemer, bliver gjort meget konkret. SE-nummer kan stadig være relevant i enkelte sammenhænge. Hvis jeres masterdata er ufuldstændige, bliver e-fakturering ustabil, selv om systemopsætningen er korrekt.
En udbredt misforståelse er, at et CVR-nummer altid er nok. Det er det ikke. Nogle modtagere skal adresseres via GLN, andre via P-nummer afhængigt af proces og modtageopsætning. Derfor bør validering af stamdata indgå i onboarding af kunder og leverandører, ikke kun i økonomiafdelingens oprydning.
Hvordan forbereder I jer på kravet om e-faktura i EU fra 2030?
I bør forberede jer nu, hvis I handler med virksomheder i andre EU-lande. Erhvervsstyrelsen oplyser, at e-faktura fra 1. juli 2030 bliver et krav ved handel med virksomheder i andre EU-lande.
Første skridt er at kortlægge, hvilke kunder og leverandører der vil blive berørt. Hvis en væsentlig del af omsætningen går til B2B i EU, bør Peppol BIS og tilhørende transportveje prioriteres tidligt. Hvis handlen mest er national i dag, kan I stadig bruge perioden frem mod 2030 til at rydde op i stamdata, dokumentformater og roller.
Næste skridt er at vurdere integrationer. Hvis salgssystem, webshop eller EDI-løsning leverer data til Business Central, skal feltmapping og dokumentregler ses igennem. Mange problemer opstår ikke i økonomimodulet, men i det system der sender kildedata ind.
Sidste skridt er governance. Beslut, hvem der ejer formatkrav, test, ændringsstyring og fejlretning. Ellers bliver EU-kravet behandlet som et rent IT-projekt, selv om det i praksis rammer salg, økonomi og kundeservice på samme tid.
Hvad er forskellen på et registreret og et ikke-registreret bogføringssystem?
Et registreret digitalt bogføringssystem er vurderet i forhold til de danske standardkrav, mens et ikke-registreret system kræver mere ansvar og dokumentation hos virksomheden selv. Forskellen har betydning for e-faktura, sikkerhed og dataudtræk som SAF-T.
Erhvervsstyrelsen kobler registrerede systemer til de funktioner, som bogføringsloven kræver om digital bogføring og IT-sikkerhed. For ikke-registrerede systemer ligger mere af byrden hos virksomheden. Det gælder både dokumentation af processer og evnen til at levere relevante udtræk.
SAF-T er et godt eksempel. Ifølge Erhvervsstyrelsen gælder SAF-T 2.0 som nyere krav for registrerede bogføringssystemer, mens version 1.0 fortsat er minimum for ikke-registrerede systemer. Praktisk tip: Se ikke SAF-T som et isoleret eksportkrav. Hvis jeres datafelter, bogføringslogik eller bilagsrelationer er svage, bliver ethvert SAF-T-udtræk svært at bruge.
Hvordan laver I en realistisk gap-analyse i Business Central?
En god gap-analyse sammenholder lovkrav, faktiske processer og systemopsætning. Hos Naviteam bruges workshops, proceskortlægning og UAT ofte til at finde de steder, hvor Business Central ser korrekt ud i demo, men fejler i drift.
Det afgørende er at vurdere systemet ud fra virkelige scenarier. En salgsordre til dansk kunde, en kreditnota via e-faktura, en leverandørfaktura modtaget som struktureret dokument og et dataudtræk til kontrol giver mere værdi end en generel funktionsliste.
I praksis bliver analysen stærkere, hvis I arbejder med få faste punkter:
- Lovkrav: digital bogføring, e-faktura, OIOUBL, Peppol BIS, NemHandel, SAF-T.
- Proceskrav: hvem opretter data, hvem validerer modtageridentifikatorer, hvem godkender fejlrettelser.
- Systemkrav: apps, adgangspunkter, felter, mapping, arkivering, logning.
- Testkrav: UAT, negative testcases, test af kreditnotaer, test af returfejl.
En almindelig fejl er at behandle afvigelser som “små tilretninger”, før man har vurderet opgraderbarhed og driftsansvar. Hvis en lokal tilpasning løser dagens krav men gør næste opgradering dyr, er det ikke nødvendigvis den billigste løsning.
Hvornår er standard Business Central nok, og hvornår kræver danske krav add-ons eller tilpasning?
Standard Business Central er ofte et stærkt udgangspunkt, men danske krav kræver tit mere end standardopsætning. NemHandel, e-dokumenter, godkendelsesflow og rapportering afhænger tit af apps, konfiguration og stram styring af ændringer.
Hvis jeres behov svarer til det, Learn beskriver for danske compliancefunktioner og e-dokumenter, kan I komme langt med standardplatformen plus korrekt opsætning og certificerede forbindelser. Hvis I derimod har mange specialprocesser, ældre integrationer eller særlige dokumentkrav, bør I forvente et lag af add-ons eller begrænsede tilpasninger.
Misforståelsen her er, at flere tilpasninger altid giver bedre compliance. Ofte er det omvendt. Jo mere særkode I lægger oven på centrale bogførings- og dokumentprocesser, jo mere test og governance kræver hver ændring. Derfor bør valget mellem standard, add-on og tilpasning altid ske ud fra drift, dokumentation og opgraderbarhed, ikke kun ønskelisten fra den enkelte afdeling.