Anex - revisionsspor som kernefunktionalitet

Hvad er et revisionsspor?

Det er dybest set ‘Hvem gjorde hvad, hvornår?’ – bare for alle de data, der eksisterer i dit system. Det har en række konsekvenser; en af de vigtigste er at du er begrænset til append-only modeller. Lad mig give et eksempel, hvorfor det er vigtigt. Lad os sige, du bruger Anex til at lave en faktura til en kunde på 100.000 DKK. Der skal afregnes moms af de 100.000, der skal betales skat af det, der er tilbage, når du har betalt abonnementet til Anex, løn til dig selv osv. Lad os nu sige, kunden brokker sig og I når frem til, at de har ret – det skulle have været 120.000. Du sender en ny faktura. Men, vent. Du har jo sendt momsopgørelsen til Skat for den periode. Så der skal laves en efterangivelse.

Lad os sige, Anex kun havde seneste version af fakturaen? Og du bliver kaldt til Torskegilde (ja, ja – jeg er så gammel, at det var den talemåde vi brugte i forrige årtusind, fordi man på et tidspunkt fik torsk serveret, når man blev inviteret ind for at kigge på gennemslagspapir… Okay, det her stikker af ud af en tangent, jeg ikke havde planlagt: Tilbage på sporet!) hos de kære adminstratorer hos Skat. Held og lykke med at huske hvad der skete for to-et-halvt år siden, der gjorde at du skulle lave den efterangivelse.

Man plejer at sige at Al Capone aldrig blev fanget for al volden, sprutten osv., men at det var skattevæsenet, der fældede ham. Det samme med rockerne (Det er helt utrolig svært at forklare hvordan du har købt en Harley til en halv million, når du har været på kontanthjælp de seneste femten år – for ikke at tale om de tommetykke guldkæder, der omkranser din nakke).

Hvad er omfattet af revisionsspor?

Alle posteringer, der vedrører økonomiske bevægelser i din virksomhed skal du kunne redegøre, hvorfra kommer. Derfor skal du altid have et bilag på dine udlæg. Derfor må der ikke være huller i dine bilagsnumre (For hvad var der på dem, du gav nummer 6,7 og 69 – det her er den eneste form for humor du vil finde i denne blog). Det skal kunne spores begge veje, så når Skat finder den bilagsmappe med de dobbelt-sorte kvitteringer i (sorte kvitteringer er for sort arbejde, som Skat ikke ved noget om – dobbelt-sort er dem din partner heller ikke ved noget om), så skal du kunne redegøre for, hvor de er i dit regnskabssystem. Lige så når du har sendt 5.400 EUR til din makker i Lichtenstein.

Hvordan er det løst i Anex?

Der er en klump kode, der registrerer alle ændringer i data. Den ligger centralt lige før data bliver sendt til databasen og det sker generisk, så ændringer i adressen på en kunde kan spores tilbage til hvornår det skete. Teknisk set, så er der ikke myndighedskrav om den slags, men det viser sig, at for supporten til et regnskabssystem, er det helt utroligt nyttigt at kunne sige: “Det var Henning, 7. december 2025 kl. 23:43:32, hvor han også lavede en ekstra postering til hans egen konto på 54.000 med teksten ‘Skurpenge’. Sjovt sammenfald – var det ikke der, I havde julefrokost?”, når der er noget, der ser mærkeligt ud.

Derudover kan man ikke lave ændringer til posteringer på alt, der er under en transaktion. Dvs. finansposteringer, debitorposteringer, lagerbevægelser, fakturalinjer osv.

Hvordan ser data ud?

Her er et eksempel på en ændring af stamdata:

{
  "id": "a676a975-89ab-4b85-b114-b47c00fafdaa",
  "createdUtc": "2026-07-03T15:13:49.725Z",
  "eventType": {
    "code": "TRAILTYPE_UPDATED"
  },
  "entityType": "Partner",
  "entityId": 51,
  "childType": null,
  "childId": null,
  "correlationId": "361ea16d-5baf-4e4b-8c4e-50d9c50cacbb",
  "oldVersion": {
    "Address": {
      "addressLine1": "Mejlgade 51A",
      "addressLine2": "",
      "zipcode": "8000",
      "city": "Århus",
      "country": null
    },
    "Version": 4,
    "Updated": "2026-07-03T15:01:56.241Z"
  },
  "newVersion": {
    "Address": {
      "addressLine1": "Mejlgade 51",
      "addressLine2": "",
      "zipcode": "8000",
      "city": "Århus",
      "country": null
    },
    "Version": 5,
    "Updated": "2026-07-03T15:13:28.692Z"
  },
  "unchanged": {
    "Name": "LabelHub ApS",
    "OrgNumber": "12345678",
    "GLNNumber": "",
    "Company": {
      "_id": 1,
      "Type": "Company"
    },
    "Id": 51,
    "Created": "2026-07-03T14:52:58.901Z"
  }
}

Læg mærke til correlationId – det vil sige, at man kan søge på alt relateret, der skete da den her ændring skete. Derudover er der childType og childId – de bruges, når fx en ordre linje ændres, så vil det også fremgå som en ændringer på den tilhørende ordre.

Hahaha, jeg har adgang til databasen…

Det er fuldstændig korrekt – og derfor en ansvarlig virksomhed a) betaler deres sysadms ordentligt og b) får samme sysadms til at logge adgange og begrænse dem mest muligt.

Og koden!

Se, derfor er Anex open-source, så vi kan sammenligne den kode, der kører på din server, med den der ligger på Codeberg og se de ændringer, du måtte have lavet på din version.