ERP‑systemers audit trail teknisk

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

Et ERP-systems audit trail består sjældent af én log. Det er et samspil mellem ændringslogtabeller, posteringernes egne tidsstempler, nummerserier, brugeropsætning og databasens egne mekanismer. Kassesystemer har en tilsvarende journal; se Kassesystemer og POS. Hvert lag besvarer forskellige spørgsmål, og hvert lag har sine huller. Den tekniske opgave er at sikre alle lagene samlet, forstå hvordan det konkrete system skriver til dem, og derefter rekonstruere, hvordan data så ud på et bestemt tidspunkt, og hvem der ændrede dem.

Hvilke tvister ERP-data typisk indgår i, og hvad advokaten bør bede om ved edition, er beskrevet i ERP-systemets ændringslog som bevis. Den grundlæggende sikring af regnskabsdata er beskrevet i Bevissikring af regnskabssystemer. Her går vi i dybden med teknikken.

Lagene i et ERP-audit trail

Ændringslog · Felt, gammel og ny værdi, bruger og tidspunkt for ændringer i stamdata og dokumenter
Posteringernes egne felter · Posteringsdato, bilagsdato, oprettet af, oprettet tidspunkt, løbenummer
Nummerserier · Hvilke numre der er udstedt, og om der er huller
Bruger- og rolleopsætning · Hvem der kunne hvad, og hvornår rettigheder blev ændret
Periodelåse og bogføringsopsætning · Hvilke perioder der var åbne for bogføring
Sessions- og loginlog · Hvem var logget på, fra hvilken klient
Databasens egne mekanismer · Transaktionslog, temporale tabeller, triggere eller revision på databaseniveau

Ændringsloggens struktur

Ændringslogge er typisk bygget som en header med bruger, tidspunkt, transaktion eller program og hvilket objekt der blev ændret, og en eller flere linjer med felt, gammel værdi og ny værdi. I SAP kendes det som ændringsdokumenter, hvor header og linjer traditionelt ligger i tabellerne CDHDR og CDPOS. I Microsofts ERP-produkter hedder funktionen forskelligt: I Business Central er det ændringsloggen, og i Dynamics 365 Finance and Operations er det databaseloggen. Begge aktiveres pr. tabel og felt eller pr. tabel og hændelsestype. Andre systemer har deres egne løsninger, fra en fuld historiktabel til en simpel tekstlog.

Tre ting skal afklares for det konkrete system:

Hvilke tabeller og felter var omfattet i den relevante periode? Opsætningen af ændringsloggen er selv data, og ændringer i den bør være logget. Hent også den historik.
Hvad udløser en post? Ændringer i brugerfladen, ja. Men også ændringer via integrationer, importfunktioner, batchjob og API? Det varierer, også mellem moduler i samme system.
Hvordan registreres sletning? Nogle systemer logger hele den slettede post, andre kun at en post med et bestemt nøglefelt forsvandt.

Posteringsdato og registreringstidspunkt

Den mest almindelige fejlkilde i ERP-sager er forveksling af datoer. En postering har typisk flere:

Bilagsdato: datoen på det underliggende dokument, fx fakturadatoen.
Posteringsdato: den dato, posteringen henføres til i regnskabet. Den vælges af brugeren inden for åbne perioder.
Registreringstidspunkt: hvornår posten faktisk blev skrevet i databasen, ofte med klokkeslæt. Systemet sætter den selv.

En postering med posteringsdato i marts kan være registreret i juni, hvis perioden stod åben. Det er ikke i sig selv usædvanligt, men det er det, der skal undersøges, hvis spørgsmålet er, om noget blev tilbagedateret. Registreringstidspunktet og løbenummeret er de felter, der viser den faktiske rækkefølge. Find ud af, om registreringstidspunktet er serverens eller klientens tid, og i hvilken tidszone det står. Se Server-tid og klient-tid.

Nummerserier og løbenumre

Fakturaer, kreditnotaer og posteringer har typisk fortløbende numre. Et hul i en nummerserie kan være tegn på en slettet post, men det kan også skyldes, at et nummer blev reserveret og aldrig brugt, fx når en bruger afbryder en bogføring, eller når flere servere tildeler numre i blokke. Undersøg systemets måde at tildele numre på, før et hul tolkes.

