ERP‑udtræk til forensic accounting

Forside › Analyse og fortolkning · Gennemgået oktober 2026 · Af John Nielsen

Et ERP-udtræk holder i en tvist, når det er hentet direkte fra produktionssystemet af en person uden interesse i sagen, når det dækker hele perioden og alle relevante tabeller inklusive stamdata og ændringslog, når kontroltal er afstemt mod systemets egne opgørelser, og når filer og fremgangsmåde er dokumenteret med hashværdier, så udtrækket kan gentages. Det er sjældent selve analysen, der bliver angrebet i en økonomisag. Det er grundlaget.

Udtrækket er udgangspunktet for analyser som journal entry testing i forensisk kvalitet. Hvordan systemets ændringslog er opbygget, er beskrevet i ERP-systemers audit trail teknisk. Hvem der bør undersøge hvad i en økonomisag, er beskrevet for ledelsen på bevissikring-digitalt.dk.

Rollerne

Forensic accountants og intern revision ved, hvilke spørgsmål data skal besvare: hvilke selskaber, perioder og processer, fx køb til betaling, salg, løn eller lager. Den tekniske side af udtrækket er en anden disciplin: hvilke tabeller der indeholder svaret, hvordan de hentes uden at ændre noget, og hvordan det dokumenteres. Systemejeren eller leverandøren giver adgang og forklarer datamodellen. Udtrækket bør ikke laves af medarbejdere, der kan være involveret i de forhold, der undersøges, og heller ikke af nogen, der rapporterer til dem.

Tre eksportveje

Rapporter fra brugerfladen. Hurtige og forståelige, men de er filtrerede, formaterede og ofte summerede. Felter som registreringstidspunkt og oprettende bruger mangler typisk, og det er uklart, hvilke kriterier rapporten bruger. Egner sig som sammenligning, ikke som grundlag.

Standardiseret eksport. Danske digitale bogføringssystemer skal kunne danne en SAF-T-fil, og på tidspunktet for gennemgangen (oktober 2026) skal registrerede standardsystemer understøtte SAF-T version 2.1 fra 1. januar 2027. Filen har en fast struktur, som gør den let at læse ind i analyseværktøjer. Den indeholder ikke nødvendigvis ændringslog, godkendelsesflow, ikke-bogførte kladder eller alle systemets tidsstempler, så kontrollér det konkrete systems fil, før den bruges som eneste kilde.

Direkte tabeludtræk eller databasekopi. Den mest komplette vej, fordi alle felter og alle tabeller er med. Den kræver kendskab til datamodellen og adgang til databasen eller en tilsvarende eksportfunktion hos leverandøren. Ved større sager er det ofte den rigtige vej. Fremgangsmåden er beskrevet i konsistent sikring af en database.

Hvad der skal med

Transaktionerne alene er ikke nok. Et udtræk til forensic accounting bør normalt omfatte:

finansposter, debitor- og kreditorposter, bankposter og eventuelt lagerposter,
ikke-bogførte kladder og deres historik,
stamdata med ændringshistorik, især kreditorer og deres bankkonti,
kontoplan, dimensioner og nummerserier,
brugere, roller og ændringer i rettigheder over perioden,
periodelukninger og bogføringsopsætning,
godkendelsesflow for fakturaer og betalinger,
ændringslog og integrationslog.

Ændringer i kreditorers bankkonti er et særligt vigtigt område, fordi de kan forklare betalinger, der er gået til en anden modtager end forventet.

Format

Én fil pr. tabel i et åbent tekstformat som CSV, med angivet tegnkodning, feltseparator og decimaltegn.
Datoer og tidspunkter i et entydigt format som ISO 8601, med tidszone.
Ingen omvej om regneark. Excel fjerner foranstillede nuller i kontonumre og CVR-numre, omformer datoer og afrunder lange tal.
Datakatalog: en beskrivelse af hver tabel og hvert felt med type og betydning, gerne fra leverandørens dokumentation.

Kontroltal

Ved udtrækket registreres for hver tabel antal rækker og relevante summer. Summerne afstemmes mod systemets egen saldobalance og eventuelt mod debitor- og kreditorsaldi på samme tidspunkt. Systemets egne totaler dokumenteres i form af en rapport, der gemmes som fil. Alle filer samles i et hashmanifest, så modtageren kan kontrollere, at intet er ændret.

