Danske cloudregnskabsprogrammer: ændringslog og eksport

Forside › Cloud- og SaaS-forensik · Gennemgået oktober 2026 · Af John Nielsen

Et registreret digitalt standard bogføringssystem skal efter de danske regler tildele hver bogført transaktion et fortløbende nummer, registrere hvem der bogførte, gemme rettelser som nye posteringer og sikre, at bogførte transaktioner ikke kan ændres, tilbagedateres eller slettes. Det giver en stærkere sporbarhed end i ældre lokale systemer. Men sporene dækker kun det bogførte. Kladder, slettede bilag før bogføring, brugerrettigheder og integrationer ligger andre steder i systemet og skal sikres særskilt.

Artiklen er skrevet til revisorer og sagkyndige, der skal sikre og analysere data fra cloudbaserede regnskabsprogrammer, fx e-conomic, Dinero eller Uniconta. Funktioner og menuer varierer, så beskrivelsen er generel. Den bredere ERP-metode er beskrevet i ERP-systemers audit trail teknisk.

Hvad reglerne kræver af systemet

Bekendtgørelsen om krav til digitale standard bogføringssystemer stiller blandt andet disse krav, som har direkte betydning for en undersøgelse:

Fortløbende transaktionsnummer eller id · Huller eller spring i rækken kan undersøges
Initialer eller lignende for den, der bogførte · Bogføringen kan knyttes til en brugerkonto
Rettelser sker ved nye posteringer · Den oprindelige postering bevares ved siden af rettelsen
Bogførte transaktioner kan ikke ændres, tilbagedateres eller slettes · Ændringer efter bogføring skal kunne ses
Opbevaring i 5 år i et struktureret format · Historikken findes, også efter skift af abonnement
Automatisk fuld sikkerhedskopi mindst ugentligt og inkrementel dagligt · Leverandøren har kopier, der kan belyse tidligere tilstande

Reglerne er senest ændret ved en bekendtgørelse fra 22. september 2026, der trådte i kraft 29. september 2026. Den skærper blandt andet kravene til e-faktura og bankafstemning, og systemet skal kunne danne en CSV- eller SAF-T-fil med bogføringsdata til indberetning af årsrapport. To krav har betydning for sporbarheden: Kunder skal bekræfte identiteten med MitID ved første login fra 1. marts 2027, og brugere, der tilføjer eller ændrer bankoplysninger og andre supplerende stamoplysninger, skal legitimere sig med MitID fra 1. januar 2028. Hvad loven kræver af virksomheden, og hvordan det bruges juridisk, er behandlet på Digitale bogføringssystemer: hvad systemet skal kunne vise.

Lagene i et cloudregnskabsprogram

Bogførte posteringer. Finansposter med transaktionsnummer, bilagsnummer, dato, konto, beløb, tekst og bruger. Det er kernen, og den er beskyttet mod ændring.

Kladder. Posteringer, der er indtastet, men ikke bogført. De kan normalt ændres og slettes frit, og sletning efterlader ofte intet spor. En undersøgelse af, hvad der skete før bogføring, kræver derfor andre kilder.

Bilag. Filer knyttet til posteringer eller liggende i en bilagsindbakke. Et bilag kan være uploadet, erstattet eller fjernet fra en postering. Om systemet logger det, varierer.

Stamdata. Kunder, leverandører, bankkonti, momskoder. Ændring af en leverandørs bankkonto er et klassisk spor i sager om fejlbetalinger, og ikke alle systemer har feltlog på stamdata.

Brugere og adgang. Brugerliste, roller, invitationer, adgang for revisor eller bogholder fra et andet firma og loginhistorik.

Integrationer. Apps og API-forbindelser til bank, webshop, lønsystem og bilagsscanning. De bogfører ofte under en teknisk bruger eller under den bruger, der godkendte integrationen.

Eksportveje

Standardrapporter og kontoudtog · Hvad den giver: Læsbart overblik · Begrænsning: Afledte data, ofte uden transaktions-id og bruger
Eksport af finansposter (CSV eller Excel) · Hvad den giver: Alle posteringer med felter · Begrænsning: Felterne afhænger af eksportens opsætning
Standardiseret revisionsfil (SAF-T) · Hvad den giver: Struktureret, maskinlæsbar helhed · Begrænsning: Ikke nødvendigvis tilgængelig i alle systemer endnu
API · Hvad den giver: Fuld adgang til posteringer, bilag og ofte logs · Begrænsning: Kræver teknisk opsætning og dokumentation
Leverandørens udtræk · Hvad den giver: Data, kunden ikke selv kan se, fx backup eller interne logs · Begrænsning: Kræver anmodning og tid

