Bokföringslagen och självhostning

Ett företag ska 1. löpande bokföra alla affärshändelser enligt 5 kap. 1–5 §§, 2. se till att det finns verifikationer enligt 5 kap. 6–9 §§ för alla bokföringsposter samt systemdokumentation och behandlingshistorik enligt 5 kap. 11 §, 3. bevara all räkenskapsinformation och sådan utrustning och sådana system som behövs för att presentera räkenskapsinformationen i den form som anges i 7 kap. 1 § 1, 4. upprätta en balansräkning enligt 3 §, och 5. avsluta den löpande bokföringen enligt 6 kap.

Läs subjektet: ett företag ska. Varenda skyldighet i bokföringslagen riktar sig till det bokföringsskyldiga företaget — inte till den som skrivit programmet. Det gäller likadant för en molntjänst: att bokföringen ligger hos en leverantör flyttar inte ansvaret dit, det lägger bara en part till mellan dig och din räkenskapsinformation.

Därav följer något som ofta sägs baklänges i branschen: det finns ingen myndighet som godkänner eller certifierar bokföringsprogram i Sverige. Kravet i 4 kap. 2 § är att bokföringsskyldigheten fullgörs på ett sätt som överensstämmer med god redovisningssed — ett krav på bokföringen, inte en stämpel på en produkt. Ett program kan göra det lätt eller svårt att uppfylla lagen. Det kan aldrig uppfylla den åt dig.

Elektronisk bokföring är uttryckligen tillåten. Formkravet i 7 kap. 1 § är att informationen ska kunna tas fram i en pappershandling genom en omedelbar utskrift, och att en elektronisk handling ska bevaras i det format och med det innehåll den hade när den kom till företaget eller sammanställdes av det.

De pappershandlingar och elektroniska handlingar som används för att bevara räkenskapsinformation ska vara varaktiga och lätt åtkomliga. De ska bevaras fram till och med det sjunde året efter utgången av det kalenderår då räkenskapsåret avslutades (bevarandetid). De ska förvaras i Sverige, i ett ordnat skick och på ett betryggande och överskådligt sätt. Den utrustning och de system som behövs för att presentera räkenskapsinformationen i en pappershandling ska hållas tillgängliga i Sverige under hela bevarandetiden.

Huvudregeln är alltså Sverige. Undantaget står i 7 kap. 3 a §: ett företag får förvara elektroniska handlingar och hålla utrustningen tillgänglig i ett annat EU-land (och i vissa länder utanför EU med motsvarande rättsliga instrument) om tre villkor är uppfyllda:

• platsen för förvaring och varje ändring av den anmäls till Skatteverket (Finansinspektionen för företag under dess tillsyn),
• företaget på begäran av Skatteverket eller Tullverket medger omedelbar elektronisk åtkomst till räkenskapsinformationen för kontrolländamål under bevarandetiden, och
• företaget kan genom omedelbar utskrift ta fram informationen i Sverige i en pappershandling.

Läs 7 kap. 2 § en gång till och räkna kraven: de är två. Räkenskapsinformationen ska förvaras i Sverige, och utrustningen och systemen som behövs för att presentera den i en pappershandling ska hållas tillgängliga här under hela bevarandetiden. Undantaget i 7 kap. 3 a § är skrivet för båda — det talar uttryckligen om att förvara elektroniska handlingar och hålla utrustningen och systemen tillgängliga i ett annat EU-land. En uppsättning har därför två regionval, inte ett, och de sitter på olika ställen:

• Databasen och fillagringen. Väljer du Stockholm som region ligger räkenskapsinformationen i Sverige. Väljer du Frankfurt, Irland eller någon annan EU-region är det tillåtet — men då är anmälan till Skatteverket enligt 7 kap. 3 a § 1 din uppgift, och den ska göras om igen varje gång platsen ändras.
• Appen som skriver ut. Utskrifterna byggs av programmet självt, alltså där appen körs — inte inne i databasen. Den hostingen har en egen regioninställning, och den följer inte med databasens val: hos Vercel körs funktioner i nya projekt som förval i Washington DC (iad1), inte i Stockholm. Vill du att båda kraven ska landa på samma ställe byter du funktionsregion till Stockholm (arn1) under projektets inställningar innan du börjar bokföra. Det är en meny hos leverantören — programmet kan inte sätta den åt dig, och vi kan inte se vad du valt.

Vi påstår inte att den andra punkten avgör bedömningen i ditt fall. Vad som är "utrustning och system" för en app som hämtar och skriver sin data i Sverige är inte självklart, och den frågan är din och din revisors. Vi säger att valet finns, att det är ditt, och att det nästan aldrig står skrivet någonstans — en sida som besvarar en juridisk invändning genom att nämna halva paragrafen vore inte värd mer än invändningen.

