ERP‑systemets ændringslog som bevis

Et ERP-system samler en virksomheds ordrer, priser, lager, indkøb, produktion og fakturering. Når en tvist handler om, hvad der blev bestilt, til hvilken pris, eller hvornår en vare forlod lageret, ligger svaret ofte i ERP-systemet. Endnu oftere handler striden om, hvorvidt tallene er blevet ændret, og af hvem. Her bliver systemets ændringslog central.

Denne artikel handler om ERP-systemets logning af ændringer i forretningsdata. De særlige krav til bogføringssystemer er behandlet i Digitale bogføringssystemer: hvad systemet skal kunne vise.

Typiske tvister

ERP-data indgår blandt andet i:

tvister om prisaftaler, rabatter og fakturerede beløb,
earn-out og kursreguleringer efter en virksomhedsoverdragelse,
lagerdifferencer og svind,
sager om en medarbejder, der har ændret ordrer, kreditnotaer eller kundestamdata,
tvister med leverandøren af selve ERP-systemet om fejl og datakvalitet. → Mangler ved IT-leverancer: dokumentation i retssagen

Hvad en ændringslog er

En ændringslog registrerer, at et felt i en post er ændret. En god registrering indeholder:

hvilken tabel og post der er ændret, fx en bestemt ordre eller vare,
hvilket felt der er ændret, fx pris eller antal,
den gamle og den nye værdi,
hvilken bruger der stod for ændringen,
tidspunktet,
ofte også hvilken funktion eller hvilket program ændringen kom fra.

Med sådan en registrering kan man rekonstruere, hvordan en ordre så ud på et bestemt tidspunkt, og hvem der ændrede den.

Huller, der går igen

Ændringsloggen er sjældent så komplet, som den ser ud. De hyppigste huller er:

Logningen er slået til felt for felt

I mange ERP-systemer skal logning aktiveres for den enkelte tabel eller det enkelte felt. Logning koster lagerplads og ydelse, så den er ofte kun slået til for udvalgte data. Et felt uden logning kan ændres uden spor.

Logningen kan være slået fra eller ændret

En administrator kan typisk ændre, hvad der logges. Det bør selv efterlade et spor, men gør det ikke altid. Spørg derfor, hvordan opsætningen var i hele perioden, ikke kun i dag.

Systembrugere og integrationer

Mange ændringer sker ikke via en person i brugerfladen, men via en integration: en webshop, et EDI-flow, et lagerstyringssystem eller et importværktøj. I loggen står der så en teknisk bruger, fx “INTEGRATION” eller “SYSTEM”. Hvem der reelt stod bag, skal findes i det system, der sendte data. → Sådan læser du en logfil

Masseopdateringer og direkte databaseændringer

Prislister indlæses ofte i store mængder ad gangen. Ændringer direkte i databasen, uden om ERP-systemet, efterlader normalt ingen spor i ændringsloggen.

Arkivering og migrering

Ved skift til en ny version eller et nyt system følger ændringsloggen ikke altid med. Gammel historik kan ligge i et arkiv eller være væk.

Hvad data ikke viser

Hvem der sad ved tastaturet. Brugernavnet viser kontoen. Delte konti og overdragne adgangskoder forekommer i mange virksomheder.
Hvorfor ændringen blev lavet. En prisændring kan være en rettelse af en fejl, en aftalt rabat eller et forsøg på at skjule noget.
Om den oprindelige værdi var rigtig. Loggen viser forløbet, ikke hvad der var aftalt.
Hvad kunden så. En ordrebekræftelse eller faktura kan være dannet og sendt, før en ændring blev lavet. Sammenhold derfor loggen med de dokumenter, der faktisk blev sendt ud.

Hvad advokaten bør bede om ved edition

Et udtræk af ændringsloggen alene er sjældent nok. Bed om:

Ændringsloggen for de relevante tabeller og perioder, med gammel og ny værdi, bruger og tidspunkt.
Oversigt over, hvilke tabeller og felter der var logning på, og om opsætningen er ændret i perioden.
Brugerliste med roller og rettigheder, herunder tekniske brugere og integrationer.
Oplysning om integrationer, der kan skrive i de relevante data.
Oplysning om migreringer, arkivering og sletning i perioden.
Beskrivelse af, hvordan udtrækket er lavet, og af hvem.

Formuler begæringen med systemets egne betegnelser, når de kendes. Klientens egne medarbejdere eller en tidligere ansat hos modparten kan ofte oplyse, hvilket system og hvilke moduler der bruges. → Editionsbegæring set fra IT-siden

Når klienten selv ejer systemet

Er det klientens eget ERP-system, er fristelsen stor til at lade en medarbejder trække en rapport og sende den til advokaten. Det er hurtigt, men det giver modparten mulighed for at spørge, hvem der har valgt data ud, og om rapporten er komplet.

En bedre fremgangsmåde er at sikre data, før nogen begynder at analysere:

Tag en kopi af databasen eller af de relevante tabeller, med dokumentation af tidspunkt og metode.
Gem en beskrivelse af logningens opsætning, som den er nu.
Notér, hvem der har administratorrettigheder, og om nogen af dem er part i sagen.
Sørg for, at automatisk arkivering eller sletning ikke fjerner historik under sagen.

Lav derefter analyserne på kopien. Så kan resultatet altid føres tilbage til de sikrede data, og en skønsmand kan gentage analysen. Har en af de involverede medarbejdere administratoradgang, bør vedkommende ikke stå for udtrækket.

Store datamængder

En ændringslog i et ERP-system kan indeholde millioner af linjer. Gennemgang kræver filtrering og analyse, og ofte er det nødvendigt at aftale en afgrænsning med modparten, fx bestemte kunder, varenumre eller perioder. Hvor det ikke er muligt at gennemgå alt, kan stikprøver være en løsning. → Stikprøver i store datamængder

Når en skønsmand skal undersøge systemet

Et skønstema om ERP-data bør være konkret: hvilke poster, hvilke felter, hvilken periode, og hvilket spørgsmål. Et spørgsmål som “er der manipuleret med data?” er for bredt. Et bedre spørgsmål er, om prisen på bestemte ordrer er ændret efter fakturering, af hvilken bruger, og om ændringen er sket via brugerfladen eller en integration.

Skønsmanden har typisk brug for adgang til systemet eller en kopi af databasen, ikke kun et udtræk. Det kræver praktiske aftaler om adgang, læserettigheder og fortrolighed. → Skønsmandens adgang til systemer og data