Af Greg Nowak. Senest opdateret 2026-09-22.
En leverandørkontrakt kan sagtens være arkiveret korrekt og alligevel blive dyr at overse. PDF’en ligger måske i Dropbox, en mailmappe eller på et delt drev. Men datoen for opsigelse, genforhandling eller prisregulering står kun inde i dokumentet. Hvis fristen ikke også findes i den rigtige kalender med en navngiven ansvarlig, hviler processen på hukommelse og manuelle rutiner.
Kunne jeres virksomhed bruge det her? nowa.dk sætter AI-automatisering op for danske virksomheder.
Dokument-AI kan bygge bro mellem kontraktmappen og den daglige drift. Når et dokument bliver tilføjet eller ændret, læser systemet det, foreslår de relevante kontraktoplysninger og sender resultatet til kontrol. Først efter godkendelsen bliver påmindelserne oprettet. AI’ens svar skal altså behandles som et kvalificeret forslag med dokumentation, ikke som en endelig juridisk fortolkning.
Fra PDF til en frist, nogen kan handle på
Et brugbart kontraktflow kræver et fast skema. For hver aftale kan det eksempelvis rumme leverandør, startdato, udløbsdato, opsigelsesvarsel, prisregulering, intern ansvarlig og signaturstatus. Googles Custom Extractor nævner kontrakter som en relevant dokumenttype og kan tilpasses de felter, virksomheden faktisk bruger.
Tekstudtræk alene løser dog ikke opgaven. En formulering som “tre måneders skriftligt varsel før periodens udløb” skal omsættes til en dato og en konkret handling. Gem derfor både den beregnede dato og det tekstudsnit, den bygger på. Så kan den ansvarlige kontrollere ordlyd, dato og dokumentversion i samme arbejdsgang.
| Trin | Systemets opgave | Det, et menneske kontrollerer | Resultat |
|---|---|---|---|
| 1. Filændring | Registrerer en ny eller ændret kontrakt | Normalt ingen kontrol | Dokumentet sendes til analyse |
| 2. Feltudtræk | Finder leverandør, løbetid, varsel, prisregulering og signaturstatus | Manglende og usikre felter | Et struktureret kontraktkort |
| 3. Fristberegning | Foreslår en handlingsdato ud fra udløb og varsel | Datoen holdes op mod kildeudsnittet | En godkendt frist |
| 4. Kalender | Opretter eller opdaterer en påmindelse | Ansvarlig og tidspunkt for varsling | En synlig opgave i arbejdskalenderen |
| 5. Ny version | Analyserer dokumentet igen | Ændrede nøglefelter | Opdateret kontraktkort og kalender |
Kontrollen skal følge risikoen
Custom Extractor returnerer en konfidensværdi mellem nul og én for hver fundet entitet. Den viser, hvor sikkert modellen forbinder en foreslået værdi med det pågældende felt. Det giver mulighed for forskellige tærskler. Et tydeligt leverandørnavn kan måske gå direkte videre. En opsigelsesfrist med lavere konfidens bør altid lande hos en medarbejder.
Konsekvensen af en fejl bør også tælle med. En forkert intern kategori har sjældent samme betydning som en forkert opsigelsesdato. Derfor giver én fælles grænse for alle felter ikke meget mening. Kritiske datoer bør sendes til godkendelse sammen med det relevante tekstudsnit. Systemet kan samtidig markere, hvis udløbsdato, løbetid og varsel ikke hænger sammen.
Nyere funktioner kan udlede oplysninger fra dokumentets sammenhæng og registrere, om en signatur er til stede. Googles dokumentation om udledte felter og signaturregistrering beskriver funktionerne som preview. En registreret signatur betyder kun, at modellen har fundet visuelle tegn på en signatur. Den fastslår hverken aftalens gyldighed eller underskriverens fuldmagt.
Den svære del kan stå på en anden side
Kontrakter rammer en væsentlig teknisk begrænsning: Udledte felter genereres side for side. Oplysninger, der kræver en samlet fortolkning på tværs af flere sider, er derfor ikke fuldt understøttet. Udløbsdatoen kan stå ét sted, opsigelsesvarslet et andet og en undtagelse i et bilag.
Det gør skellet mellem direkte tekstfund og beregnede konklusioner vigtigt. Datoer og formuleringer bør så vidt muligt hentes som konkrete tekstudsnit med sidehenvisning. Derefter kan en fast regel beregne handlingsdatoen og vise den sammen med kildefelterne. Ligger oplysningerne på forskellige sider, eller finder systemet en undtagelsesklausul, bør kontrakten sendes til manuel kontrol.
Dropbox giver startsignalet
Ligger kontrakterne i Dropbox, kan en webhook sætte processen i gang, når en bruger tilføjer, ændrer eller sletter en fil. Dropbox’ webhook-dokumentation fremhæver en væsentlig detalje: Notifikationen indeholder ikke selve filændringen. Den angiver, hvilke konti der har ændringer. Integrationen skal derefter hente ændringerne og holde styr på, hvor langt den er nået.
Det påvirker den praktiske opbygning. Webhooken skal modtages hurtigt, mens hentning og analyse af dokumentet foregår bagefter. Flere notifikationer kan komme næsten samtidig. Flowet skal derfor kunne genkende gentagelser, så samme kontrakt ikke udløser flere identiske kontroller eller kalenderaftaler. Dropbox sender desuden en signatur med webhook-anmodningen, som integrationen kan validere, før behandlingen begynder.
Godkend fristen, før kalenderen ændres
Når kontraktkortet er godkendt, kan integrationen oprette kalenderhændelsen. I Microsoft 365 understøtter Microsoft Graphs event-ressource blandt andet emne, beskrivelse, starttidspunkt, påmindelse og følsomhed. En klientdefineret transaktionsidentifikator kan hjælpe serveren med at undgå en ekstra hændelse, hvis et oprettelseskald gentages efter eksempelvis en timeout. Hændelser kan opdateres, og Graph understøtter både ændringsnotifikationer og løbende registrering af tilføjelser, ændringer og sletninger.
Bruger virksomheden Google Workspace, kan Google Calendar API udfylde samme rolle. En begivenhed oprettes i en valgt kalender med obligatorisk start- og sluttid. Beskrivelse, deltagere og påmindelser kan tilføjes. Et selvvalgt event-id kan forbinde kontraktposten med kalenderhændelsen og mindske risikoen for dubletter, hvis oprettelsen må forsøges igen.
Selve kalenderteksten skal kunne bruges af den kollega, der modtager den. Den bør fortælle, hvilken kontrakt det gælder, hvilken beslutning der skal træffes, hvem der ejer opgaven, og hvor den godkendte dokumentversion ligger. Påmindelserne skal også passe til den reelle beslutningstid. En frist tre måneder før udløb hjælper kun, hvis den interne vurdering begynder tidligt nok til at indhente priser, forhandle og få et alternativ godkendt.
Få de praktiske beslutninger på plads først
Inden arbejdet begynder, skal virksomheden vælge den autoritative kontraktmappe, definere de nødvendige felter og placere ansvaret for hver leverandøraftale. Det skal også være klart, hvilke felter der altid kræver godkendelse, hvordan en ny dokumentversion genkendes, og om en ændring skal opdatere den eksisterende kalenderhændelse eller udløse en ny kontrol.
Start med én kontrakttype og et overskueligt antal aktive aftaler. Så kan I sammenligne forslagene med de faktiske dokumenter, justere konfidensgrænserne og finde de formuleringer, der kræver særlige regler. Når det fungerer stabilt, kan flowet udvides til flere mapper, leverandørtyper og ansvarlige teams.
Greg kan gennem nowa.dk, en AI-automationsservice for danske virksomheder, designe flowet omkring jeres nuværende kontraktmappe og kalender. Det kan omfatte overvågning af dokumentændringer, udtræk af de aftalte felter, visning af kildeudsnit til godkendelse og efterfølgende oprettelse eller opdatering af påmindelser i Microsoft 365 eller Google Calendar.
Resultatet er en arbejdsgang, hvor hver vigtig frist kan spores tilbage til kontrakten. Den har et kildeudsnit, en godkendelse, en ansvarlig og en entydig kalenderpost. Det gør det langt lettere at håndtere kontrakter som en løbende driftsopgave, før en overset dato begrænser virksomhedens muligheder.
Relateret på GrN.dk
- Montørens talenote skal blive til en arbejdsordre – ikke rå lyd
- Kundeindbakken må sortere sig selv – men ikke kommandere din AI
- Samme kunde, tre kundekort: AI-oprydning med styr på historikken
Brug for hjælp til den slags opgaver?
Få afklaret jeres kontraktflow Kontakt Greg her.
