DigitalForensics

70 13 63 23

Journal entry testing i forensisk kvalitet

Journal entry testing i forensisk kvalitet

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:

  1. Debet lig kredit: summen af alle linjer pr. bilag og i alt går i nul.
  2. Afstemning til saldobalancen: primosaldo plus periodens bevægelser er lig ultimosaldo for hver konto, sammenholdt med en saldobalance hentet uafhængigt af udtrækket.
  3. Antal poster: antallet af bilag og linjer pr. periode sammenholdes med systemets egen opgørelse.
  4. Nummerserier: huller og dubletter i bilagsnumre identificeres og forklares.
  5. 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

Senest gennemgået: oktober 2026.

Næste skridt

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

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

John Nielsen, IT-sagkyndig

Brug for en forensisk undersøgelse?

Skriv kort, hvilke systemer eller enheder det drejer sig om, og om noget haster, så vender jeg tilbage. Kun civile sager.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.