Spring til indhold
Gathena
en

Lær · Guide · DuffBeautys platform

Sådan er bogholderiagenten bygget, trin for trin

Siden følger data fra kildesystemerne til bogholderen. Ved hvert trin viser den, hvad der kører, hvorfor vi valgte det, og hvad der holder det sikkert.

← Casen: en bogholderiagent på Google Cloud

Kører
hver nat
Seneste kørsel
ca. 10 minutter
Pris pr. kørsel
ca. 0,11 USD

Målt den 28. oktober 2026 på én natlig kørsel; prisen er beregnet efter Google Clouds listepriser.

  1. Trin 1

    Kilderne

    Hver nat læser platformen lager- og ERP-systemet, webshoppene, økonomisystemet, kortbetalingerne, banken og dagens valutakurser. Forbindelsen til betal-senere-løsningen er bygget, men er endnu ikke med i den natlige kørsel.

    Hvorfor sådan

    Til hvert system er der én fælles klient, som alle pipelines bruger. Så taler de med kilden på samme måde, og ændrer kilden sit API, skal det kun rettes ét sted.

    Sådan er det sikret

    Adgangen til kilderne er kun læseadgang, og koden håndhæver det: en pipeline kan aldrig skrive tilbage i kildesystemerne. Ændrer en kilde sig, giver pipelinen besked i stedet for at gætte.

    • Lager · Rackbeat

      lager, ordrer, fakturaer

    • Webshops · Shopify

      ordrer, udbetalinger

    • Økonomi · e-conomic

      finans, kladder, bilag

    • Kortbetaling · AltaPay

      kortafregninger

    • Bank

      kontoudtog via et drev

    • Valutakurser · ECB

      dagens kurser

    • Betal senere · Klarna

      bygget · endnu ikke natlig

    hentes hver nat

  2. Trin 2

    Den natlige kørsel

    En scheduler starter ét workflow hver nat. Små kørsler henter data fra hver kilde og indlæser dem. Derefter genopbygger transformationstrinnet tabellerne og kører sine kontroller. Den daglige mail sendes kun, når alle kontroller er bestået.

    Hvorfor sådan

    Det er så få tjenester som muligt til at køre en natlig pipeline pålideligt, og der er ingen orkestrator at holde i drift.

    Sådan er det sikret

    Ingen ser data, før kontrollerne er bestået. En fejlet kontrol stopper mailen, og hver kørsel efterlader en kvittering.

    Scheduler · Cloud Scheduler

    starter kørslen om natten

    starter

    Udtræk og indlæsning

    små kørsler · Cloud Run · rå filer gemt som dokumentation

    derefter

    Transformation · Dataform

    tabeller, views og kontroller

    kun hvis kontrollerne består

    Daglig mailkørsel

    læser ét klargjort view

    indlæses og kopieres

  3. Trin 3

    Hvor data ligger

    Hvert svar fra kilderne gemmes uændret i et fillager. I data warehouset ligger data i lag: raw som modtaget, staging renset og typet, intermediate med forretningsregler og afstemninger, og core og marts med de tabeller, økonomi rapporterer og bogfører fra. Et separat ops-område gemmer kørselskvitteringerne og auditloggen.

    Hvorfor sådan

    Hvert tal, økonomi bruger, kan spores gennem lagene tilbage til den rå fil, det kom fra.

    Sådan er det sikret

    De rå filer er dokumentationen. Bliver et tal sat i tvivl, ligger filen, det kom fra, der stadig. Det hele bliver i EU, i virksomhedens eget Google Cloud-projekt.

    Fillager · Cloud Storage

    hvert råt svar, gemt

    Data warehouse · BigQuery, EU

    raw

    som modtaget

    staging

    renset og typet

    intermediate

    regler, afstemninger, kontroller

    core · marts

    tabeller til rapportering og bogføring

    ops

    kørselskvitteringer · auditlog

    læses kun via de faste adgange

  4. Trin 4

    Adgang til data

    Ingen læser data warehouset direkte. Mennesker og agenter får adgang på én af tre måder: en dataforbindelse til spørgsmål, en kladdeforbindelse til bogholderiagenten og den daglige mail. Begge forbindelser er MCP-servere. En MCP-server er et program, der giver en AI-assistent en fast defineret adgang til jeres data og, hvor det er tilladt, til at handle i et system. De kører i virksomhedens egen cloud.

    Hvorfor sådan

    Hver person logger ind som sig selv. Så er adgangen personlig og kan trækkes tilbage ét sted.

    Sådan er det sikret

    Hver rolle har sine egne datasæt og grænser. Hvert kald logges, og kan logposten ikke skrives, sendes intet svar. Kladdeforbindelsen kan kun skrive kladder. Den kan aldrig bogføre.

    • Dataforbindelse · MCP

      egen cloud · Cloud Run

      • login pr. person
      • et niveau pr. rolle, med grænser
      • forespørgsel og udtræk
      • hvert kald logges

    • Kladdeforbindelse · MCP

      • skriver kun kladder
      • bogfører aldrig
      • hvert kald logges

    • Daglig mail

      webshop- og lagerforskelle

    bruges af

  5. Trin 5

    Hvem gør hvad

    Operatøren driver og ændrer platformen. Økonomiteamet stiller spørgsmål i deres AI-assistent. Bogholderiagenten forbereder posteringer og skriver dem som kladder i økonomisystemet. Bogholderen gennemgår kladderne og bogfører dem i det økonomisystem, de allerede bruger.

    Hvorfor sådan

    Intet bogføres, før et menneske har godkendt det, og det sker dér, hvor bogholderen allerede arbejder.

    Sådan er det sikret

    Den eneste orange linje på kortet er den, der skriver i et forretningssystem, og for enden af den står et menneske. Hver rolles kort viser, hvad den kan se og gøre, og hvilke grænser den har.

    • Operatør · én konto

      Via
      AI-værktøjer (Claude Code, Codex) → dataforbindelse
      Ser
      alle datasæt, alle selskaber
      Kan
      forespørgeudtrækkekøre
      Grænser
      en daglig scanningsgrænse; kildeudtræk begrænset pr. dag

    • Økonomiteam

      Via
      AI-assistent (Claude) → dataforbindelse
      Ser
      økonomidatasættene
      Kan
      forespørge
      Grænser
      kun læsning; en grænse pr. forespørgsel og pr. dag

    • Analyse · ingen medlemmer endnu

      Via
      samme connector → dataforbindelse
      Ser
      analysedatasættene
      Kan
      forespørge
      Grænser
      en daglig scanningsgrænse

    • Bogholderiagent · én skrivekonto

      Via
      AI-agent (Claude) → kladdeforbindelse
      Ser
      kassekladder og kladder; klargjorte webshoplinjer
      Kan
      skrive kladderimportere
      Grænser
      en grænse pr. kald; importer kører først som prøvekørsel; kan aldrig bogføre
      → skriver kladder iØkonomi · e-conomic · kladder; læses tilbage hver nat

    • Bogholder

      Via
      økonomisystemet (e-conomic)
      Ser
      agentens kladder
      Kan
      gennemgå og bogføre
      Grænser
      uden for platformen

    • Økonomi, via mail

      Via
      en mail hver morgen
      Ser
      gårsdagens forskelle mellem webshop og lager
      Kan
      læse og følge op
      Grænser
      sendes kun, hvis kontrollerne består

  6. Trin 6

    Sådan blev det bygget, og sådan ændres det

    En builder agent skrev pipelines, kontrollerne og forbindelserne inden for projektets egne regler: et skrevet scope før hver pipeline, kontroller pr. tabel og et notat for hver beslutning. Operatøren gennemgår hver plan og godkender den, før noget ændres.

    Hvorfor sådan

    Operatøren godkender en plan i stedet for at skrive pipelines selv, og ingen ændring kommer i drift uden den godkendelse.

    Sådan er det sikret

    Koden udrulles fra Git via Cloud Build. Der er ingen servicekontonøgler nogen steder, og hver pipeline og forbindelse kører med sin egen identitet og kun de rettigheder, den skal bruge.

Kilder

Gennemgangen er skrevet 28. oktober 2026 ud fra platformen, som den er bygget; tallene er målt samme dag.

DuffBeauty har sagt ja til at blive nævnt og har godkendt de detaljer og tal, der vises her.

Vil I se, hvordan det her passer til jeres egne systemer, kan vi gennemgå det sammen, også med jeres IT, internt eller hos jeres IT-partner.

Book en samtale