Spring til indhold
Gathena
en

Lær · Guide

Fakturaer bag et login kan hentes automatisk

Nogle leverandører, for eksempel mange forsyningsselskaber, sender aldrig fakturaen. I stedet skal nogen logge ind, finde den, downloade den og lægge den det rigtige sted, ofte med en kode, der først kommer på mail. Guiden viser, hvordan det kan køre helt af sig selv i jeres egen Azure. Ved hvert trin kan I se, hvad der sker, hvorfor det er valgt, og hvordan det er sikret.

Tidspunkt
I bestemmer
Kører i
jeres egen Azure
AI undervejs
ingen

  1. Trin 1

    Undersøg først, om I kan undgå portalen

    Mange leverandører sender gerne fakturaen på mail, hvis I beder om det, og nogle portaler har en indstilling til det. Enkelte lande er nået længere. I Italien har momsregistrerede virksomheder siden 2019 skullet sende fakturaer elektronisk gennem landets fælles system, SdI. En virksomhed, der er registreret i Italien, kan derfor få alle sine fakturaer leveret ét sted uden at logge ind nogen steder.

    Hvorfor sådan

    Når fakturaen kommer af sig selv, er der intet login, ingen kode og intet script at vedligeholde.

    Sådan er det sikret

    Der ligger ingen adgangskode nogen steder, og der er intet, der kan gå i stykker, når portalen bliver ændret.

    og for de portaler, der er tilbage

  2. Trin 2

    Scriptet bygges én gang

    En builder agent, her Claude Code, åbner portalen med Playwright CLI og finder ud af, hvor der skal klikkes: login, listen over fakturaer og knappen, der downloader. Derefter skriver den et helt almindeligt Playwright-script. Playwright er et open source-værktøj fra Microsoft, som styrer en browser via kode. Scriptet gemmes i Git, og en deploy-pipeline pakker det sammen med en browser i et container-image.

    Hvorfor sådan

    AI bruges kun, mens scriptet bygges. Den faste kørsel er bare scriptet, så den gør præcis det samme hver gang og bruger ingen AI-model.

    Sådan er det sikret

    Operatøren gennemgår og godkender hver ændring, før pipelinen sætter den i drift. Pipelinen logger ind i Azure med sin egen identitet, så der ligger hverken adgangskode eller nøgle i koden eller i pipelinen.

    Builder agent · Claude Code

    udforsker med Playwright CLI

    gemmer i Git

    Git-repository

    kun godkendte ændringer

    efter godkendelse

    Deploy-pipeline

    bygger container-imaget

    sender

    Container Registry

    opbevarer imaget

    sendes til Azure

  3. Trin 3

    Kørslen på faste tidspunkter

    Azure Container Apps Jobs starter containeren på de tidspunkter, I har valgt, for eksempel én gang om måneden, når fakturaen plejer at være klar. Containeren åbner en såkaldt headless browser, altså en browser uden skærm, kører scriptet og lukker ned, når det er færdigt.

    Hvorfor sådan

    Container Apps Jobs er beregnet til netop den slags kørsler, der starter, gør deres arbejde og stopper igen. I betaler kun, mens den kører, og der er ingen server at holde ved lige imellem. Microsofts eget Playwright-image har allerede browseren og alt, hvad den skal bruge.

    Sådan er det sikret

    Kørslen har sin egen managed identity, altså et login til Azure, der hører til containeren. Det giver kun adgang til kørslens egne hemmeligheder og dens eget lager. Browseren kører som en almindelig bruger uden administratorrettigheder, sådan som Playwright anbefaler, når man besøger sider, man ikke selv har kontrol over.

    Tidsplan · cron

    tidspunkter, I vælger

    starter

    Container Apps Jobs

    • kører én gang og stopper
    • Playwright-scriptet
    • en headless browser
    • egen bruger, ikke admin

    logger ind og gemmer

  4. Trin 4

    Login-oplysningerne: hvordan de oprettes, gemmes og bruges

    Login-oplysningerne er brugernavn og adgangskode til portalen og, hvis I bruger scenarie A nedenfor, også nøglen til authenticator-appen. Kan portalen have flere brugere, får kørslen sin egen. Den, der kender login, taster selv oplysningerne direkte ind i Key Vault, som er Azures sikre lager til hemmeligheder. Herefter er det kun kørslen, der kan læse dem, og kun mens den kører.

    Hvorfor sådan

    Adgangskoden kommer aldrig forbi en chat, en mail, koden eller builder agenten. Den skal beskyttes ét sted og ændres ét sted.

    Sådan er det sikret

    Key Vault krypterer hemmelighederne og gemmer alle tidligere versioner. Kun kørslens managed identity har lov til at læse dem, og kun netop de hemmeligheder. De personer, der skal kunne lægge dem ind eller ændre dem, får en rolle til det. Slår I logning til i Key Vault, bliver hver eneste læsning og ændring registreret. Kørslen holder kun værdierne i hukommelsen, og optagelsen af kørslen starter først efter login, så hverken adgangskode eller kode ender i det, den gemmer.

    1. 1 · Opret

      Et login til kørslen

      • sin egen bruger i portalen, hvis portalen tillader det
      • så den kan lukkes uden at røre andres adgang

    2. 2 · Gem

      Tastes direkte ind i Key Vault

      • af den, der kender login
      • aldrig via chat, mail, kode eller builder agenten
      • én hemmelighed for hver: brugernavn, adgangskode, nøgle

    3. 3 · Brug

      Læses af kørslen, mens den kører

      • logger ind i Azure med sin egen identitet uden gemte nøgler
      • må kun læse netop disse hemmeligheder
      • holdes i hukommelsen; optagelsen starter efter login

    4. 4 · Skift

      Ændres ét sted

      • en ny adgangskode bliver en ny version i Key Vault
      • næste kørsel bruger den uden ny udrulning
      • hver læsning og ændring bliver logget

    bruges ved login

  5. Trin 5

    Koden ved login: to måder

    De fleste portaler beder om en kort kode efter adgangskoden. Hvordan kørslen får fat i koden, afhænger af, hvad portalen tilbyder. Scenarie A, en authenticator-app, er den måde, vi anbefaler. Scenarie B, en kode på mail, kan bruges, når portalen ikke tilbyder andet.

    Hvorfor sådan

    I scenarie A regner kørslen selv koden ud fra nøglen og klokken, præcis som appen på en telefon gør, så den behøver ikke adgang til noget andet. I scenarie B skal kørslen kunne læse en postkasse og vente på, at mailen kommer.

    Sådan er det sikret

    Mangler koden, eller er den forkert, stopper kørslen i begge tilfælde og giver operatøren besked. Den prøver kun én gang, så kontoen bliver aldrig spærret. Koder, der kommer som sms, kan en kørsel ikke læse. Ved de portaler kan I bede leverandøren om en authenticator-app eller blive ved med at hente fakturaen manuelt.

    • A · Authenticator-app

      anbefalet

      Sættes op én gang

      1. Vælg authenticator-app i portalens sikkerhedsindstillinger.
      2. Portalen viser en QR-kode og en nøgle.
      3. Nøglen gemmes i Key Vault. Den kan også lægges i en medarbejders egen app, så et menneske stadig kan logge ind.
      4. Bekræft med én kode.

      Ved hver kørsel

      1. Kørslen henter nøglen i Key Vault.
      2. Den regner den aktuelle kode ud fra nøglen og klokken. Koden skifter hvert 30. sekund.
      3. Den taster koden. Der er ingen postkasse og ingen ventetid.

      Vær opmærksom på

      Nøglen er lige så værdifuld som selve telefonen, for med den og adgangskoden kan hvem som helst logge ind. Derfor ligger den i Key Vault sammen med adgangskoden og ingen andre steder.

    • B · Kode på mail

      hvis der ikke er andre muligheder

      Sættes op én gang

      1. Giv portalbrugeren en mailadresse, der kun bruges til koderne.
      2. Giv kørslen adgang til at læse netop den postkasse. Microsoft 365 kan begrænse en app til bestemte postkasser, så den ikke kan læse anden mail.
      3. Skriv ned, hvilken afsenderadresse leverandørens koder kommer fra.

      Ved hver kørsel

      1. Kørslen logger ind med adgangskoden, og portalen sender en kode.
      2. Kørslen venter på en ny mail fra den afsender, som er kommet efter login.
      3. Den læser koden, taster den og markerer mailen som klaret.
      4. Kommer der ingen mail inden for få minutter, stopper kørslen og giver operatøren besked.

      Vær opmærksom på

      Kørslen kan læse en postkasse. Brug derfor kun den postkasse til koder, og lad kørslens adgang gælde den alene.

    logget ind

  6. Trin 6

    Gemt og overvåget

    Fakturaen gemmes i Blob Storage med leverandørens navn og måneden i filnavnet. Hver kørsel skriver sin log til Azure Monitor.

    Hvorfor sådan

    Blob Storage samler alle fakturaer ét sted, som bogføringen kan henvise til.

    Sådan er det sikret

    Ser en side anderledes ud, end scriptet forventer, stopper kørslen i stedet for at gætte. Den gemmer et skærmbillede og en optagelse af hvert trin efter login, og Azure Monitor giver operatøren besked.

    • Blob Storage

      gemmer · fakturaer og fejlrapporter

    • Azure Monitor

      log · besked ved fejl

    og uden for Azure

  7. Trin 7

    Tre systemer uden for Azure

    Kørslen er i kontakt med tre systemer uden for Azure. Den logger ind på leverandørens portal og downloader fakturaen. Den læser kun i postkassen, hvis portalen sender koden på mail. Og den lægger fakturaen som kladde i økonomisystemet via systemets API, for eksempel i e-conomic.

    Hvorfor sådan

    Så ligger fakturaen allerede dér, hvor bogholderen arbejder, og ingen skal hente den eller vedhæfte den.

    Sådan er det sikret

    Økonomisystemet er det eneste sted, kørslen skriver noget, og den skriver kun kladder. Den kan aldrig bogføre, og den betaler aldrig. Læs leverandørens vilkår, før I automatiserer deres portal, for nogle tillader ikke, at man logger ind automatisk.

    • Leverandørens portal

      login og download

    • Postkasse

      kun hvis koden kommer på mail

    • Økonomi · e-conomic

      kladde med fakturaen

      ← lægger en kladde

    og derfra til mennesker

  8. Trin 8

    Hvem gør hvad

    Operatøren godkender ændringer i scriptet og retter det, når der kommer en alarm. Bogholderen gennemgår kladden og bogfører den i det økonomisystem, I allerede bruger. Regningen betales i banken af den, der plejer at betale.

    Hvorfor sådan

    At hente og arkivere er rutine. At bogføre og betale kræver, at et menneske tager stilling, og derfor bliver det hos jer.

    Sådan er det sikret

    Den eneste orange linje på kortet er der, hvor kørslen skriver i et forretningssystem, og for enden af den står et menneske. Kortet for hver rolle viser, hvad rollen kan se og gøre, og hvor grænsen går.

    • Operatør

      Via
      Git og builder agenten (Claude Code)
      Ser
      scriptet, tidligere kørsler og alarmer
      Kan
      godkende ændringerrette scriptet
      Grænser
      intet ændres, før det er godkendt

    • Den faste kørsel · egen identitet

      Via
      Azure Container Apps Jobs
      Ser
      sine egne hemmeligheder, sit eget lager og portalen
      Kan
      downloadegemmelægge kladder
      Grænser
      kun kladder; bogfører og betaler aldrig; stopper ved alt uventet
      → lægger kladder iØkonomi · e-conomic · kladde med fakturaen

    • Bogholder

      Via
      økonomisystemet (e-conomic)
      Ser
      kladden med fakturaen vedhæftet
      Kan
      gennemgå og bogføre
      Grænser
      arbejder uden for kørslen

    • Den, der betaler

      Via
      banken
      Ser
      den bogførte faktura
      Kan
      betale
      Grænser
      arbejder uden for kørslen

Kilder

Guiden er skrevet den 29. oktober 2026 ud fra dokumentationen fra Microsoft, Playwright og de øvrige kilder, som den så ud den dag.

Produkterne er nævnt som eksempler på den slags systemer.

Har I fakturaer, der kun ligger bag et login, kan vi sammen se på, hvilke der kan hentes på denne måde, gerne med jeres IT, internt eller hos jeres IT-partner.

Book en samtale