Utskriftskravet uppfyller programmet på din sida: huvudbok, verifikationslista, balans- och resultatrapport skrivs ut som PDF när som helst, och arkivexporten lägger SIE-filen, resultatrapporten, balansrapporten, huvudboken, verifikationslistan och varje underlag i samma zip. Åtkomstkravet kan du möta med granskarrollen, som ingår och inte har något slutdatum. Anmälan gör vi inte åt dig — den är företagets, och vi har varken insyn i eller behörighet till ditt ärende hos Skatteverket.

Elektronisk räkenskapsinformation ska säkerhetskopieras. Hur ofta räkenskapsinformationen ska säkerhetskopieras får bedömas med hänsyn till förhållandena i det enskilda företaget. En säkerhetskopia ska förvaras åtskild från den kopierade räkenskapsinformationen.

Tre saker följer, och alla tre är byggda in i programmet i stället för att stå som en uppmaning i en guide:

• Kopian tas automatiskt. Varje natt byggs hela räkenskapsårets arkiv — SIE 4, rapporterna som PDF och varje underlag — och läggs upp på en lagring du äger.
• Kopian ligger åtskild. Destinationen är ett annat konto eller en annan lagring än den bokföringen ligger i, och uppsättningen vägrar om destinationen visar sig vara samma projekt som bokföringen — också när den skrivits som projektets egen S3-adress, som ser ut som en annan server men inte är det. Det är sista meningen i punkt 8.2, kodad.
• Kopian räknas inte som tagen förrän den lästs tillbaka. Filen hämtas hem igen och jämförs mot sin egen SHA-256-summa; stämmer längden eller summan inte, är körningen misslyckad och nästa körning är fortfarande försenad. En säkerhetskopia ingen någonsin läst tillbaka är en förmodan, och punkt 8.1 kräver att informationen förvaras så att den inte riskerar att förstöras eller förkomma.

Frekvensen lämnar rådet uttryckligen till företaget. Förvalet är dagligen. Vi driftar ingen lagring och tar ingen avgift per gigabyte — destinationen är ditt konto hos den leverantör du väljer, och nycklarna står i din egen miljö.

Bevarandetiden räknas inte från fakturans datum utan till och med det sjunde året efter utgången av det kalenderår då räkenskapsåret avslutades [7 kap. 2 §]. För ett räkenskapsår som slutar 2026-12-31 betyder det till och med utgången av 2033.

Programmet håller tiden med en regel i databasen, inte med en påminnelse i gränssnittet: ett kvitto eller en faktura som är kopplad till ett verifikat kan inte raderas så länge verifikatet finns. Och verifikatet självt kan varken ändras eller raderas av någon roll i programmet — se Bokföringsmotorn.

Att flytta arkivet någon annanstans är tillåtet, men villkorat. 7 kap. 6 § tillåter att handlingarna förstörs om informationen överförstill en annan handling, och bara om överföringen "med hänsyn till tekniska metoder, organisatoriska åtgärder och övriga omständigheter inte innebär risk för att räkenskapsinformationen förändras eller försvinner". Arkivexporten är den form en sådan överföring kan ta — SIE 4 plus underlagen, i en zip som går att öppna utan både databasen och programmet. Bedömningen att överföringen skett utan risk är företagets, inte vår. Vill du förstöra något före bevarandetidens slut krävs tillstånd av Skatteverket [7 kap. 7 §].

Det är invändningen, ordagrant som den brukar ställas, och den förtjänar ett rakt svar: nej, ingenting hindrar det — och det gör inte heller något annat bokföringsprogram i världen. Den som äger en databas kan tekniskt röra vad som helst i den. Hos en molntjänst gäller exakt samma sak, med skillnaden att den som kan är leverantörens databasadministratör i stället för du. Frågan är alltså inte om någon kan, utan vem som kan och om det syns.

Lagen ställer inte heller kravet att det ska vara omöjligt. Den ställer krav på spårbarhet:

• 5 kap. 5 §: rättas en bokföringspost ska det anges när rättelsen skedde och vem som gjorde den; sker rättelsen genom en särskild rättelsepost ska det samtidigt säkerställas att det vid en granskning av den rättade bokföringsposten utan svårighet går att få kännedom om rättelsen.
• 5 kap. 9 §: rättas en verifikation ska det anges när rättelsen skedde och vem som gjorde den. Kravet på rättelsepost i 5 kap. 5 § andra meningen gäller bokföringsposten, inte verifikationen — paragraferna är inte likalydande, och det ska den här sidan inte påstå.
• 5 kap. 11 §: företaget ska upprätta systemdokumentation och behandlingshistorik, så att de enskilda bokföringsposternas behandling går att följa och förstå.

Så här svarar programmet på var och en av dem:

