När AI blir redovisningsbyrå
Programmen finns redan. Den svåra delen är att bygga ett system som kan bära bokföringens krav på bevis, kontroll och ansvar.
En AI kan läsa fakturor, föreslå konton och skriva rapporter. För att fungera som en svensk redovisningsbyrå måste den också förstå affärshändelser, hantera undantag, skydda kunddata och lämna ett revisionsspår. Här är systemen, kopplingarna och regelverket som krävs – och varför framtidens byrå snarare blir en kontrollerad produktionsapparat än en självgående chattbot.
Av Gunnar EklöfSkribent · Ekonomi och industriUppläst av tidningens berättarröst
1. En faktura är början – inte hela affärshändelsen
En leverantörsfaktura kommer till ett svenskt konsultbolag. Den avser ett års användning av en molntjänst, är utställd i euro och kommer från en leverantör i ett annat EU-land. Betalningen dras automatiskt från företagskortet. På kontoutdraget står betaltjänstens namn, inte leverantörens.
Detta är ett typexempel, inte ett dokumenterat kundfall. Men det visar varför AI som redovisningsbyrå är en svårare uppgift än att läsa siffror ur en PDF. Systemet måste avgöra vilket bolag som köpt tjänsten, vad tjänsten gäller, vilken momsbehandling som är relevant, om kostnaden ska periodiseras och vilken bank- eller korttransaktion som hör till fakturan. Det måste också undvika att bokföra både fakturan och kortbetalningen som varsin kostnad.
En språkmodell kan hjälpa till med flera av bedömningarna. Men en trovärdig redovisningsbyrå måste kunna visa varför de blev rätt.
Redovisning är därför en intressant prövning av AI-ekonomin. Underlagen är till stor del digitala, arbetsmomenten återkommer och många regler kan uttryckas i programkod. Samtidigt kan ett litet fel få följder i momsdeklaration, resultat, skatt och utdelningsutrymme. En nästan korrekt bokföring är inte nödvändigtvis en användbar bokföring.
Den praktiska ambitionen bör vara tydlig: AI ska utföra en växande andel av arbetet inom en kontrollerad tjänst. Den ska inte bli en självutnämnd auktoritet med fri tillgång till bokföring, bank och deklarationsinlämning.
AI kan föreslå hur en affärshändelse ska förstås. Ett hållbart system måste dessutom bevara underlaget, kontrollera beslutet och visa vem som godkände det.
Det finns ingen superintelligens som behöver uppfinnas för att börja. OCR, dokumenttolkning, språkmodeller, bankintegrationer, regelmotorer och etablerade ekonomiprogram räcker långt. Det som återstår är i hög grad integrationsarbete, processdesign och ansvarsfördelning.
För företagaren bör slutprodukten inte vara en ny chattruta att administrera. Den bör vara en tjänst som samlar in handlingar, ställer begripliga följdfrågor, håller tidsfrister och levererar avstämda siffror.
2. Programmen: ett ekonomisystem i botten, AI ovanpå
Den första arkitekturfrågan är var den officiella bokföringen ska ligga. För ett mindre svenskt företag är svaret normalt ett etablerat ekonomisystem, exempelvis Fortnox, Visma eEkonomi eller Björn Lundén. Större organisationer kan använda Microsoft Dynamics 365 Business Central, SAP eller Oracle. Produkternas API:er, licenser och automatiseringsmöjligheter skiljer sig och måste kontrolleras för den aktuella versionen.
Detta system bör vara huvudbok och register över bokförda transaktioner. En språkmodell ska inte hålla företagets saldo i sitt samtalsminne.
Ovanpå behövs ett insamlingslager. Det tar emot e-fakturor, kvitton, leverantörsfakturor, banktransaktioner, kortköp, försäljningsrapporter och löneunderlag. En strukturerad e-faktura är normalt lättare att behandla säkert än en skannad pappersfaktura: belopp, valuta och organisationsuppgifter kommer som data i stället för att först behöva läsas från en bild. Peppol är ett viktigt nätverk för standardiserat dokumentutbyte, men det täcker inte alla tänkbara underlag.
Nästa lager tolkar dokumenten. Azure AI Document Intelligence, Google Document AI och Amazon Textract är exempel på tjänster för dokumentextraktion. En multimodal språkmodell kan komplettera dem genom att förstå beskrivningar, identifiera oklarheter och formulera frågor. Valet beror på dokumenttyper, sekretesskrav, kostnad och faktisk träffsäkerhet i kundens material.
Därefter kommer en regelmotor. Den kontrollerar bland annat att debet och kredit balanserar, att perioden är öppen, att konton finns och att obligatoriska uppgifter inte saknas. Summor och momskalkyler ska beräknas med deterministisk kod, inte genom att modellen ombeds gissa rätt aritmetik.
Slutligen behövs ett arbetsflödessystem: en kö för sådant som kräver attest, komplettering eller expertbedömning. Där ska en människa kunna se dokumentet, förslaget, kontrollerna och skälet till att ärendet stoppades.
Tre lösningsvägar är realistiska. Den enklaste är att använda ekonomiprogrammets inbyggda automatisering och komplettera med mänsklig granskning. Den andra är att kombinera specialister som Medius för leverantörsfakturaflöden eller Pleo och Findity för utläggshantering, beroende på behov och tillgängliga integrationer. Sådana produkter löser delar av arbetet, inte automatiskt hela byråuppdraget.
Den tredje vägen är att bygga ett eget orkestreringslager ovanpå ekonomisystemet. Det ger kontroll över kunddialog, regler och arbetsfördelning, men innebär också att byrån blir mjukvaruoperatör. Den måste underhålla integrationer, hantera driftfel och testa varje modelländring.
För en liten byrå är den tredje vägen sällan billigast från början. För en större aktör med många likartade kunder kan den bli själva konkurrensfördelen.
3. Flödet från kundstart till bokförd verifikation
Automatiseringen börjar före den första fakturan. Vid kundstart måste byrån dokumentera bolagsform, verksamhet, räkenskapsår, momsregistrering, redovisningsmetod, rapporteringsperioder och vilka system som används. Den behöver veta om bolaget har lager, utlandsförsäljning, anställda eller ägartransaktioner.
Dessa uppgifter är kundens redovisningsprofil. De ska vara strukturerade, versionshanterade och godkända. Om verksamheten förändras måste profilen uppdateras. En konsultfirma som börjar sälja digitala tjänster till privatpersoner utomlands kan få helt andra momsfrågor än tidigare.
Ett robust löpande flöde har sju steg:
- Ta emot och registrera. Ge varje underlag ett internt ID, spara mottagningstid och bevara den version som faktiskt behandlades.
- Extrahera. Läs parter, fakturanummer, datum, rader, belopp, valuta och betalningsuppgifter. Markera saknade eller motstridiga värden.
- Kontrollera. Sök dubbletter, kontrollera summeringar och jämför med leverantörsregister, beställning eller tidigare underlag.
- Föreslå. Ange konto, momsbehandling, dimensioner och eventuell periodisering med en kort motivering.
- Pröva mot regler. Stoppa exempelvis okänd leverantör, ändrat bankkonto, orimlig moms eller bokföring i låst period.
- Godkänn och bokför. Låt tillåtna standardfall gå vidare enligt en fastställd policy. Skicka övriga till rätt granskare.
- Stäm av. Matcha betalning, kontrollera reskontra och följ upp återstående differenser.
AI-modellens egen uppgift om att den är ”99 procent säker” är inte ett tillräckligt beslutsunderlag. Sådana självskattningar behöver inte motsvara verklig felfrekvens. Tillit ska byggas på mätningar av historiska fall och konkreta signaler: känd motpart, stabil kontering, komplett underlag och godkända kontroller.
Belopp är bara en riskfaktor. En liten faktura kan avslöja ett ändrat bankkonto eller ett nytt gränsöverskridande skatteproblem. En stor återkommande hyresfaktura kan däremot vara enkel att behandla när avtalet är känt.
Kunddialogen är en central del av produktionen. I stället för ”komplettera verifikation 154” bör systemet fråga: ”Avser inköpet verksamheten eller privat användning?” Vid representation kan det efterfråga deltagare och syfte. Men frågan ska vara neutral; systemet får inte styra kunden mot ett svar som gör avdrag möjligt.
Avslutningen är lika viktig som inläsningen. Ett månadsbokslut kräver avstämning av bank, kundfordringar, leverantörsskulder, skattekonto och relevanta balansposter. Att alla dokument har fått ett konto betyder inte att redovisningen är komplett. Den saknade fakturan syns inte i dokumentkön.
4. API-kopplingarna: där byrån blir ett tekniskt system
Ett API är ett definierat sätt för program att läsa eller skriva data hos varandra. I en AI-byrå används det exempelvis för att hämta leverantörer, skapa fakturautkast eller läsa bokförda verifikationer. Fortnox har en offentlig utvecklarportal; andra ekonomisystem har egna gränssnitt och partnerupplägg.
Integrationen måste skilja på vad systemet får läsa och vad det får ändra. Åtkomst sker ofta med OAuth 2.0 och åtkomsttoken, men detaljerna varierar. Ge varje anslutning minsta nödvändiga behörighet. En funktion som analyserar kostnader behöver inte rätt att skapa betalningar.
En normal kedja kan se ut så här:
Fakturatjänst → dokumentlager → extraktion → kontrollmotor → attestkö → ekonomisystem → bankavstämning → rapportering.
Varje pil är en möjlig felpunkt. Nätverket kan brytas efter att en verifikation skapats men innan integrationsprogrammet fått svaret. Om programmet då försöker igen utan kontroll kan samma affärshändelse registreras två gånger.
Därför behövs idempotens: samma begäran ska inte orsaka dubbla resultat. Om mottagarens API saknar sådant stöd får integrationen hålla en egen transaktionsjournal och kontrollera externa referenser innan den gör om operationen.
Webhooks kan meddela att något har ändrats. Men en webhook bör behandlas som en signal, inte som ensam garanti för att alla data är kompletta. Systemet behöver återläsning, felkö och regelbunden avstämning mellan den egna journalen och ekonomiprogrammet. Det måste också hantera API:ernas anropsgränser och förändrade versioner.
Bankdata kräver särskild omsorg. Bankernas företagsintegrationer, filer och kontoinformationstjänster har olika täckning. PSD2 har möjliggjort reglerad tredjepartsåtkomst till betalkonton, men innebär inte att varje byrå fritt kan koppla sig till varje företagskonto. Att själv tillhandahålla kontoinformations- eller betalningsinitieringstjänster kan kräva registrering eller tillstånd. För många byråer är en etablerad bank- eller betalningspartner den rimliga vägen.
För betalningar bör befogenheterna delas. AI kan kontrollera förfallodatum och sammanställa ett betalningsförslag. Att ändra mottagaruppgifter och därefter godkänna överföringen bör inte ligga hos samma autonoma funktion.
SIE-filer är användbara för överföring av redovisningsdata mellan svenska system, men ersätter inte ett fullständigt arbetsflödes-API. Bilagor, attesthistorik och dokumentstatus följer inte nödvändigtvis med i samma omfattning.
Inte heller myndighetsrapporteringen är ett enda öppet API. Moms, arbetsgivardeklarationer, inkomstdeklarationer och årsredovisningar har skilda inlämningsvägar, format och behörighetskrav. En lösning måste verifiera varje deklarationskedja separat, inklusive vem som får lämna uppgifterna och vilket kvitto som bevisar att inlämningen lyckades.
5. Reglerna: AI avskaffar varken bokföringsskyldighet eller ansvar
Bokföringslagen är fundamentet. Den reglerar bland annat löpande bokföring, verifikationer, arkivering och avslutning av räkenskaper. Bokföringsnämndens normgivning konkretiserar god redovisningssed. Årsredovisningslagen och tillämpligt K-regelverk styr ytterligare delar av rapporteringen.
Det finns inget generellt krav på att en människa manuellt måste kontera varje rutintransaktion. Däremot måste resultatet uppfylla reglerna. Företagets bokföringsskyldighet försvinner inte när arbetet läggs ut på en byrå eller automatiseras. Styrelse, vd och andra företrädare har ansvar enligt tillämpliga regler; en byrå kan också ha eget avtalsrättsligt eller annat rättsligt ansvar för sitt agerande.
Bokföringslagen kräver att räkenskapsinformation bevaras till och med det sjunde året efter utgången av det kalenderår då räkenskapsåret avslutades. Ett räkenskapsår som slutar under 2025 innebär alltså normalt bevarande till och med 2032. Detta är något annat än att spara filen i sju år från uppladdningsdagen.
Sedan den 1 juli 2024 kan ett ursprungligt underlag förstöras efter överföring till annan form, exempelvis genom skanning, om lagens förutsättningar är uppfyllda. Överföringen får inte innebära risk för att räkenskapsinformationen förändras eller försvinner. Reformen avskaffade inte bevarandekravet.
Systemdokumentation och behandlingshistorik är också viktiga. I en AI-lösning bör det gå att följa underlag, tolkning, regelkontroll, godkännande och bokförd post. Ett redan bokfört fel ska rättas spårbart enligt reglerna, inte döljas genom att historiken skrivs om.
Moms är ett eget specialistområde. Svensk försäljning, EU-handel, import, omvänd betalningsskyldighet och begränsad avdragsrätt kan kräva olika behandling. Modellen bör slå upp information i en kontrollerad och uppdaterad kunskapsbas och använda versionsstyrda regler. Ett gammalt träningsminne är inte en tillräcklig rättskälla.
Yrkesmässiga bokföringstjänster omfattas dessutom normalt av penningtvättslagen. Det medför bland annat krav på allmän riskbedömning, kundkännedom, löpande uppföljning och rapportering av misstänkta aktiviteter när förutsättningarna är uppfyllda. En automatiserad kundstart måste därför kunna identifiera kunden, förstå ägarförhållanden och verklig huvudman samt bedöma uppdragets syfte och risk. En språkmodells sammanfattning ersätter inte dessa kontroller.
Auktorisation som redovisningskonsult är inte ett allmänt lagkrav för att bedriva redovisningsbyrå. Däremot är kompetens, kvalitetsarbete och ansvarsförsäkring viktiga för kundernas riskbedömning. Redovisning och lagstadgad revision är dessutom olika tjänster; en AI-byrå blir inte kvalificerad revisor genom att kunna granska siffror.
6. GDPR, AI-förordningen och säkerheten i praktiken
Bokföringsmaterial innehåller personuppgifter: namn, kontonummer, utlägg och ibland uppgifter som avslöjar hälsa eller facklig tillhörighet. Därför måste dataskyddet byggas in innan material skickas till en AI-leverantör.
Kunden är ofta personuppgiftsansvarig och byrån personuppgiftsbiträde för vissa behandlingar. Men rollerna måste bedömas per ändamål. Byrån kan vara självständigt personuppgiftsansvarig för exempelvis behandling som krävs för egna penningtvättsskyldigheter.
Det behövs biträdesavtal där det är relevant, kontroll över underbiträden, dokumenterade lagringstider och regler för överföring utanför EES. Att en molntjänst erbjuder en europeisk serverregion räcker inte ensamt som fullständig dataskyddsbedömning. Supportåtkomst och leverantörskedjor behöver också granskas.
Avtalen med AI-leverantören bör tydligt reglera om kunddata får användas för modellträning, hur länge anrop och svar sparas samt hur radering och incidenthantering fungerar. Skicka helst bara den information som behövs för uppgiften. En fråga om kontering kräver sällan att hela kundens lönearkiv bifogas.
GDPR:s rätt till radering upphäver inte lagstadgad arkivering. Däremot betyder bokföringens bevarandekrav inte att varje kopia i en felsökningslogg måste sparas lika länge. Originalmaterial, behandlingshistorik och tillfälliga modellspår behöver separata lagringsregler.
EU:s AI-förordning införs stegvis. Kravet på åtgärder för tillräcklig AI-kunnighet började tillämpas den 2 februari 2025. Huvuddelen av förordningen börjar enligt den antagna förordningens tidsplan tillämpas den 2 augusti 2026, med särskilda tidsplaner för vissa bestämmelser. Vanlig bokföringsautomation är inte automatiskt ett högrisksystem; klassificeringen beror på användningsområdet. Om samma teknik används för exempelvis vissa personalbeslut eller kreditvärdighetsbedömningar av fysiska personer kan andra regler aktualiseras.
Säkerheten måste också hantera en ny sorts angrepp. En faktura kan innehålla text som försöker instruera modellen att ignorera regler eller byta betalningsmottagare. Det kallas promptinjektion. Dokument ska därför behandlas som underlag, inte som instruktioner till systemet.
Praktiskt innebär det isolering mellan kunder, kryptering, åtkomstloggar, säkert hanterade API-nycklar och tillåtna åtgärder som kontrolleras utanför språkmodellen. Säkerhetskopiering måste kompletteras med återläsningstester. En backup som ingen kan återställa är ingen fungerande kontinuitetsplan.
7. Affären: besparingen finns i undantagen, inte bara i avläsningen
Det ekonomiska argumentet är enkelt: om mer av standardarbetet automatiseras kan samma personal hantera fler kunder. Men kalkylen måste inkludera integrationer, granskning, support och felkostnader.
Anta, enbart som räkneexempel, en byrå med 100 kunder och 200 underlag per kund och månad. Det blir 20 000 underlag. Vid tre minuters handläggning per underlag motsvarar det 1 000 timmar. Om 80 procent kan behandlas utan manuell handläggning och återstående 20 procent kräver fem minuter vardera blir undantagsarbetet cirka 333 timmar.
Den teoretiska skillnaden är omkring 667 timmar per månad. Men från detta måste man räkna bort kvalitetskontroll, kundfrågor, teknisk drift och sådant som aldrig ingick i underlagshanteringen: bokslut, rådgivning och svårare skattebedömningar. Exemplet är inte ett belägg för en viss besparing i verkliga byråer.
Den viktigaste kostnadsdrivaren är ofta undantagsandelen. En standardiserad tjänstekund med digitala fakturor är en annan affär än ett företag med kontanthantering, lager, flera valutor och bristfälliga underlag. Därför kan kvaliteten på kundens processer vara viktigare än valet mellan två språkmodeller.
Prissättningen kan följaktligen behöva röra sig från timmar till grundavgift, volym och komplexitet. Men fasta priser flyttar risken till byrån. Om ett kundsystem ändrar API eller en ny affärsmodell skapar många manuella frågor kan marginalen försvinna.
Mät därför mer än antalet automatiskt bokförda dokument. Följ andelen korrekta automatiska beslut, rättelser per period, tid till avstämd månad, saknade underlag och kostnad per färdigställt kunduppdrag. Ett system som skapar utkast snabbt men lämnar månader av avstämningsarbete efter sig har inte effektiviserat byrån.
Testmaterialet måste också vara representativt. Årsbokslut, kreditfakturor, valutadifferenser och ändrade leverantörsuppgifter får inte försvinna ur utvärderingen bara för att rutinfallen är fler. Det är ofta i de ovanliga fallen som den ekonomiska risken ligger.
8. Så bygger man en AI-byrå som kan tas i drift
En rimlig införandeplan börjar med en avgränsad kundgrupp och ett fåtal flöden. Välj exempelvis svenska tjänsteföretag med digitala underlag och begränsad internationell handel. Att börja med alla branscher samtidigt gör både regler och testning onödigt svåra.
Först behövs en tjänstebeskrivning: vad ingår, vem lämnar underlag, vem attesterar, vem godkänner deklarationer och vad händer när kunden inte svarar? Avtalet bör också reglera rättelser, incidenter, systembyte och hur kunden får ut sin information om samarbetet upphör.
Därefter byggs integrationerna och ett testbibliotek med kända korrekta utfall. Kör systemet i skuggläge: låt det föreslå utan att bokföra och jämför med kvalificerade bedömningar. Oenighet ska analyseras, inte automatiskt räknas som att människan eller modellen har rätt.
Nästa steg är begränsad automation för tydliga standardfall. Håll betalningsgodkännanden och komplicerade bedömningar utanför. Utöka först när uppmätt kvalitet, avstämningar och incidenthantering håller. Det finns ingen universell procentsats som gör ett system säkert; toleransen måste kopplas till felets konsekvens.
Modellbyten ska behandlas som produktionsförändringar. En ny version kan bli bättre på text men sämre på en viss fakturamall. Testa återkommande fall igen, behåll versionsinformation och ha möjlighet att gå tillbaka till föregående fungerande lösning.
Till sist behövs människor med mandat. Någon ska äga redovisningspolicyn, någon integrationernas drift och någon kundens öppna frågor. I en liten byrå kan samma person bära flera roller, men rollerna får inte försvinna i föreställningen att AI ”tar hand om det”.
Den mest realistiska AI-byrån är därför en kombination: etablerat ekonomisystem, strukturerade data, deterministiska kontroller, språkmodell och kvalificerad ansvarskedja. Den kan bli betydligt mer produktiv än traditionell manuell hantering. Men dess verkliga produkt är inte konteringsförslag. Det är en avstämd, begriplig och spårbar ekonomisk verklighetsbild som företagaren kan fatta beslut utifrån.
Källor
- Sveriges riksdag, Bokföringslag (1999:1078) (1999, med senare ändringar)
- Bokföringsnämnden, Bokföring – vägledning till BFNAR 2013:2 (2013, med senare uppdateringar)
- Fortnox, Fortnox Developer (Löpande dokumentation)
- Skatteverket, Moms (Löpande vägledning)
- Sveriges riksdag, Lag (2017:630) om åtgärder mot penningtvätt och finansiering av terrorism (2017, med senare ändringar)
- Europeiska unionen, Europaparlamentets och rådets förordning (EU) 2016/679 (2016)
- Europeiska unionen, Europaparlamentets och rådets förordning (EU) 2024/1689 (2024)
- Europeiska unionen, Europaparlamentets och rådets direktiv (EU) 2015/2366 (2015)
Ställ frågor om "När AI blir redovisningsbyrå". Svaren bygger på tidningens egna artiklar.
