admin/accounted
3
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

docs: correct the systemdokumentation template to match the actual system (#1240)

Browse Source 
The downloadable BFL 5 kap. 11 § template (Hjälp > Dokumentmallar) had not
been touched since March and had drifted into describing a system we no
longer run. Users archive this document as räkenskapsinformation for 7
years, so the wrong facts were being filed as compliance evidence.

Corrected against the code:

- Auth was "Magic link via e-post (lösenordsfri)". It is e-post + lösenord
  with TOTP two-factor, plus optional BankID (lib/auth/require-auth.ts,
  lib/auth/bankid.ts).
- Access control claimed "en användare kan enbart se och redigera sin egen
  data" with a single "Kontoägare" role. Data is company-scoped via RLS and
  there are four roles, owner/admin/member/viewer
  (20260330130000_multi_tenant_company_refactor.sql).
- Rättelse described storno only. Inline rättelse in the same verifikat has
  existed since 20260723210000_verifikat_inline_rattelse.sql; the template
  now documents both tracks and the rule that a locked or closed period
  leaves storno as the only route.
- Voucher numbering claimed uniqueness "per räkenskapsår och användare" and
  a single series. It is per company, fiscal year and series, and the series
  is configurable per source type (lib/bookkeeping/engine.ts).
- Product is Accounted, not erp-base (lib/branding/service.ts).
- OpenAI is listed as an embeddings integration; only a stray env var
  remains in lib/init.ts. Removed. Added Skatteverket, BankID and PostHog,
  which were missing.
- Navigation paths were pre-redesign: Kontoplan is under Data, moms under
  Skatt, and behandlingshistorik exports from Importera/Exportera >
  Säkerhetsbackup, not the "Rapporter > Audit trail" that does not exist.
- BAS 2025/2026 -> BAS 2026.

Added the sections a systemdokumentation needs and this one lacked: API
keys and machine access (external agents can write to the ledger under
scoped keys and are logged as the actor), löner/AGI, anläggningsregister,
periodiseringar and dimensioner as delsystem, and säkerhetskopiering.

The granular "BFNAR 2013:2 punkt 9.x" citations are dropped rather than
renumbered; see DECISIONS.md.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Jakob Wennberg
2026-07-27 16:32:36 +02:00
committed by GitHub
co-authored by Claude Opus 5
parent 52ec3ce497
commit d47b19fd74
2 changed files with 140 additions and 66 deletions
Download Patch File Download Diff File Expand all files Collapse all files
DECISIONS.md
+1
View File
@@ -608,3 +608,4 @@ One line per decision: `[YYYY-MM-DD] <decision>: <why>`. Appended by agents and
[2026-07-27] Identity verification via posthog.setIdentity(distinctId, hash) at runtime rather than the identity_distinct_id/identity_hash init options PostHog's settings page documents. init runs from instrumentation-client.ts app-wide, before the user is known and including logged-out pages, and PostHog fixes init values for the session; setIdentity is a method on the SDK (verified typed in posthog-js 1.407.3) so the hash can be applied from AnalyticsIdentify once the dashboard layout knows who the user is. Without it tickets are browser-scoped and recovered by email.
[2026-07-27] POSTHOG_SECRET_API_KEY is server-only (no NEXT_PUBLIC_ prefix) and the HMAC is computed in the dashboard layout; only the derived per-user hash reaches the browser. The key signs identity hashes AND authenticates external API requests, so it is a real credential unlike the phc_ project token, which is public by design and embedded in the client bundle.
[2026-07-27] Support ticket free-text is declared as its own data category (user.content.support) in .compliance/ropa.yaml and named on the privacy page, separate from analytics. Analytics events deliberately carry no message body (the breadcrumb sends only the subject), but a ticket carries what the user wrote, because that is the point of writing to support. Keeping the two purposes distinct is what stops the privacy page drifting out of date the way the Recapt row did.
[2026-07-27] Removed the granular "BFNAR 2013:2 punkt 9.x" citations from public/docs/systemdokumentation-mall.md instead of renumbering them to kap 8: the swedish-accounting-compliance skill and our own route comments both place systemdokumentation in kap 8, the template asserted kapitel 9 with a full point-by-point mapping (9.1, 9.2, 9.3-9.5, 9.6-9.8, 9.9, 9.16), and neither could be verified against BFN's actual text from here. A downloadable statutory template is the wrong place to guess a legal citation, and a wrong precise cite is worse than a correct general one, so the doc now cites BFL 5 kap. 11 § and BFNAR 2013:2 without pinning points. Restore the points once someone confirms the chapter against the standard.
public/docs/systemdokumentation-mall.md
+139 -66
View File
@@ -1,15 +1,15 @@
# Systemdokumentation
**Mall for användare av erp-base**
Upprättad i enlighet med 5 kap. 11 § BFL och BFNAR 2013:2 kapitel 9
**Mall för användare av Accounted**
Upprättad i enlighet med 5 kap. 11 § BFL och BFNAR 2013:2
---
## Instruktioner
Varje bokföringsskyldig ska upprätta en systemdokumentation som beskriver bokföringssystemets organisation och uppbyggnad. Dokumentationen ska göra det möjligt att utan svårighet överblicka systemet och förstå hur bokföringen är organiserad (BFNAR 2013:2 punkt 9.1).
Varje bokföringsskyldig ska upprätta en systemdokumentation som beskriver bokföringssystemets organisation och uppbyggnad. Dokumentationen ska göra det möjligt att utan svårighet överblicka systemet och förstå hur bokföringen är organiserad.
Denna mall är förifylld med uppgifter som gäller för erp-base. Avsnitt markerade med hakparenteser ska anpassas till ditt företags förhållanden. Radera denna instruktionssektion innan du arkiverar dokumentet.
Denna mall är förifylld med uppgifter som gäller för Accounted. Avsnitt markerade med hakparenteser ska anpassas till ditt företags förhållanden. Radera denna instruktionssektion innan du arkiverar dokumentet.
Systemdokumentationen ska förvaras tillsammans med övrig räkenskapsinformation under hela arkiveringsperioden (7 år).
@@ -29,17 +29,19 @@ Systemdokumentationen ska förvaras tillsammans med övrig räkenskapsinformatio
| Fält | Uppgift |
|---|---|
| Programnamn | erp-base |
| Version | [ANGE VERSION, t.ex. 1.0] |
| Programnamn | Accounted |
| Version | [ANGE VERSION ELLER DATUM FÖR SENASTE KONTROLL] |
| Leverantör | [BOLAGSNAMN], org.nr [ORG-NR] |
| Webbplats | [DOMÄN] |
| Typ | Molnbaserad SaaS-tjänst (webbläsarbaserad) |
| Databasplattform | PostgreSQL via Supabase (AWS, EU-region) |
| Autentisering | Magic link via e-post (lösenordsfri) |
| Webbplats | [DOMÄN, för den molnbaserade tjänsten app.accounted.se] |
| Typ | [ ] Molnbaserad SaaS-tjänst (webbläsarbaserad) [ ] Egen drift (självhostad) |
| Databasplattform | PostgreSQL via Supabase (EU-region) |
| Autentisering | E-post och lösenord. Tvåfaktorsautentisering (TOTP) krävs i den molnbaserade tjänsten. BankID kan kopplas som inloggningsmetod. |
## 3. Kontoplan (BFNAR 2013:2 punkt 9.2)
*Vid egen drift: ange var databasen driftas och vem som ansvarar för drift och säkerhetskopiering.*
3.1. Kontoplanen bygger på BAS-kontoplanen (BAS 2025/2026) utgiven av BAS-intressenternas Förening.
## 3. Kontoplan
3.1. Kontoplanen bygger på BAS-kontoplanen (BAS 2026) utgiven av BAS-intressenternas Förening.
3.2. Kontona är indelade i klasser enligt BAS-standard:
@@ -51,12 +53,12 @@ Systemdokumentationen ska förvaras tillsammans med övrig räkenskapsinformatio
| 4-7 | Kostnader | Konfigureras efter verksamhet |
| 8 | Finansiella poster och skatt | Konfigureras efter verksamhet |
3.3. Kontoplanen kan ses och exporteras i erp-base under Inställningar > Kontoplan.
3.3. Kontoplanen kan ses och exporteras under **Data > Kontoplan**.
3.4. Företagsspecifika anpassningar av kontoplanen:
[BESKRIV EVENTUELLA TILLAGDA ELLER BORTTAGNA KONTON, t.ex. "Konto 4010 Inköp varor, 5010 Lokalhyra har lagts till. Inga standardkonton har tagits bort."]
## 4. Samlingsplan (BFNAR 2013:2 punkt 9.3-9.5)
## 4. Samlingsplan
Samlingsplanen beskriver hur bokföringen är organiserad i form av delsystem, grundbokföring och huvudbokföring.
@@ -86,20 +88,20 @@ Status: Bokförd (posted), verifikationsnummer tilldelas
### 4.2 Grundbokföring (registreringsordning)
Samtliga affärshändelser registreras kronologiskt i erp-base journalen. Varje post innehåller:
Samtliga affärshändelser registreras kronologiskt i journalen. Varje post innehåller:
- Verifikationsnummer (sekventiellt, tilldelat automatiskt vid bokföring)
- Registreringsdatum (datum då posten skapades i systemet)
- Bokföringsdatum (datum för affärshändelsen)
- Beskrivning
- Konteringsrader med konto, debet, kredit
Grundbokföringen kan visas under Bokföring > Journal i erp-base.
Grundbokföringen kan visas under **Bokföring** och exporteras under **Rapporter > Grundbok**.
### 4.3 Huvudbokföring (systematisk ordning)
Huvudbokföringen presenterar affärshändelserna sorterade per konto. Varje konto visar ingående saldo, periodens transaktioner och utgående saldo.
Huvudbokföringen kan visas och exporteras under Rapporter > Huvudbok i erp-base.
Huvudbokföringen kan visas och exporteras under **Rapporter > Huvudbok**.
### 4.4 Delsystem
@@ -111,27 +113,38 @@ Följande delsystem matar journalen:
| Kundbetalningar | Inbetalningar mot fakturor | Debet 1930, kredit 1510 |
| Leverantörsfakturor | Inkommande fakturor, registrering och betalning | Debet kostnadskonto + 2641, kredit 2440 |
| Leverantörsbetalningar | Utbetalningar mot leverantörsfakturor | Debet 2440, kredit 1930 |
| Banktransaktioner | Synkroniserade via PSD2 (Enable Banking) | Kontering via kategoriseringsregler |
| Kvittohantering | OCR-bearbetade kvitton | Kontering efter granskning |
| Kreditnotor | Kreditering av utgående fakturor | Omvänd kontering av originalfaktura |
| Banktransaktioner | Synkroniserade via PSD2 (Enable Banking) eller importerade bankfiler | Kontering via kategoriseringsregler och konteringsmallar |
| Kvitto- och underlagshantering | Uppladdade eller inmejlade underlag, maskinellt avlästa | Kontering efter granskning |
| Kreditnotor | Kreditering av utgående och inkommande fakturor | Omvänd kontering av originalfaktura |
| Löner | Lönekörningar, arbetsgivardeklaration (AGI) | Debet 7xxx + 7510, kredit 2710/2730/1930 |
| Anläggningstillgångar | Anläggningsregister med årliga avskrivningar | Debet 78xx, kredit 12xx |
| Periodiseringar | Periodiseringsscheman över flera perioder | Debet/kredit 17xx respektive 29xx |
### 4.5 Avstämningsordning
[STRYK DE DELSYSTEM SOM INTE ANVÄNDS I DITT FÖRETAG]
Bankkonto 1930 avstäms via erp-base bankavstämningsmodul (4-stegs matchning: exakt belopp+datum, referensmatchning, datumintervall, fuzzy-matchning).
### 4.5 Dimensioner
## 5. Verifikationer (BFNAR 2013:2 punkt 9.6-9.8)
[OM KOSTNADSSTÄLLEN ELLER PROJEKT ANVÄNDS: konteringsrader kan märkas med dimensionsvärden för uppföljning per kostnadsställe eller projekt. Dimensionerna påverkar inte huvudbokföringens saldon. Ses under **Data > Kostnadsställen & projekt**. STRYK DETTA AVSNITT OM DIMENSIONER INTE ANVÄNDS.]
### 4.6 Avstämningsordning
Bankkonto 1930 avstäms via bankavstämningsmodulen (flerstegs matchning: exakt belopp och datum, referensmatchning, datumintervall, sannolikhetsmatchning). Avstämningsstatus visas under **Rapporter > Bankavstämning**.
## 5. Verifikationer
### 5.1 Verifikationsnumrering
Verifikationsnummer tilldelas sekventiellt av systemet vid bokföring. Numreringen är unik per räkenskapsår och användare. Numren tilldelas via databas-RPC (concurrent-safe) och kan inte sättas manuellt.
Verifikationsnummer tilldelas sekventiellt av systemet vid bokföring. Numreringen är unik per företag, räkenskapsår och verifikationsserie. Numren tilldelas via en databasfunktion som är säker vid samtidiga anrop och kan inte sättas manuellt.
En enda verifikationsnummerserie används: [A1, A2, A3, ...].
Systemet stödjer flera verifikationsserier. Standardserien är A. Vilken serie som används kan styras per underlagstyp (t.ex. egen serie för löner) under **Inställningar > Bokföring**.
[OM FÖRETAGET ANVÄNDER FLERA SERIER, BESKRIV HÄR.]
Verifikationsserier som används i detta företag: [ANGE, t.ex. "Endast serie A" eller "A för löpande bokföring, L för löner"]
Om ett verifikationsnummer saknas i en serie ska luckan förklaras. Systemet har en funktion för att registrera förklaringar till nummerluckor, och förklaringarna bevaras som en del av räkenskapsinformationen.
### 5.2 Verifikationens innehåll
Varje verifikation i erp-base innehåller:
Varje verifikation innehåller:
- Verifikationsnummer
- Bokföringsdatum (affärshändelsens datum)
- Registreringsdatum (datum då posten skapades)
@@ -139,34 +152,45 @@ Varje verifikation i erp-base innehåller:
- Konteringsrader (konto, debet, kredit)
- Referens till underlag (bifogat dokument, fakturanummer, etc.)
- Status (utkast / bokförd / reverserad)
- Vid rättelse: referens till reverserad/reverserande verifikation
- Vid rättelse: referens till reverserad eller reverserande verifikation, alternativt rättelselogg för rättelse i samma verifikat
### 5.3 Underlag
Underlag kopplas till verifikationer som bifogade dokument (PDF, bild). Dokumenten lagras i erp-base dokumentarkiv med SHA-256 checksumma for integritetskontroll.
Underlag kopplas till verifikationer som bifogade dokument (PDF, bild). Dokumenten lagras i dokumentarkivet med SHA-256 checksumma för integritetskontroll.
Typer av underlag:
- Kundfakturor (genererade i systemet)
- Leverantörsfakturor (uppladdade)
- Leverantörsfakturor (uppladdade eller inmejlade)
- Kvitton (fotograferade/skannade)
- Bankbekräftelser (synkroniserade)
- Löneunderlag och lönespecifikationer
- Övriga avtal och dokument (uppladdade)
## 6. Rättelser (BFNAR 2013:2 punkt 9.9)
Dokument som är kopplade till bokförda verifikationer kan inte raderas, eftersom de omfattas av arkiveringsskyldigheten.
6.1. Bokförda verifikationer (status: posted) kan inte ändras eller raderas. Detta upprätthålls av databastriggrar i enlighet med bokföringslagens krav på oföränderlighet.
## 6. Rättelser (BFL 5 kap. 5 §)
6.2. Rättelse sker genom stornobokning: en ny verifikation skapas som reverserar den felaktiga posten (byter debet/kredit). Den nya verifikationen länkas till originalet via referens (reverses_id / reversed_by_id).
6.1. Bokförda verifikationer (status: bokförd) kan inte tyst ändras eller raderas. Detta upprätthålls av databastriggrar i enlighet med bokföringslagens krav på oföränderlighet.
6.3. Därefter skapas en ny korrekt verifikation vid behov.
6.2. Systemet stödjer två rättelsevägar, båda med bevarad ursprungsinformation:
6.4. Rättelseverifikationen innehåller uppgift om vilken verifikation som rättats, när rättelsen gjordes, och vem som utförde rättelsen (BFNAR 2013:2 punkt 2.17).
**a) Stornobokning (särskild rättelsepost).** En ny verifikation skapas som reverserar den felaktiga posten (byter debet och kredit). Den nya verifikationen länkas till originalet via referens. Därefter skapas en ny korrekt verifikation vid behov. Denna väg är alltid tillåten.
## 7. Periodavstängning
**b) Rättelse i samma verifikat.** Felaktiga uppgifter eller konteringsrader stryks och ersätts inom samma verifikat. Den ursprungliga uppgiften förblir läsbar, och vem som gjorde rättelsen och när loggas oföränderligt i en separat rättelselogg. Denna väg är endast tillåten så länge perioden är öppen och olåst.
7.1. Räkenskapsperioder kan stängas (låsas) i erp-base. En låst period tillåter inte nya bokföringsposter. Periodlåsning upprätthålls av databastriggrar (enforce_period_lock).
6.3. När en period är låst eller stängd, eller när bokföringen redan legat till grund för en inlämnad deklaration eller ett bokslut, är stornobokning den enda tillåtna vägen.
7.2. Årsbokslut registreras som bokföringsposter i systemet.
6.4. Rättelsen innehåller alltid uppgift om vilken verifikation som rättats, när rättelsen gjordes, och vem som utförde den.
## 7. Periodavstängning och låsning
7.1. Räkenskapsperioder kan stängas och låsas. En låst period tillåter inte nya bokföringsposter. Periodlåsning upprätthålls av databastriggrar, inte enbart av gränssnittet.
7.2. Utöver periodlåsning kan ett företagsgemensamt låsdatum sättas. Ingen bokföring kan ske före detta datum. Ställs in under **Inställningar > Bokföring**.
7.3. Årsbokslut registreras som bokföringsposter i systemet.
7.4. Ansvarig för att stänga och låsa perioder: [NAMN]
## 8. Momshantering
@@ -175,78 +199,127 @@ Typer av underlag:
| Momssats | Beskrivning | Utgående moms-konto | Ingående moms-konto |
|---|---|---|---|
| 25 % | Standardsats | 2611 | 2641 |
| 12 % | Reducerad (livsmedel, hotell m.m.) | 2621 | 2641 |
| 6 % | Reducerad (böcker, tidningar, kultur m.m.) | 2631 | 2641 |
| 12 % | Reducerad (restaurang och servering, hotell m.m.) | 2621 | 2641 |
| 6 % | Reducerad (böcker, tidningar, persontransport, kultur m.m.) | 2631 | 2641 |
| 0 % (export) | Varuexport utanför EU | - | 2641 |
| 0 % (omvänd skattskyldighet) | Försäljning med omvänd skattskyldighet | - | 2641/2645 |
| Omvänd skattskyldighet | Byggtjänster, EU-förvärv, vissa varor | 2614 (beräknad utgående) | 2645 / 2647 |
| Momsfri | Undantagna transaktioner | - | - |
*Notering: Livsmedel sänks till 6 % från 1 april 2026 t.o.m. 31 december 2027.*
*Notering: Livsmedel sänks tillfälligt från 12 % till 6 % under perioden 1 april 2026 till och med 31 december 2027. Restaurang- och serveringstjänster berörs inte av sänkningen utan ligger kvar på 12 %.*
8.2. Fakturor stödjer blandade momssatser (per fakturarad).
8.3. Momsrapport genereras under Rapporter > Momsdeklaration och mappas till Skatteverkets rutor.
8.3. Momsdeklarationsunderlag genereras under **Skatt > Moms** och mappas till Skatteverkets rutor.
## 9. Behandlingshistorik (BFNAR 2013:2 punkt 9.16)
8.4. Redovisningsmetod: [ ] Faktureringsmetod [ ] Kontantmetod
Momsperiod: [ ] Månad [ ] Kvartal [ ] Helår
9.1. erp-base registrerar automatiskt en behandlingshistorik som inkluderar:
- Registreringsdatum och tidpunkt for varje journalpost
## 9. Behandlingshistorik
9.1. Systemet registrerar automatiskt en behandlingshistorik som inkluderar:
- Registreringsdatum och tidpunkt för varje journalpost
- Tidpunkt för statusändring (utkast till bokförd)
- Vem som utförde bokningen (användar-ID kopplat till e-postadress)
- Vem som utförde bokningen (användar-ID kopplat till e-postadress, eller API-nyckel vid maskinell bokföring)
- Stornobokningar med referens till originalverifikation
- Rättelser i samma verifikat, med ursprungsvärde, nytt värde, tidpunkt och utförare
- Tidpunkt och utförare av periodlåsning
- Importer och maskinella körningar
9.2. Behandlingshistoriken genereras automatiskt av systemet och kan inte ändras av användaren.
9.3. Behandlingshistoriken kan exporteras under Rapporter > Audit trail.
9.3. Behandlingshistoriken exporteras under **Importera/Exportera > Exportera > Säkerhetsbackup**. Exporten är en ZIP-fil som innehåller `revision/behandlingshistorik.json` (alla ändringar) och `revision/systemdokumentation.json` (kontoplan, verifikationsserier, arkiveringsprinciper), utöver SIE-filer, rapporter och underlag.
## 10. Import och export
| Funktion | Format | Beskrivning |
|---|---|---|
| SIE-import | SIE4 | Import av bokföringsdata från annat system |
| Bankfil-import | CSV (10 svenska bankformat) | Import av banktransaktioner |
| Bankfil-import | CSV och flera svenska bankformat | Import av banktransaktioner |
| SIE-export | SIE4 | Export av komplett bokföring per räkenskapsår |
| Huvudbok | PDF/skärm | Export av huvudbok |
| Resultaträkning | PDF/skärm | Export av resultaträkning |
| Balansräkning | PDF/skärm | Export av balansräkning |
| Säkerhetsbackup | ZIP | Komplett arkiv: SIE, rapporter, underlag, register och behandlingshistorik |
| Huvudbok och grundbok | PDF/skärm/CSV | Export av grund- och huvudbokföring |
| Resultat- och balansräkning | PDF/skärm | Export av resultat- och balansräkning |
| Momsdeklaration | PDF/skärm | Underlag för momsdeklaration |
| SRU-export | SRU | Export for inkomstdeklaration |
| Periodisk sammanställning | PDF/skärm | EU-försäljning av varor och tjänster |
| SRU-export | SRU | Export för inkomstdeklaration (AB) |
| NE-bilaga | PDF/skärm | Bilaga till inkomstdeklaration (EF) |
| Årsredovisning | PDF/skärm | Årsredovisning för aktiebolag |
| Verifikationsunderlag | PDF/bild | Nedladdning av bifogade dokument |
## 11. Integrationer
| Integration | Beskrivning | Dataflöde |
|---|---|---|
| Enable Banking (PSD2) | Bankkontosynkronisering | Bank -> erp-base (läsning av transaktioner och saldon) |
| Anthropic API | AI-kategorisering av transaktioner, OCR | erp-base -> Anthropic -> erp-base (transaktionsdata skickas, kategoriseringsförslag returneras) |
| OpenAI API | Embeddingar for likhetsmatchning | erp-base -> OpenAI -> erp-base (transaktionsbeskrivningar skickas, vektorer returneras) |
| Resend | E-postutskick | erp-base -> Resend -> mottagare (fakturor, påminnelser) |
| Enable Banking (PSD2) | Bankkontosynkronisering | Bank -> Accounted (läsning av transaktioner och saldon) |
| Skatteverket | Momsdeklaration, arbetsgivardeklaration (AGI), skattekonto | Accounted -> Skatteverket (inlämning signeras med BankID) |
| Anthropic (Claude) | Maskinell kategorisering av transaktioner och avläsning av underlag | Accounted -> Anthropic -> Accounted (transaktions- och dokumentdata skickas, förslag returneras) |
| Resend | E-postutskick | Accounted -> Resend -> mottagare (fakturor, påminnelser) |
| BankID (via identitetsleverantör) | Inloggning och signering | Accounted -> leverantör -> Accounted |
| PostHog | Användningsstatistik för tjänsten | Accounted -> PostHog |
[ANGE YTTERLIGARE INTEGRATIONER OM TILLÄMPLIGT]
[ANGE YTTERLIGARE INTEGRATIONER OM TILLÄMPLIGT, t.ex. import från Fortnox, Visma, Bokio, Björn Lundén eller Briox]
## 12. Behörigheter och åtkomstkontroll
**Notering om maskinell behandling:** förslag från maskinella hjälpmedel bokförs aldrig automatiskt utan att en användare har granskat och godkänt dem. Godkännandet loggas i behandlingshistoriken.
12.1. Varje konto i erp-base är isolerat via Row Level Security (RLS) i databasen. En användare kan enbart se och redigera sin egen data.
## 12. API-nycklar och maskinell åtkomst
12.2. Nuvarande behörighetsstruktur:
12.1. Externa system och AI-assistenter kan ges åtkomst till bokföringen via API-nycklar. Nycklarna skapas och återkallas under **Inställningar > API**.
12.2. Varje nyckel har avgränsade behörigheter (scopes), t.ex. enbart läsning av rapporter eller skrivning av transaktioner. En nyckel kan aldrig göra mer än sina tilldelade behörigheter.
12.3. Åtgärder som utförs via API-nyckel loggas i behandlingshistoriken med nyckeln som utförare.
12.4. Utfärdade API-nycklar och deras behörigheter:
| Nyckelns namn | Syfte | Behörigheter | Utfärdad |
|---|---|---|---|
| [NAMN] | [T.EX. BOKFÖRINGSBYRÅNS ASSISTENT] | [SCOPES] | [DATUM] |
[STRYK DETTA AVSNITT OM INGA API-NYCKLAR ANVÄNDS]
## 13. Behörigheter och åtkomstkontroll
13.1. All data är knuten till ett företag och isolerad via Row Level Security (RLS) i databasen. En användare kommer enbart åt data för de företag hen är medlem i.
13.2. Behörighetsstruktur:
| Roll | Beskrivning |
|---|---|
| Kontoägare | Full åtkomst till all data och funktionalitet |
| Ägare (owner) | Full åtkomst, kan hantera medlemmar och äganderätt |
| Administratör (admin) | Full åtkomst till bokföring och inställningar, begränsad medlemshantering |
| Medlem (member) | Arbetar i bokföringen |
| Läsare (viewer) | Endast läsåtkomst |
[OM YTTERLIGARE ROLLER FINNS, BESKRIV HÄR]
13.3. Företag kan grupperas så att en bokföringsbyrå eller konsult får åtkomst till flera företag. [BESKRIV OM EXTERN BYRÅ HAR ÅTKOMST, OCH I SÅ FALL VILKEN.]
12.3. Ansvarig for att tilldela och granska behörigheter: [NAMN]
13.4. Tvåfaktorsautentisering (TOTP) krävs för samtliga användare i den molnbaserade tjänsten.
## 13. Uppdatering av systemdokumentationen
13.5. Personer med åtkomst till bokföringen:
| Namn | Roll | Tilldelad |
|---|---|---|
| [NAMN] | [ROLL] | [DATUM] |
13.6. Ansvarig för att tilldela och granska behörigheter: [NAMN]
## 14. Säkerhetskopiering och arkivering
14.1. Räkenskapsinformationen lagras i EU och bevaras i minst 7 år enligt BFL 7 kap.
14.2. Utöver leverantörens lagring bör företaget själv ta ut en egen kopia. Detta görs under **Importera/Exportera > Exportera > Säkerhetsbackup**.
14.3. Företagets rutin för egen säkerhetskopiering: [BESKRIV HUR OFTA OCH VAR KOPIAN FÖRVARAS, t.ex. "En gång per kvartal samt vid varje bokslut. Förvaras krypterad på extern disk."]
14.4. Se även företagets arkivplan, som beskriver var räkenskapsinformationen förvaras.
## 15. Uppdatering av systemdokumentationen
Systemdokumentationen ska uppdateras vid:
- Byte eller uppgradering av bokföringsprogram
- Ändringar i kontoplan
- Ändringar i momshantering
- Nya integrationer eller delsystem
- Ändrade behörigheter eller nya API-nycklar
- Minst en gång per räkenskapsår
| Datum | Ändring | Utförd av |
@@ -256,4 +329,4 @@ Systemdokumentationen ska uppdateras vid:
---
*Denna systemdokumentation uppfyller kraven i 5 kap. 11 § BFL och BFNAR 2013:2 kapitel 9 (punkterna 9.1-9.16) samt Exempel 9.1-9.4 i vägledningen. Anpassa innehållet till ditt företags specifika förhållanden.*
*Denna systemdokumentation är avsedd att uppfylla kraven i 5 kap. 11 § BFL och BFNAR 2013:2. Anpassa innehållet till ditt företags specifika förhållanden.*