Dokumentation af udtrækket

Dokumentationen skal gøre det muligt for en anden at gentage udtrækket:

system, version og miljø, og en bekræftelse af, at det var produktionsmiljøet,
tidspunkt, tidszone og den konto, der blev brugt,
forespørgsler eller eksportopsætning, ordret, inklusive filtre,
selskaber, perioder og tabeller,
kontroltal og afstemning,
hashværdier,
afvigelser, fejl og forhold, der ikke kunne udtrækkes.

Hvis der senere skal hentes supplerende data, laves et nyt udtræk med samme dokumentation, så de to kan holdes op mod hinanden.

Når leverandøren laver udtrækket

Ligger systemet som SaaS eller hos en hostingpartner, er det ofte leverandøren, der skal lave tabeludtrækket. Det er i orden, men stil de samme krav som til et internt udtræk. Bed om en skriftlig beskrivelse af metoden, de præcise tabeller og filtre, tidspunktet og den konto, der blev brugt. Bed om hashværdier ved udleveringen, og kontrollér dem ved modtagelsen. Lav selv kontroltallene mod systemets saldobalance, så afstemningen ikke alene hviler på leverandørens oplysninger. For de mindre cloudregnskabsprogrammer er eksportvejene og deres begrænsninger beskrevet i ændringslog og eksport i regnskabsprogrammer.

Spørg også, om leverandøren har data, kunden ikke selv kan se i brugerfladen, fx tekniske logs over integrationer, API-kald og administrative handlinger foretaget af leverandørens egne medarbejdere. De kan være afgørende, hvis det bliver et spørgsmål, om en ændring kom fra en bruger eller fra en integration.

Persondata i udtrækket

Et fuldt ERP-udtræk indeholder persondata: medarbejdere, kunder, kreditorer, der er enkeltmandsvirksomheder, og ofte løndata. Det er ikke et argument for at filtrere i selve udtrækket, fordi det svækker fuldstændigheden. Det er et argument for at begrænse, hvem der får adgang til hvilke tabeller i analysefasen, og for at notere det. Løntabeller udleveres kun, hvis spørgsmålene kræver det.

Udleveringen

Det originale udtræk bevares forseglet med hashværdi, og forensic accountants arbejder på kopier. Rensning, mapning af konti og sammenkædning af tabeller gøres med scripts eller dokumenterede trin, så det er sporbart, hvordan analysegrundlaget er dannet fra udtrækket. Spørgsmål om datamodellen samles og besvares skriftligt, fordi svarene ofte bliver en del af forklaringen på analysen.

Fejlkilder

Testmiljø eller kopi: et udtræk fra et test- eller rapporteringsmiljø kan være forældet eller ufuldstændigt.
Arkiverede år: ældre data kan være flyttet ud af produktionsdatabasen til et arkiv.
Koncerner: interne posteringer og elimineringer giver dobbelttælling, hvis selskaberne ikke holdes adskilt.
Valuta: beløb i transaktionsvaluta og regnskabsvaluta blandes sammen.
Slettede kladdelinjer: linjer, der blev slettet før bogføring, findes kun i en log, hvis de findes.
Afskæring: periodegrænser beregnet i UTC i stedet for dansk tid flytter posteringer omkring midnat.

Hvad udtrækket kan og ikke kan

Et korrekt dokumenteret udtræk kan bære en analyse, der kan efterprøves af en modpart eller en skønsmand, og det kan vise systemets tilstand på udtrækstidspunktet. Det kan ikke vise ændringer, som systemet ikke har logget, eller data, der blev slettet før udtrækket. Det skal fremgå af dokumentationen. Udtrækket kan heller ikke i sig selv vise, hvem der sad ved tastaturet. Det kræver, at brugerkonti, loginlogs og andre spor kobles på, og at det vurderes, om kontoen kunne være brugt af andre end den, den tilhører.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Analyse og fortolkning

Læs også: Journal entry testing i forensisk kvalitet · AI i egen analyse: dokumentation og efterprøvelighed · Teknisk ordbog

→ Digital forensics-undersøgelse · 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