Forside › Analyse og fortolkning · Gennemgået oktober 2026 · Af John Nielsen
Journal entry testing bliver forensisk, når hele populationen af posteringer er hentet direkte fra kilden, når det er dokumenteret, at udtrækket er fuldstændigt, når filer og forespørgsler har hashværdier og versioner, og når hver posteringsudvælgelse kan gentages af en anden med samme resultat. Testen i sig selv er den samme som i revisionen: udvælgelse af posteringer med kendetegn, der kan pege på tilsidesættelse af kontroller. Forskellen ligger i dokumentationen og i, at hvert hit kan følges videre til bruger, tidspunkt og ændringslog.
Revisionsstandarden om besvigelser, ISA 240, kræver, at revisor tester posteringer og andre reguleringer for risikoen for, at ledelsen tilsidesætter kontroller. Den overordnede forskel på revisionsbevis og forensisk bevis er beskrevet i fra revisionsbevis til forensisk bevis. Ledelsens situation, når der er uregelmæssigheder, står på bevissikring-digitalt.dk.
Fra stikprøve til population
I revisionen kan en test være målrettet og afgrænset af væsentlighed. I en forensisk sammenhæng er udgangspunktet alle posteringer i den relevante periode og i de relevante selskaber, uden beløbsgrænse. Små beløb kan være netop dem, der er interessante, fx gentagne posteringer lige under en godkendelsesgrænse. Afgrænsningen sker bagefter med dokumenterede filtre, ikke i udtrækket.
Felterne, der skal med
Et udtræk, der kun indeholder konto, dato og beløb, er ikke nok. Mindst disse felter bør være med pr. posteringslinje:
- bilagsnummer og linjenummer,
- posteringsdato og bilagsdato,
- systemets registreringstidspunkt, dvs. hvornår posten faktisk blev oprettet,
- bruger, der oprettede posten, og eventuel godkender,
- kilde: manuel indtastning, automatisk postering, import eller integration,
- konto, dimensioner, beløb, valuta og valutakurs,
- posteringstekst,
- periode og om perioden var lukket.
Hvordan udtrækket laves fra ERP-systemet, så det holder, er beskrevet i ERP-udtræk til forensic accounting. Hvordan ændringsloggen læses, står i ERP-systemers audit trail teknisk.
Fuldstændighedskontrol
Før testen køres, skal det vises, at udtrækket er komplet. Typiske kontroller er:
- Debet lig kredit: summen af alle linjer pr. bilag og i alt går i nul.
- Afstemning til saldobalancen: primosaldo plus periodens bevægelser er lig ultimosaldo for hver konto, sammenholdt med en saldobalance hentet uafhængigt af udtrækket.
- Antal poster: antallet af bilag og linjer pr. periode sammenholdes med systemets egen opgørelse.
- Nummerserier: huller og dubletter i bilagsnumre identificeres og forklares.
- Periodegrænser: posteringer med posteringsdato uden for den forventede periode tælles og noteres.
Resultatet af hver kontrol gemmes med kontroltal, så en anden kan se, at udtrækket var afstemt, før analysen begyndte.
Udvælgelseskriterier
De fleste kriterier er velkendte fra revisionen. I forensisk kvalitet skal hvert kriterium beskrives præcist, med parameterværdier og antal hit:
- manuelle posteringer på konti, der normalt kun får automatiske posteringer,
- posteringer registreret efter periodeafslutning, men dateret i den lukkede periode,
- registrering uden for normal arbejdstid, i weekender og på helligdage,
- posteringer foretaget af brugere, der sjældent bogfører, af administratorer eller af tekniske konti,
- runde beløb og beløb lige under godkendelsesgrænser,
- tilbageførsler kort efter oprindelig postering,
- posteringstekster med bestemte ord eller uden tekst.
Statistiske metoder som Benfords lov kan bruges til at pege på områder, men et afvigende mønster er ikke et fund i sig selv. Gem også de kriterier, der blev forsøgt og forkastet, med begrundelse.
Tid er en egen fejlkilde
Posteringsdato er det, brugeren har angivet. Registreringstidspunktet er det, systemet har sat. Filtrerer man kun på posteringsdato, overser man tilbagedaterede posteringer, som netop er et af de mønstre, testen skal finde. Afklar desuden, hvilken tidszone registreringstidspunktet er gemt i, særligt i cloudbaserede systemer, og brug en dansk helligdagskalender for de relevante år, når der testes for registrering på fridage.
Fra hit til fund
Et hit er et spørgsmål, ikke et svar. Hvert hit, der indgår i en konklusion, skal følges videre til:
- bilaget og dets metadata,
- ændringsloggen for posten: blev den oprettet, ændret eller tilbageført, og af hvem,
- loginloggen for brugeren på tidspunktet,
- godkendelsesflowet og eventuel mail eller chat om posten.
For danske cloudregnskabsprogrammer er sporene beskrevet i ændringslog og eksport i regnskabsprogrammer.
Gentagelighed
Analysen skal kunne køres igen. Gem udtrækket med hashværdi, forespørgsler eller scripts med version, værktøjets navn og version, uddata med hashværdi og en log over kørslen. Lad gerne en anden person køre den samme analyse uafhængigt og sammenlign antal hit. Undgå at lave udvælgelsen manuelt i et regneark, hvor filtre og sorteringer ikke gemmes. Regneark konverterer desuden datoer og afrunder beløb, hvilket kan ændre resultatet uden varsel.
Brugere og roller som kontekst
Et kriterium som “posteringer foretaget af brugere, der sjældent bogfører” forudsætter, at det er kendt, hvem brugerne er. Sikr derfor brugerlisten med roller og rettigheder og ændringerne i dem over perioden, ikke kun den aktuelle opsætning. En bruger, der fik bogføringsrettigheder i tre dage og derefter mistede dem igen, er interessant i sig selv. Notér også, hvilke konti der er delte, tekniske eller tilknyttet eksterne, fx en revisor eller en bogføringsassistent hos et andet firma. Poster fra en delt konto kan ikke uden videre føres til en person, og det skal fremgå af resultatet. Kontoplanen med kontotyper og eventuelle spærrede konti hører med, fordi flere kriterier bygger på, hvilke konti der normalt kun får automatiske posteringer.
Sådan rapporteres testen
En rapport over en forensisk journal entry test bør gøre det muligt for en anden at gentage hvert trin. Den bør indeholde:
- kilden: system, version, selskaber, periode og hvem der lavede udtrækket hvordan,
- hashværdier for udtræk og uddata,
- resultatet af fuldstændighedskontrollerne med kontroltal,
- hvert kriterium med præcis definition, parameterværdier og antal hit,
- de forkastede kriterier og begrundelsen,
- for hvert hit, der indgår i en konklusion: det videre spor i bilag, ændringslog og loginlog,
- begrænsninger, fx delte konti, manglende ændringslog for en periode eller migrerede data.
Skriv resultatet som fakta først og vurdering bagefter. “Posten blev registreret den 3. januar af kontoen X og dateret 31. december” er et fund. “Posten blev tilbagedateret for at påvirke årsregnskabet” er en vurdering, der kræver mere end testen.
Typiske fejlkilder
- Integrationer, der ligner manuelle posteringer: en import fra et andet system kan stå med en almindelig brugerkonto.
- Migrerede data: posteringer flyttet fra et tidligere system har ofte migreringsbrugeren og migreringsdatoen som oprettelsesoplysninger.
- Tilbageførsler talt dobbelt: en postering og dens modpost kan begge ramme samme kriterium.
- Valuta: beløbsgrænser testet i transaktionsvaluta i stedet for regnskabsvaluta.
- Systembrugere: batchjob og periodeafslutningsrutiner skaber posteringer uden for arbejdstid.
Hvad testen kan og ikke kan vise
En forensisk journal entry test kan vise, hvilke posteringer der opfylder bestemte kriterier, hvem der registrerede dem, og hvornår. Kombineret med ændringslog og loginlog kan den vise, hvilken konto der foretog hvad. Den kan ikke vise hensigt eller viden. Det er en vurdering, der hører til andre dele af sagen.
Kilder og versioner
- IAASB: ISA 240 (Revised), The Auditor’s Responsibilities Relating to Fraud
- ISO/IEC 27042:2015: Guidelines for the analysis and interpretation of digital evidence
- ISO/IEC 27037:2012: Guidelines for identification, collection, acquisition and preservation of digital evidence
Senest gennemgået: oktober 2026.
Næste skridt
- Hvem sad ved tastaturet? Attribution af brugerhandlinger
- Systemet eller brugeren? Aktivitet, der ligner brugeradfærd
- Bias i forensisk analyse: bekræftelsesbias og kontekstinformation
Del af: Analyse og fortolkning
Læs også: Memory forensics: hvad en RAM-kopi kan vise · ERP-udtræk til forensic accounting · Teknisk ordbog
→ Digital forensics-undersøgelse · For IT-revision · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT