LLMs hører hjemme i narrative-laget — ikke i laget for finansiel sandhed

Jeg kan godt lide fart. Jeg kan godt lide færre manuelle trin. Jeg kan godt lide ethvert værktøj, der fjerner meningsløst arbejde fra en close.

Men jeg kan ikke lide tvetydighed i finansiel sandhed.

Large language models er grundlæggende probabilistiske. Finansiel rapportering skal være deterministisk, sporbar og gentagelig. De to verdener kan godt sameksistere, men kun hvis vi sætter en hård arkitektonisk grænse mellem dem.

Min holdning er enkel: LLMs hører hjemme i narrative-laget, ikke i laget for finansiel sandhed. De kan skrive udkast til variance commentary, samle disclosure-tekst og hjælpe jer med at kommunikere det, der allerede er sket. De må aldrig generere, transformere, “rette” eller afstemme tal. De må aldrig være stedet, hvor kontroller bor. Og de må aldrig være systemet, der lydløst ændrer, hvad der anses for sandt.

Jeg lærte den disciplin længe før generativ AI. Som tidligere QA- og test manager på tværs af hardware og software, og senere med ansvar for R&D-organisationer, levede jeg efter én regel: Hvis du ikke kan spore det, kan du ikke shippe det. Reporting er samme disciplin — bare med højere konsekvens. Hvis du ikke kan spore det, kan du ikke rapportere det.

To-lags-modellen: sandhed versus narrativ

De fleste teams blander de her lag uden at opdage det. Et regneark bliver kopieret. Et tal bliver omklassificeret “bare til decket”. Nogen redigerer en forklaring efterfølgende. Pludselig begynder historien at drive tallene.

Med LLMs mangedobles risikoen, fordi værktøjet er designet til at levere et plausibelt svar. Det er ikke designet til at bevare en chain of custody.

Derfor deler jeg systemet op i to eksplicitte lag:

• Lag for finansiel sandhed: hovedbog, subledgers, data warehouse, deterministiske beregninger, versionerede regnskabsregler, godkendelser og sign-offs. Alt her er reproducerbart og auditerbart.
• Narrative-lag: ledelseskommentarer, udarbejdelse af disclosure-tekst, forklaringer på afvigelser og Q&A til interne stakeholders. Alt her er afledt — aldrig autoritativt.

Grænsen er vigtig, fordi den sætter jeres governance-udgangspunkt. I truth layer antager du, at enhver ændring skal kunne forklares og tilskrives en ansvarlig. I narrative-laget antager du, at hver sætning skal kunne understøttes af evidens, men du accepterer, at tekst er iterativ.

Hvis du vil have en mental model fra industriel teknologi: betragt hovedbogen som sensoren, og LLM’en som annotationen på dashboardet. Du kan ændre annotationen hele dagen. Du “forbedrer” ikke sensorens måling med kreativ skrivning.

Et auditerbart design: data-to-text, ikke text-to-data

Det eneste design, jeg stoler på i regulerede kontekster, er en data-to-text pipeline. Ikke text-to-data. Ikke “chat med tallene og lad den opdatere spreadsheetet”.

Her er den blueprint, jeg ville lægge på bordet foran et audit committee.

1. Låst source of truth: hovedbog og governance-styrede warehouse-tabeller. Uforanderligt hvor det skal være uforanderligt, og adgangsstyret alle steder.
2. Deterministisk calculation layer: aggregeringer, mapping, elimineringer, FX-logik, allokeringsregler. Versionerede regler og reproducerbare runs. Ingen skjulte trin.
3. Uforanderlig evidence pack: de præcise queries der blev kørt, parameterværdier, snapshots af resultatsæt, links til source-tabeller, tidsstempler og identiteten på kørslen. Tænk på det som et “build artifact” for rapportering.
4. LLM begrænset til pakken: modellen ser kun evidence pack og en fast reporting-template. Den skriver udkast til kommentarer og disclosure-tekst, og den skal kunne angive hvilket artifact, der understøtter hvilken påstand.
5. Change logs og approvals: ændringer i narrativet bliver logget. Endelig sign-off er fortsat menneskelig, og den refererer til det evidence pack-ID, der blev brugt.

Det er samme operating principle, som jeg brugte, da jeg ledte internationale R&D-teams. Vi accepterede ikke “det virker på min maskine”. Vi accepterede build artifacts, versionerede afhængigheder og test evidence. Reporting fortjener samme standard for bevis.

Hvis du vil længere ned i operationelle guardrails for AI, går den samme filosofi igen i min tekst om hvorfor stop-knappen er den reelle AI-værdi. Reporting har også brug for en stop-knap. Den hedder: “ingen evidens, ingen sætning”.

Hvad LLMs er fremragende til (og hvad de ikke er)

Brugt rigtigt kan LLMs fjerne noget af det lavest værdiskabende arbejde i finans- og ESG-rapportering. Arbejdet, der brænder senior-tid af og skaber fejl på grund af træthed.

Det her er gode use cases:

