Kundcase 004
Ett AI-system för flera bolags ekonomi
Vi byggde ett system som samlar underlag, matchar rutintransaktioner och skickar avvikelser till ekonomi före bokslutet.
- Kund
- Verksamhet med flera bolag
- System
- Löpande avstämning
- Typ
- Kundcase
- Publicerad
- 20 juli 2026
Det vi byggde
Daglig avstämning med ekonomi i kontroll.
Systemet samlar underlag, kör exakta kontroller, föreslår kontering och förbereder avvikelser. Ovanliga eller otillräckligt styrkta poster går till en namngiven ansvarig.
Ekonomiteamet hittade saknade underlag och olösta transaktioner i slutet av varje månad, precis när det fanns som minst tid.
01 / Varför bokslutet tar tid
Saknat underlag gör bokslutet långsamt.
Teamet arbetade över bankflöden, företagskort, fakturainkorgar, inköpsorder, avtal och redovisningssystem. Informationen fanns oftast, men var spridd mellan system och människor.
Bokslutet blev därför ett rekonstruktionsarbete. Ekonomi letade kvitton, frågade vem som godkänt en leverantör, kontrollerade vilket bolag som ägde kostnaden och rättade dubbletter när sammanhanget redan hunnit bli gammalt.
Modeller kan läsa stökiga dokument och föreslå kontering. Exakta bokföringskontroller behövs ändå. Ett rimligt förslag kan fortfarande vara kopplat till fel underlag.
02 / Första bygget
Vi började med en typ av transaktion.
Bolagsgruppen hade flera juridiska enheter, bankkonton, kortprogram, valutor och godkännanderegler. Första versionen hanterade faktura- och banktransaktionsmatchning för ett bolag.
Version 01
Matchning av fakturor och banktransaktioner för ett bolag.
- Indata
- En fakturainkorg och ett bankflöde
- Sammanhang
- Leverantörsregister, kontoplan och inköpsorder
- Resultat
- Ett länkat konteringsförslag eller ett komplett avvikelseunderlag
- Gräns
- Inga betalningar, bankändringar eller ej godkända skrivningar
Avgränsningen var tillräckligt liten för att testa och tillräckligt viktig för att göra skillnad. Samtidigt byggde den grunden för källidentitet, underlagslänkar, regler, godkännanden och en pålitlig granskningslogg.
03 / Så fungerar det
Varje post gick genom samma kontroller.
Redovisningssystemet låg kvar. Varje förslag följde samma steg, oavsett om det började som en ren faktura eller en rörig bilaga.
- 01
Samla
Läs fakturainkorg, bankflöde, inköpsorder, leverantörsregister och kontoplan.
- 02
Koppla
Spara varje förslag med källa, bolag, leverantör, period och godkännandehistorik.
- 03
Kontrollera
Använd fasta regler för summor, dubbletter, moms, kontostatus, beloppsgränser och balanserade verifikat.
- 04
Föreslå
Låt modellen föreslå kontering, förklara ovanliga poster och sammanfatta avvikelser.
- 05
Skicka
Skicka posten till rätt person utifrån värde, risk, bolagsregler och saknat underlag.
- 06
Bokför
Använd ett begränsat konto för att bokföra den godkända posten och registrera vem som godkände den.
Underlagsposten blev systemets centrum. Ett förslag gick till granskning först när det hade källänk, bolag, regelresultat och beslutshistorik.
04 / Vem beslutar
Assistenten förbereder. Ekonomi beslutar.
Det är olika jobb. Modellen får inte godkänna sitt eget förslag. Kontot som läser fakturor ska inte också styra betalningar eller huvudbok.
Läser fält, hittar troliga matchningar, föreslår kontering, förklarar avvikelser och bygger granskningsunderlaget.
Räknar om belopp, stoppar dubbletter, tillämpar toleranser, kontrollerar underlag och blockerar ogiltiga perioder.
Äger ovanlig kontering, manuella verifikat, skattefrågor, bankändringar, betalningar och policyundantag.
Den första versionen tog bort manuella sökningar, förberedde varje beslut och hade rätt att utföra mycket få handlingar.
05 / Testning
Testa felen som faktiskt spelar roll.
Vi byggde en referensmängd med historiska transaktioner och godkända underlag, konteringar och beslut. En hel period hölls utanför utvecklingen och användes för sluttest med saknade dokument, dubbletter, motstridiga belopp och fel bolag.
Underlag
Kopplade systemet rätt faktura, transaktion, order och bolag?
Kontering
Var förslaget på konto, moms, kostnadsställe och motpart korrekt?
Kontroll
Släpptes någon post igenom trots krav på granskning eller mer underlag?
Routing
Kom avvikelsen till rätt person med nog sammanhang för ett beslut?
Rättning
Hur ofta ändrade ekonomi ett godkänt förslag efter bokföring?
Det viktigaste säkerhetsmåttet var falskt godkännande: en post som systemet släppte igenom trots att den borde ha stoppats.
06 / Behörighet
Varje agent fick en egen identitet.
Varje handling blev spårbar eftersom agenternas behörigheter var separata och begränsade.
- Separata identiteter för läsning, förslag, godkännande och skrivning
- Åtkomst begränsad efter bolag, konto, handling och miljö
- Mänskligt godkännande för betalningar, bankuppgifter, skatt och ovanliga verifikat
- Källor, regelresultat, modellversion, verktygsanrop, godkännanden och skrivningar loggade
- Omedelbar återkallning av åtkomst och spårbara rättningar
- E-post och bilagor behandlade som opålitlig indata
Granskaren såg underlaget, den föreslagna posten, godkända kontroller och orsaken till att ärendet nådde dem.
07 / Införande
Vi började skrivskyddat och lade till skrivning senare.
Innan systemet fick ändra huvudboken behövde det visa att det kunde samla rätt underlag och stanna vid rätt gräns.
- 01
Följde en transaktion
Dokumenterade underlag, godkännande, bokföring och rättningar.
- 02
Anslöt skrivskyddat
Läste en fakturainkorg, ett bankflöde och redovisningen för ett bolag.
- 03
Lade till fasta kontroller
Byggde exakt matchning, dubblettkontroll, gränser och underlagsregler före modellen.
- 04
Lade till förslag
Föreslog kontering och sammanfattade avvikelser med länk till varje källa.
- 05
Körde utan bokföring
Jämförde förslagen med ekonomiteamets beslut medan huvudboken var skrivskyddad.
- 06
Tillät godkända poster
Gav ett begränsat konto rätt att bokföra först efter godkännande.
Varje utökning blev en ny version. Ett andra bolag, en ny valuta eller en ny skrivbehörighet ändrade risken och fick egna tester.
08 / Mätning
Vi mätte om böckerna var redo.
Vi följde saknat underlag, godkända matchningar, väntande avvikelser och rättade poster under hela månaden.
Komplett underlag före granskning
Rutinposter matchade utan manuell sökning
Första konteringsförslaget godkänt av ekonomi
Avvikelser som väntar längre än avtalad tid
Poster ändrade efter godkännande eller bokföring
Konton redo för granskning före bokslut
Vid månadsslutet granskade ekonomiteamet förberedda avvikelser i stället för att börja med en hög med saknade underlag.
Vanliga frågor
Korta svar.
Kan AI stänga böckerna automatiskt?
Dagens system kan samla underlag, föreslå matchningar och förklara avvikelser. Ekonomiteamet bör fortfarande godkänna ovanliga poster, skatt, bankändringar och betalningar.
Vad bör automatiseras först?
Välj en vanlig transaktionstyp med tydliga regler, bra underlag och en besvärlig manuell kö. Matchning mellan faktura och transaktion är ofta en bättre första version än bred autonom redovisning.
Ersätter detta affärs- eller redovisningssystemet?
Nej. Redovisningssystemet förblir källan till sanningen. Det här lagret samlar underlag och förbereder poster för godkännande.
Hur bör godkännanden fungera?
Godkännandet bör följa konsekvensen. Exakta matchningar med låga belopp kan passera enligt en tydlig policy. Ovanlig kontering, verifikat, skatt, bankändringar, betalningar och saknat underlag ska alltid gå till en kvalificerad person.
Källor
Källor bakom kontrollerna.
- FinBalance: A benchmark for multi-document accounting reconciliationEtt test från juni 2026 som visar varför rimliga poster inte räcker när underlag och slutbalanser måste bli exakta.
- NIST: Identity and authorization for software agentsVägledning om agentidentitet, delegerad behörighet, spårbarhet och ansvar.
- Anthropic: Demystifying evals for AI agentsEn praktisk modell för deterministisk, modellbaserad och mänsklig utvärdering.
- OpenAI: Workspace agentsExempel på avgränsade anslutningar, förslag och godkännande före känsliga handlingar.
- NIST: AI Risk Management FrameworkStruktur för att kartlägga, mäta, hantera och styra AI-risk över tid.