Sporbarhet, sikkerhet og kontroll

Alt som påvirker en rapports utfall lagres i revisjonsloggen; rapporter sjekkes automatisk for avvik; og roller og tokens kan tilbakekalles på sekundnivå.

Revisjonslogg

Dette lagres i revisjonsloggen:

Domene	Eksempler på hendelser
Brukere	Invitasjon sendt/akseptert/trukket tilbake, rolleendring, blokkering, provisjonering
Ekstern tilgang	Tilgang for ekstern regnskapsfører/rådgiver tildelt, fornyet, tilbakekalt (se API og autentisering)
Rapport	Innsending, godkjenning, avvisning, kommentarer, redigering, statusendring
Flyt	Endringene en flytkjøring gjør på rapporter. Selve kjøringen (trigger, betingelser, handlinger) ligger i flytens kjørelogg (`GET /flows/{id}/traces`)
Integrasjoner	Faktura sendt, levert eller feilet, endringer i integrasjonens innstillinger
Enterprise	Organisasjonen koblet til eller fra et konsern, kategorier lagt til fra konsernet

Hver hendelse inneholder: aktør (bruker, tjenestekonto eller system), tidspunkt (UTC), ressurs-ID, før/etter-snapshot der relevant, og hvilket kall som utløste den (entryPoint, metode og sti).

Lagringstid

Operasjonell revisjonslogg: minimum 5 år (regnskapskrav i Norge).
Flow-traces: 90 dager med full payload, deretter aggregerte metadata.
PAT/SAT-bruk: detaljert i 12 måneder.

Tilgang

Org-Admin og Eier ser revisjonsloggen for sin egen organisasjon via API-et (GET /organizations/{organizationId}/audit-trail, med NDJSON-eksport under /audit-trail/export). Webdashbordet viser den ikke i dag.
Admin og Eier i et konsern kan lese revisjonsloggen til hver medlemsorganisasjon, én organisasjon per kall.
Alminnelige brukere ser sin egen rapporthistorikk.

Kontroller og funn

Rapporter, utgifter og vedlegg analyseres automatisk av et sett kontroller (checks). Hver kontroll kan produsere ett eller flere funn (findings) på en rapport:

Duplikat – samme kvittering brukt flere ganger i organisasjonen: identisk fil (SHA-256), samme dag, beløp, valuta og brukersted, visuelt like bilder eller nesten lik OCR-tekst
Integritet – mulige tegn på manipulering eller AI-generert innhold i et vedlegg
Beløpsavvik – beløpet lest fra kvitteringen (OCR) stemmer ikke med beløpet ført på utlegget
Manglende kvittering – en utgift mangler kvittering, og beløpet er over organisasjonens grense for når kvittering kreves

Resultater vises som badges på rapportnivå og i en mer detaljert kontrollvisning for godkjenner og admin. Et funn med tilstrekkelig sikkerhet kan blokkere godkjenning inntil det er ryddet opp i; andre funn er rådgivende. Bare admin og godkjennere kan avvise eller bekrefte funn – innsenderen av rapporten kan ikke selv rydde opp i egne funn.

Org-admin kan konfigurere hvilke kontroller som er aktive for organisasjonen, og eventuelt justere terskelverdier, via check-policies-API-et.

Tokens og revokering

Token	Levetid	Revokering
Bruker-session (JWT)	Kort (typisk 15 min) + refresh	Logg ut / deaktiver bruker
PAT (`ua_...`)	Til den `expiresAt` du valgte (standard 30 dager)	`DELETE /users/pat/:id` eller fra UI
SAT (`uas_...`)	Til `expiresAt` satt ved opprettelse, ellers uten utløp	Fra tjenestekontoen i dashbordet (Innstillinger → Utvikler); globale SAT-er via chat på utleggsappen.no

Blokkeres eller slettes en bruker, slutter alle brukerens PAT-er å virke umiddelbart.

PAT- og SAT-listevisninger i API-et inkluderer et lastUsedAt-felt (siste vellykkede autentisering, oppdatert med inntil 15 minutters forsinkelse) – bruk det til å identifisere og rydde i ubrukte tokens. Verdien er null for tokens som ikke er brukt siden feltet ble innført.

Hva integrasjoner må ta hensyn til

Behandle funn som forretningslogikk, ikke skjult metadata. Hvis du integrerer med rapporter eller vedlegg, skjul ikke funn (duplikat, integritet, beløpsavvik eller manglende kvittering) fra brukeren.
Funn hentes via GET /reports/:id/findings, og triageres via POST /findings/:id/dismiss|confirm|unresolve. De eldre /fingerprints/*-endepunktene er fjernet.
Rapportsvar inneholder antall funn per kontrolltype. Et tall på 0 betyr at kontrollen kjørte og ikke fant noe; fravær av nøkkelen betyr at kontrollen ikke er aktivert for organisasjonen, eller ikke har kjørt ennå – ikke tolk det ene som det andre.
Kvitteringer for en hel rapport kan hentes samlet via GET /reports/:id/attachments i stedet for å hente vedlegg per utlegg.
Oppgi traceId fra feilresponsens body, eller traceresponse-headeren, i feilmeldinger og support-henvendelser.
Mottakere av webhooks skal være idempotente – samme melding kan leveres flere ganger, med samme webhook-id.

Revisjonslogg​

Lagringstid​

Tilgang​

Kontroller og funn​

Tokens og revokering​

Hva integrasjoner må ta hensyn til​

Se også​