Posteringsposter i finansmodulet har ofte et løbenummer, der er tildelt ved registreringen. Sammenholdt med registreringstidspunktet giver det en robust rækkefølge, der er svær at manipulere fra brugerfladen.

Brugere, roller og tekniske konti

En ændringslog viser en konto. Før kontoen kobles til en person, skal du vide:

om kontoen var personlig eller delt,
hvilke roller og rettigheder den havde på tidspunktet, ikke kun i dag,
om integrationer, batchjob eller importfunktioner skriver med kontoen,
om der er konti for leverandørens konsulenter, og hvornår de var aktive.

Rettighedsændringer er ofte selv logget. Hent historikken, så en ændring kan holdes op mod, hvad kontoen kunne på det givne tidspunkt.

Uden om applikationen

Ændringer direkte i databasen går uden om ERP-systemets ændringslog. Det kan være en konsulent, der retter data med et script, en migrering eller en opdatering fra leverandøren. Sådanne ændringer kan nogle gange findes i databasens egen transaktionslog, i temporale tabeller eller i revision på databaseniveau, hvis det var slået til. Se Databaser som bevis: transaktionslogs og audittabeller.

Sikring

Kopiér databasen eller de relevante tabeller konsistent, med dokumentation af metode og tidspunkt. Se Konsistent sikring af en database.
Eksportér ændringsloggen for perioden i rå form, ikke kun som rapport. For danske cloudregnskabsprogrammer, se ændringslog og eksport, og om forskellen på revisors udtræk og en forensisk kopi Fra revisionsbevis til forensisk bevis.
Gem opsætningen: logningskonfiguration, nummerserier, periodelåse, brugere og roller, integrationer og batchjob.
Notér version og tilpasninger. Tilpassede felter og egne udvidelser kan logge anderledes end standarden.
Beregn hashværdier for alle kopier og eksporter.

Ligger systemet hos en hostingpartner eller som SaaS, skal partneren lave kopien eller udtrækket. Bed om en beskrivelse af metoden og om eksport af rå tabeller frem for rapporter.

Rekonstruktion

Med ændringsloggen kan en posts tilstand på et tidligere tidspunkt rekonstrueres ved at gå baglæns fra den aktuelle værdi og tilbageføre hver ændring. Det kræver, at alle ændringer af de relevante felter er logget. Kontrollér rekonstruktionen mod dokumenter, der blev dannet på tidspunktet, fx en ordrebekræftelse eller en faktura i PDF, eller mod en ældre backup. Stemmer de, styrker det både rekonstruktionen og loggens fuldstændighed. Stemmer de ikke, er der ændringer, loggen ikke har fanget.

Typiske fejlkilder

Rapporter i stedet for rådata. En standardrapport over ændringer kan filtrere, gruppere eller afkorte værdier. Brug den som overblik, ikke som kilde.
Visning i brugerens tidszone. Brugerfladen kan vise registreringstidspunktet omregnet til den indloggede brugers tidszone, mens databasen gemmer UTC.
Tilbageførsler læst som sletninger. I et regnskab slettes bogførte posteringer normalt ikke; de modposteres. En tilbageførsel er et spor, ikke et hul.
Oprydningsjob. Mange systemer har job, der sletter ældre ændringslogposter for at spare plads. Find ud af, om de har kørt i perioden.
Test- og kopimiljøer. Data fra et testmiljø kan ligne produktionsdata. Notér altid, hvilket miljø og hvilket firma i systemet data stammer fra.

Hvad audit trailen kan og ikke kan bevise

Et komplet og korrekt sikret audit trail kan vise, hvilken konto der ændrede hvilket felt fra hvilken værdi til hvilken, og hvornår ændringen blev registreret. Det kan afsløre tilbagedaterede posteringer via forskellen mellem posteringsdato og registreringstidspunkt. Det kan ikke vise ændringer i felter, der ikke var logget, ændringer uden om applikationen, eller hvem der brugte en delt konto. Ved skift af system kan historikken være tabt; den praktiske side er beskrevet i Skift af bogføringssystem.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Cloud- og SaaS-forensik

Læs også: SaaS-systemer som datakilde: hvilke logs findes, og hvem har dem · Feltlog og ændringshistorik i CRM-systemer

→ 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