• Udkast til variance commentary fra et på forhånd defineret variance-træ (pris, volumen, mix, one-offs) — udelukkende baseret på evidence pack.
• Sammensætning af disclosure-tekst ved at kombinere godkendt boilerplate med periodespecifikke fakta, igen med referencer til evidens.
• Fremsøgning af underliggende evidens til interne spørgsmål, så længe retrieval sker fra governance-styrede repositories — ikke fra det åbne web.
• Konsistenschecks på sproget: modsiger forklaringerne hinanden, driver definitioner på tværs af afsnit, bruger vi samme term for samme begreb.

Det her er dårlige use cases, selv om de ser effektive ud i en demo:

• At generere tal (“estimer manglende data”, “fyld huller”, “udglat anomalier”). Det er modellering, ikke rapportering.
• At transformere tal inde i en prompt (“konverter denne tabel til rapporteret omsætning pr. region”). Den transformation hører til i et deterministisk lag med versioneret logik.
• At “rette” data (“det her ser forkert ud, justér det”). Værktøjet kan ikke eje kontrollen. Mennesker skal undersøge upstream og derefter genkøre den deterministiske pipeline.
• Auto-approving udkast eller sign-offs. En signatur skal hænge på accountability — ikke convenience.

I mine egne ventures, herunder IBHQ og Shopeno, tænker jeg på AI på samme måde: Lad det accelerere beslutninger, ikke erstatte system of record. I det øjeblik modellen bliver “recorden”, mister du både tillid og mulighed for at debugge.

Kontroller du kan implementere i dette kvartal

Hvis du er CFO, controller, head of reporting eller et bestyrelsesmedlem, der spørger “hvad gør vi nu”, ville jeg starte med en kort checklist. Det er operator-greb, ikke teori.

1) Skriv boundary-policy på én side

• LLM-output er aldrig et finansielt record.
• LLM må kun skrive tekstudkast og skal referere til evidence artifacts.
• Ingen LLM-tool får write access til hovedbog, warehouse eller konsolideringsmotor.

Den policy forhindrer “hjælpsomme” genveje, der senere bliver usynlig process debt.

2) Byg en evidence pack som et software release artifact

• Gem de queries og parametre, der skabte hver rapporteret tabel.
• Gem snapshots af resultater — ikke kun links.
• Giv pakken et unikt ID og gør det til ankeret for hvert narrativt udkast.

Som tidligere kvalitetsleder i power electronics så jeg, hvor hurtigt teams bliver disciplinerede, når enhver fejl kan spores til en specifik build. Reporting-kvalitet forbedres på samme måde, når enhver påstand kan mappes til et konkret artifact.

3) Gennemtving citations i narrativet

Accepter ikke fri kommentar uden referencer. Kræv at udkastet indeholder interne citations som fx “EvidencePack:2026-05 CloseRun:14 Query:RevenueByRegion_v3”. Hvis modellen ikke kan citere, skal den sige “insufficient evidence”.

4) Gør variance commentary til en governance-styret template

• Definér variance-træet én gang.
• Definér hvad der tæller som en one-off.
• Definér thresholds for hvornår modellen må foreslå et narrativ, og hvornår den skal eskalere til en owner.

Det reducerer risikoen for narrative drift og gør kommentarer sammenlignelige kvartal for kvartal.

5) Adskil “drafting” fra “approval” i værktøjerne

LLM’en kan bo i et drafting-miljø. Approval skal ske i en kontrolleret workflow med identitet, tidsstempler og eksplicit sign-off. Det er samme adskillelse, som industrielle teams bruger mellem en test bench og en production line.

Bestyrelsens nøglespørgsmål: Hvad optimerer vi efter?

De fleste diskussioner om AI i reporting går i stå i “labor savings”. Det er ikke den rigtige objective function.

Den rigtige målsætning er: kortere cyklustid uden højere audit risk.

Da jeg havde ansvar for en forretningsenhed på tværs af flere lande med fuldt P&L-ansvar, var close ikke bare en finance-aktivitet. Det var en operating rhythm. Forecast-dialoger, lagerbeslutninger og kommerciel prioritering afhænger af, om tallene er til at stole på. I det øjeblik tilliden falder, går alt langsommere. Folk begynder at dobbelttjekke. Møder bliver til diskussioner om data i stedet for beslutninger.

Så jeg vil ikke have “AI reporting”. Jeg vil have auditable acceleration. Hurtigere drafting, hurtigere review, hurtigere konsistenschecks. Samme truth layer. Samme ejerskab af kontroller.

Derfor er jeg også varsom med modelstørrelse og deployment patterns i operationelle miljøer. Disciplinen i at shippe pålidelig AI handler om constraints — ikke ambition. Det samme tema udfolder jeg i hvorfor små modeller ofte er den eneste fornuftige måde at shippe på. I reporting er parallellen en begrænset model med en begrænset kontekst.

Min takeaway: hold maskinen ærlig ved at holde den ude af sandheden

LLMs kan absolut gøre reporting bedre. De kan fjerne repetitiv drafting, øge klarheden og forkorte cyklusser. De kan endda hæve kvalitetsniveauet ved at håndhæve konsistent sprog og struktur.

Men kun hvis du er kompromisløs med, hvor de må operere.

Placér dem i narrative-laget. Giv dem en uforanderlig evidence pack. Kræv citations. Log hver ændring. Hold beregninger deterministiske og versionerede. Hold approvals menneskelige og forankret i accountability.

Så får du værdien uden at bytte den ene ting væk, som reporting ikke kan overleve uden: finansiel sandhed.