• Rättelse sker som ändringsverifikat. Originalet vänds och det rätta bokförs, med en spårbar koppling mellan de två — precis det 5 kap. 5 § beskriver. Spärren ligger i databasen och gäller lika hårt för appen, ett API-anrop och SQL-editorn, eftersom alla tre ansluter som vanliga applikationsanvändare.
• Nummerserierna är obrutna. Verifikatnummer delas ut atomiskt i databasen. En bortplockad rad blir därför en lucka i serien — den syns.
• Den nattliga kopian är ett yttre facit. Kopiorna är daterade och ligger på ett annat system än bokföringen. Vill någon veta om något ändrats i efterhand jämför man med kopian från natten innan — den är hash-verifierad och skrevs innan ändringen fanns.

Och den ärliga bisatsen, som ska stå här och inte i en fotnot: den som har ägarrollen i din Postgres kan stänga av en spärr. Så ser det ut i varje bokföringsprogram som körs på egen infrastruktur. Skillnaden mot ett skydd som bara sitter i gränssnittet står ändå kvar: ett kringgående kräver ett medvetet ingrepp med ägarens behörighet, och det är precis den sortens handling revisorn, Skatteverket och bokföringsbrottet i 11 kap. 5 § brottsbalken redan är riktade mot.

Det här är kravet nästan ingen leverantör hjälper sin kund att uppfylla, och det träffar dig så fort programmet konterar något automatiskt:

Enkla bokföringssystem är dels system med manuell bokföring i form av en kolumndagbok, dels system i vilka bokföringen görs i ett standardiserat bokföringsprogram och övriga delar i systemet hanteras manuellt. Används automatkonteringar i bokföringsprogrammet anses bokföringssystemet inte vara enkelt.

Ett system som inte är enkelt ska ha en systemdokumentation enligt punkt 9.2 — kontoplan, beskrivning av hur kontona används, samlingsplan och arkivplan — och enligt punkt 9.9 ska den beskriva de behandlingsregler som automatiskt påverkar konto eller belopp i en bokföringspost. Punkt 9.12 lägger till en beskrivning av hur den elektroniska räkenskapsinformationen kan tas fram i en pappershandling.

Regelverket du läser just nu är den beskrivningen. Kontoplanen med varje kontos momskod, konteringen händelse för händelse, momsrutornas mappning, avskrivningsreglerna, filformaten och bokföringsmotorns garantier — publicerat, med rättskälla per rad och en länk in i koden som kör beräkningen. Vi publicerar den för att den ska gå att granska. Att den samtidigt är det underlag punkt 9.2 och 9.9 efterfrågar är en bonus värd att känna till.

Arkivplanen enligt punkt 8.3 — vad som arkiverats och var det förvaras — är den del du själv får skriva, eftersom bara du vet var din säkerhetskopia ligger. Uppsättningen ger dig svaret på båda frågorna. Punkt 8.3 kräver den om det behövs för att kunna överblicka den arkiverade räkenskapsinformationen; villkoret står i rådet och vi skriver inte bort det.

Det ärliga svaret är inte att självhostning är enklare. Det är att ansvaret ligger på samma ställe i båda modellerna, men att arbetet och beroendet ligger på olika ställen. Så här ser det ut, utan skönmålning:

Den sista raden är den enda där en abonnemangstjänst har ett övertag, och vi tänker inte låtsas något annat. Väger drift tyngre än ägande för dig är abonnemanget rätt val — då är det bättre att du vet det innan du köper än efter.

• Vi kan inte intyga att du inte har ändrat i din egen databas. Ingen leverantör kan intyga det om sin kund. En molnleverantör kan bara intyga att just deras applikation inte gjorde det — vilket är något annat, och mindre, än det som brukar läsas in i ordet.
• Vi lämnar inte juridisk rådgivning. Sidan citerar lagrummen så att du kan läsa dem själv och ta dem till din revisor eller redovisningskonsult. Bedömningen i ditt fall är deras och din.
• Vi ser inte om din säkerhetskopia slutar gå. Vi har ingen åtkomst till din installation. Programmet visar körningarna under Inställningar och räknar en misslyckad körning som utebliven — men larmet går till dig, inte till oss.
• Digital inlämning av årsredovisningen till Bolagsverket ingår inte. Den kräver en programvarulicens hos Bolagsverket som en självhostad installation inte har. Det står i bygglistan som planerat, inte som levererat, och det ska det fortsätta göra tills det stämmer.

Lagtexten på den här sidan är bokföringslagen (1999:1078) i lydelse enligt lag (2024:342) och Bokföringsnämndens allmänna råd BFNAR 2013:2 om bokföring i lydelse enligt BFNAR 2024:1. Hittar du ett fel — i citatet, i hänvisningen eller i slutsatsen — vill vi veta det.