Den mest robuste sikring kombinerer en struktureret eksport af alle posteringer for perioden, en API- eller filkopi af bilagene, eksport af brugerliste og rettigheder og en skriftlig anmodning til leverandøren om loginhistorik og eventuelle interne ændringslogs. Hver fil hashes ved modtagelse. Hvorfor gentagen eksport ikke giver samme hashværdi, er forklaret i Mobiludtræk og cloud-eksporter.

Analyse

En første analyse ser typisk på:

huller eller uregelmæssigheder i transaktionsnumre,
forskel mellem posteringsdato og registreringstidspunkt, fx bogføringer i en lukket periode,
rettelsesposteringer: hvem, hvornår og hvor længe efter den oprindelige postering,
bogføringer foretaget af brugere uden for den normale kreds, eller af en integration på usædvanlige tidspunkter,
ændringer af leverandørstamdata kort før betalinger.

Kombinér altid regnskabsdata med eksterne kilder. Bankens egne kontoudtog viser, hvad der faktisk blev betalt, uanset hvad der er bogført, og forskelle mellem bank og bogføring er ofte det første tegn på et problem. Den bredere metode til at koble bogføring med transaktionslogs i databaser er beskrevet i Databaser som bevis.

Leverandørens sikkerhedskopier kan i særlige tilfælde bruges til at vise, hvordan kladder eller stamdata så ud på en bestemt dag. Det kræver, at leverandøren vil og kan udlevere data fra en backup, og at det sker dokumenteret. Udbyderen skal efter kravbekendtgørelsen stille bogførte transaktioner og bilag til rådighed for myndigheder og for en kurator, likvidator eller rekonstruktør inden for fire uger, men udlevering af en tidligere tilstand fra backup til kunden afhænger af leverandørens vilkår og kan ikke forudsættes.

Brugere, roller og eksterne adgange

I mange mindre virksomheder har flere personer adgang til regnskabet: ejer, intern bogholder, ekstern bogholder, revisor og eventuelt en tidligere medarbejder, hvis adgang aldrig blev lukket. Cloudsystemerne understøtter typisk, at en revisor eller et bogholderfirma har adgang til mange kunders regnskaber fra én konto. Det betyder, at en postering kan være lavet fra en konto, der ikke tilhører virksomheden selv.

Sikr derfor en liste over alle brugere med rolle, oprettelsesdato, sidste login og eventuelle adgange via partnerkonti. Spørg leverandøren om historik for oprettelse og fjernelse af brugere, hvis den ikke er synlig i brugerfladen. Om loginhistorik med IP-adresse og tidspunkt kan ses i brugerfladen, varierer mellem programmerne. Er den ikke synlig, må den bestilles hos leverandøren, og opbevaringen kan være begrænset.

Godkendte integrationer bør listes med navn, hvem der godkendte dem og hvornår. En integration, der kan bogføre, er reelt en bruger med egne rettigheder.

Dokumentation

Rapporten bør angive system, abonnementstype og version, hvilke eksporter der er lavet, af hvem, hvornår og med hvilke filtre, hashværdier af filerne og antallet af posteringer pr. periode, så en anden kan kontrollere fuldstændigheden. Afstemning mod saldobalancen for samme periode er en enkel og stærk kontrol af, at eksporten er komplet.

Fejlkilder

Delte logins: Bruger en bogholder og en direktør samme konto, viser initialerne kontoen, ikke personen.
Tekniske brugere: En bankintegration kan bogføre hundredvis af posteringer under én bruger. Det er automatik, ikke en persons handling.
Tidszoner og datoformater: Registreringstidspunkter kan være i UTC i API’et og i lokal tid i brugerfladen.
Skift af system: Ved migrering bliver historik ofte importeret som åbningsposteringer eller samlede saldi, og ændringslogs fra det gamle system følger ikke med. Det gamle system bør sikres, før abonnementet opsiges; se Skift af bogføringssystem.
Afgrænsning: Et kontoudtog over en periode kan mangle posteringer bogført senere med dato i perioden.

Hvad sporene kan og ikke kan bevise

Ændringssporet i et registreret system kan vise, at en postering er bogført af en bestemt brugerkonto på et bestemt tidspunkt og senere rettet. Det kan ikke vise, om posteringen var korrekt, eller hvem der sad bag kontoen. Det, der skete i kladder og bilagsindbakker før bogføring, er ofte kun delvist dokumenteret. Rapporten bør derfor tydeligt adskille det, systemet garanterer, fra det, der er udledt af andre kilder som mail, bankdata og loginhistorik.

Kilder og versioner

Gennemgangen bygger på BEK nr. 97/2023 som ændret ved BEK nr. 811/2026. Flere krav har senere ikrafttræden; tjek den gældende version før brug.

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Cloud- og SaaS-forensik

Læs også: Hostingleverandørens logs: hvad kan leveres, og hvor hurtigt forsvinder det · MitID og NemLog-in: hvilke logdata findes, og hvem har dem

→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-revision · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik