Hoppa till innehåll

Behandlingshistorik

Behandlingshistorik är den juridiskt bindande loggen över allt som hänt i företagets bokföring — vem som gjort vad, när, baserat på vilket underlag, med vilken AI-assistans. Enligt Bokföringslagen 5 kap 11 § ska denna historik kunna visas för Skatteverket eller revisorn om de frågar.

Redofys implementation är mer omfattande än vad lagen kräver — vi bygger en kryptografiskt tamper-evident loggstruktur som kan användas som rättsligt bevismaterial.

Allt som påverkar bokföringen:

  • Verifikationer — skapande, commit, rättelseverifikationer.
  • Agentbeslut — varje förslag från Bank-, Kvitto-, Bokförings-, Avstämnings-, Skatt- och Revisoragenten.
  • Användaraktioner — godkännanden, avvisningar, manuella ändringar.
  • Inställningar — ändringar av kontoplan, räkenskapsår, användarroller.
  • Tillgång — inloggningar, sidvisningar, export av känslig data.
  • Integration — SKV-inlämningar, bankkopplingsförnyelser.
  • Systemhändelser — migrationer, failovers, planerat underhåll.

Varje post har:

  • Tidsstämpel — mikroukunder-precision, UTC.
  • Aktör — användar-id eller agent-id + modellversion.
  • Åtgärd — vad som gjordes.
  • Påverkat data — hash före och efter (för ändringar).
  • Korrelationsidentifierare — länkar händelser som hör ihop.

Loggen ligger i tre PostgreSQL-tabeller:

  • behandlingshistorik — affärsrelaterade händelser (verifikationsändringar, godkännanden).
  • agent_tool_calls — varje verktygsanrop agenten gjort, med argument och resultat.
  • audit_log — systemrelaterade händelser (inloggning, rollbyte, integration-förändring).

Samtliga tre är append-only — INSERT är tillåtet, UPDATE och DELETE är strukturellt förhindrat via triggers.

För att skydda mot tamper använder Redofy en hash-kedja:

Entry N: hash_N = SHA256(entry_N_data || hash_{N-1})

Varje ny post innehåller hash:en av föregående post. Att ändra en historisk post skulle kräva att alla efterföljande hashes också ändrades — vilket upptäcks av daglig validering.

Kedjan startar från en genesis-hash som är hårdkodad vid första installationen.

Utöver hash-kedjan skapas varje dag en Merkle-root över dagens händelser:

  1. Alla händelser för dagen hashas.
  2. Hasharna byggs ihop som ett Merkle-träd.
  3. Trädets rot är dagens Merkle-root.
  4. Merkle-roten signeras med Redofys HSM-nyckel (Hardware Security Module).
  5. Signaturen och roten publiceras till en off-system location — för närvarande en annan cloud-region, i framtiden en public blockchain-anchor eller time-stamping service.

Fördelen med detta: en oberoende tredje part (revisor, Skatteverket, domstol) kan verifiera att loggen är äkta genom att:

  1. Ta Redofys signerade Merkle-root för ett specifikt datum.
  2. Rekonstruera Merkle-trädet från dagens agent_tool_calls + behandlingshistorik.
  3. Jämföra rekonstruktionens rot med den signerade.

Om de matchar är loggen äkta. Om de inte matchar har något ändrats efter signering — vilket är bevis på tampering.

Signeringsnyckeln för Merkle-rotarna bor i en Hardware Security Module (HSM) — en fysisk säkerhetsenhet som:

  • Kan bara signera, inte exportera nyckeln.
  • Kräver multi-factor authentication för access.
  • Loggar varje användning separat.
  • Är ISO/IEC 19790 Level 3-certifierad.

Detta betyder att även om Redofys servrar blev komprometterade skulle angriparen inte kunna signera fel rotar åt dig — HSM-nyckeln skulle vägra.

Åtkomst är strikt kontrollerad:

  • Ägare + Administratör — full åtkomst till sin egen tenant.
  • Bokförare — åtkomst till bokföringsrelaterade poster.
  • Revisor — full åtkomst (standardkrav för revision).
  • Anställd — bara sina egna poster (t.ex. sina egna kvittouppladdningar).

Skatteverket, domstolar eller polis kan kräva utlämning via formell begäran — vilket i sig loggas.

Behandlingshistoriken sparas i 10 år:

  • 7 år enligt Bokföringslagens krav.
  • 3 år extra för eventuell tvist-drivning (preskriptionsreglerna).

Efter 10 år arkiveras loggen till cold storage (billigare lagring, längre åtkomsttid) men tas inte bort. Tidskritisk åtkomst är då inte garanterad, men datan finns kvar.

Hela behandlingshistoriken (eller en tidsperiod) kan exporteras som:

  • JSON — strukturerad data för import till annat system.
  • CSV — för Excel-analys.
  • PDF — för arkivering eller inskick.
  • Redofy-paket — inkluderar underlagsfiler så hela kedjan kan rekonstrueras offline.

Exporten är signerad med Redofys nyckel så mottagaren kan verifiera äktheten.

För AI-beslut loggar Redofy mer än bara “beslut fattades”:

  • Vilken modell — Claude Haiku 4.5 / Sonnet 4.6 / Opus 4.7, version.
  • Vilken systemprompt — hash av systemprompten (inte själva prompten, för kostnads- och integritetsskäl).
  • Vilka verktyg — vilka tool calls agenten gjorde.
  • Vilka resultat — vad verktygen returnerade.
  • Konfidens — hur säker agenten var.
  • Cost och tokens — för spårbarhet på kostnader.

Detta gör det möjligt att återskapa en AI-körning vid behov — t.ex. om en verifikation ifrågasätts kan man rekonstruera vad agenten såg och beslutade baserat på.

Traditionella applikations-loggar (t.ex. vad som skrivs till stdout, mid-request-debugging) är inte behandlingshistorik:

  • Vanliga loggar kan raderas eller roteras bort.
  • De är inte kryptografiskt säkrade.
  • De har ingen juridisk bindande status.

Behandlingshistoriken är en parallell, separat struktur som är byggd för långvarighet och bevislig integritet. Vanlig loggning kan fortfarande existera för felsökning.

Behandlingshistoriken innehåller personuppgifter (användare-id:n, vilka personer som gjort vad). Enligt GDPR har en registrerad rätt att få sina uppgifter raderade.

Men BFL har en lex specialis-relation till GDPR: bokföringslagens retentionskrav går före GDPR:s rätt till radering, för bokföringsrelaterad data. Du kan alltså inte begära att bli “borta” från behandlingshistoriken under 7+ år efter räkenskapsårets slut.

Efter 7 år kan personuppgifter pseudonymiseras (användar-id:n ersätts med systemgenererade anonyma id:n) medan hash-kedjan förblir intakt.

Scenario: SKV granskar företaget 3 år efter händelse och ifrågasätter en specifik verifikation.

  1. Du öppnar Redofy → Huvudbok → klicka på verifikationen.
  2. Ser hela kedjan: underlag → agentförslag → ditt godkännande → commit.
  3. Exportera behandlingshistoriken för den specifika verifikationen som PDF.
  4. Bifoga PDF:en i SKV-svaret.

Om SKV ifrågasätter äktheten kan de verifiera Merkle-roten för det datumet mot Redofys signerade off-system-kopia. Matchar = autentisk.

Denna struktur har gjort Redofy till ett starkt val för företag som vill ha en juridiskt osårbar bokföring.