Stämmer utbetalningarna? Automatisera avstämningen

Blocket, Klarna eller Tradera sätter in en klumpsumma på kontot. Ingenstans står det vilka ordrar pengarna gäller, vad plattformen dragit i avgifter, eller om en försäljning saknas helt. Att kontrollera det för hand tar timmar, så de flesta gör det aldrig – och missade pengar förblir missade. Den här guiden visar hur AI gör kontrollen åt dig: varje order matchas mot varje utbetalning, varje avvikelse flaggas, och du godkänner innan bokslutet stängs.

Arbetsfördelningen genom hela guiden är enkel: du exporterar tre filer, AI-agenten gör steg 1 till 6, och du fattar besluten i steg 7. Du läser alltså för att förstå vad som händer under huven, inte för att sitta med filerna själv.

Varför landar utbetalningen inte på samma summa som försäljningen?

Utbetalningen skiljer sig från försäljningen eftersom tre olika källor beskriver samma affär på tre olika sätt: plattformens orderexport, din egen orderkälla och plattformens utbetalningsrapport. Var och en har sitt eget format, sin egen ordernyckel och sina egna avdrag. Manuell avstämning mellan dem tar timmar varje månad och missar ändå avvikelser en människa inte hinner se.

Är du ny på AI-agenter, läs först vår genomgång av AI-agenter för svenska företag. Var avstämningen hör hemma bland de andra e-handelsflödena ser du i vår artikel om AI-agenter för e-handel.

I praktiken ser det ofta ut så här: en order har ett ordernummer du satt själv, till exempel i Shopify eller WooCommerce. Betalleverantören, som Klarna eller Stripe, sätter i stället ett eget referensnummer på affären, och i utbetalningsrapporten kan samma order ligga utspridd på flera transaktionsrader. Säljer du även via Blocket eller Tradera upprepas mönstret där, fast med ett tredje namn på samma order. Formaten beskriver bara samma sak på var sitt språk.

Vad behöver du innan du börjar?

Du behöver tre datakällor per plattform: orderexporten, din egen orderkälla och utbetalningsrapporten i CSV eller PDF. Utan alla tre går varken matchning eller nettoberäkning att göra, eftersom varje källa bara visar en del av bilden.

Är ordrarna redan samlade på ett ställe, som vi går igenom i guiden om att automatisera orderhanteringen, är halva jobbet redan gjort: den interna orderkällan finns och uppdateras löpande i stället för att jagas ihop i efterhand.

Har du flera kanaler, till exempel en egen webbshop, Blocket och Tradera, körs hela protokollet nedan per plattform och samlas till slut i en enda mastertabell. Tre källor gånger tre plattformar blir nio filer i en fullständig månadsrevision, inte tre – varje plattform har sitt eget format, sin egen utbetalningstakt och sina egna undantag.

Steg 1: Hur samlar du in de tre källorna?

Först läses varje fil in och profileras: vilka kolumner den har, vilka datatyper, vilka fält som kan funka som ID, och i vilken enhet beloppen står. Det tar tid nu. Vinsten kommer senare: när resten av protokollet byggs vet du redan exakt vad varje källa innehåller.

Tre filer, tre format

I praktiken skiljer sig filerna åt på nästan varje punkt:

• Plattformens orderexport har ofta ett referensnummer som inte liknar ditt eget ordernummer.
• Den interna orderkällan har rätt ordernummer men saknar plattformens interna transaktions-ID.
• Utbetalningsrapporten radar upp transaktioner, inte ordrar, ibland flera rader per order.

Profileringen avslöjar också beloppsenheten. En del plattformar redovisar i minor units, där 229000 betyder 2 290,00 kronor, alltså en division med 100 innan något annat räknas.

Varför den interna källan måste vara radvis

Skatteverket kräver att varje försäljning bokförs för sig, inte bara som en nettosumma från en betaltjänst. Det är en anledning till att den interna orderkällan måste vara radvis per order redan från start, annars finns inget att stämma av mastertabellens rader mot i steg 4.

Sitter uppgiften om moms, frakt och rabatt i olika kolumner i den interna källan men slås ihop till en summa hos plattformen, är det den interna filen som bär den detaljnivå du senare behöver för att förklara en avvikelse.

Samma profilering avgör också vilka fält som duger som ID-kandidat. Ett ordernummer som återanvänds mellan år, eller ett kundnamn som stavas olika i två system, ser ut som en nyckel men håller inte i praktiken.

Steg 2: Hur skapar du en gemensam ordernyckel?

Nu byggs en gemensam ordernyckel som fungerar i alla tre källor, oavsett hur olika de ser ut från början. Nyckeln normaliseras, till exempel genom att strippa prefix och nollor, och testas sedan mot en verklig matchningsgrad innan du går vidare.

En vanlig lösning är att låta det interna ordernumret vara facit och bygga en översättningstabell mot plattformens referenskolumn och utbetalningens transaktions-ID. Tabellen byggs en gång per plattform och återanvänds sedan varje månad, så att arbetet inte görs om från noll.

Matchningsgraden är det första kvittot på om nyckeln håller. Ligger den nära hundra procent redan efter första testet vet du att normaliseringen fångat rätt fält. Ligger den lägre är det oftast ett tecken på att ett prefix, en bindestrecksvariant eller en gammal ordertyp inte normaliserats bort ännu.

Exempel från en riktig månadsrevision: hos vår kund Telestore, som säljer begagnade telefoner via telestore.se, Blocket och Tradera, heter samma order "WGR12345" internt men ligger under plattformens eget referensnummer i orderexporten, och hos nästa kanal heter motsvarande order i stället "#10123". En översättningstabell byggd en gång per kanal löste matchningen.

Steg 3: Hur normaliserar du beloppen?

Härnäst normaliseras alla belopp till en gemensam SEK-standard, utbetalningsrader grupperas per order och nettobeloppet räknas ut: försäljning minus avgift minus retur. Utan det steget går siffror i olika format och olika valutaskrivning aldrig att jämföra rakt av.

Minor units och separerade rader

En vanlig utmaning när du stämmer av flera kanaler är att en plattform delar upp utbetalningen i separata SALE-, FEE- och RETURN-rader per order, i stället för en enda summa. Settlementet, plattformens ord för själva utbetalningen, blir då försäljning minus avgifter minus returer minus eventuell skatt, och alla rader måste grupperas till samma order innan nettot går att räkna.

Klarnas egen dokumentation för settlement-rapporter visar samma princip från en etablerad utbetalningsleverantör: varje betalning bryts ner i transaktionsrader som tillsammans förklarar hur summan på kontot blev vad den blev.

Exempel från en riktig månadsrevision: en av Telestores tre kanaler redovisar i exakt det minor units-format som steg 1 beskrev, och delar samtidigt upp varje order i separata SALE-, FEE- och RETURN-rader. Utan divisionen med 100 och grupperingen till samma ordernyckel hade nettot sett ut att avvika från både orderlistan och utbetalningen, trots att allt stämde.

Tusentalsavgränsare och direktavdrag

En annan vanlig variant redovisar i engelskt talformat med tusentalsavgränsare, till exempel "5,499.00", och drar plattformens kommission direkt innan utbetalning: utbetalt blir brutto minus kommission, ofta med en månadssummering i PDF i stället för radvis CSV. Exakt kommissionssats varierar mellan plattformar och avtal, så den siffran får din egen utbetalningsrapport ge dig.

Steg 4: Hur bygger du mastertabellen?

Allt samlas sedan i en mastertabell: en rad per unik ordernyckel, med en flagga för om ordern finns hos varje källa, beloppet från var och en, och matchningsflaggor med noteringar.

En rad kan se ut så här i praktiken: ordernyckeln, finns_internt (ja/nej), finns_hos_plattformen (ja/nej), finns_i_utbetalningen (ja/nej), beloppet från vardera källa, och en kolumn med matchningsstatus: grön för fullständig match, gul för beloppsavvikelse, röd för att ordern helt saknas i en källa.

Det här är också den fil du sparar. Varje månad exporteras mastertabellen som CSV, tillsammans med de sex avvikelselistorna och en revisionsrapport i Markdown och Excel, så att den går att öppna, granska och arkivera utan att någon behöver fråga hur den byggdes.

En mastertabell som bara visar "matchar" eller "matchar inte" räcker inte. Den måste visa exakt vilken källa som avviker och med vilket belopp, annars flyttar du bara problemet ett steg och kallar det löst.

Fördelen mot att jämföra tre kalkylark manuellt är att mastertabellen är sökbar och filtrerbar. Vill du se alla ordrar över ett visst belopp som saknar match, eller alla avvikelser från en specifik vecka, är det ett filter, inte en eftermiddag med tre öppna Excel-flikar bredvid varandra.

Steg 5: Vilka avvikelselistor ska AI:n ta fram?

Ur mastertabellen tar AI:n sedan fram sex avvikelselistor – en för varje typ av glapp som kan uppstå mellan de tre källorna. Varje lista är en färdig arbetslista för en människa, inte råmaterial.

De sex listorna, var för sig:

1. Finns internt men saknas hos plattformen, ofta ett tecken på att en order aldrig synkats över huvud taget.
2. Finns hos plattformen men saknas internt, vanligt vid manuella ordrar eller ett integrationsfel som tystnat.
3. Finns i orderlistorna men saknas i utbetalningen, till exempel en order som väntar på nästa utbetalningsperiod.
4. Finns i utbetalningen men saknas i orderlistorna, den typ av avvikelse som lättast göms i en stor fil.
5. Beloppsdifferenser, där ordern finns överallt men summan inte stämmer mellan källorna.
6. Avbrutna eller returnerade ordrar, som behöver en egen kontroll eftersom de påverkar nettot i flera led samtidigt.

En retur som dras i utbetalningen som en RETURN-rad, men aldrig registreras som retur internt, hamnar i just den fjärde listan: finns i utbetalningen men saknas i orderlistorna.

Exempel från en riktig månadsrevision: det här är exakt den sortens fynd Telestores månadsrevision är byggd för att fånga. En retur som plattformen redan dragit av men som inte registrerats internt fastnar i lista fyra och utreds före bokslut, i stället för att dyka upp månader senare som en oförklarad differens.

Hur en retur registreras korrekt från början, med rätt kontroll mot ångerrätt och öppet köp, går vi igenom i guiden till AI-returhantering med human in the loop.

Steg 6: Hur verifierar du plattformens totalsummor?

Sista räknekontrollen gäller plattformens egna totalsummor: summera transaktionsraderna själv och jämför mot plattformens summering, samtidigt som settlement-formeln verifieras rad för rad. Ett fel i summeringslogiken syns annars aldrig i en enskild order, bara i helheten.

Bokio beskriver samma princip för bankavstämning: stämmer summan i bokföringen mot saldot på kontot, är sannolikheten hög att resten också stämmer. Vänder man på ordningen och bara litar på plattformens egen summa riskerar man att ärva ett fel man aldrig själv upptäckt.

FAR:s vägledning till BFNAR 2013:2 slår fast att bokföringen ska stämmas av löpande enligt fasta rutiner, där frekvensen anpassas efter det enskilda företagets förhållanden. För en e-handel med daglig försäljning på flera kanaler landar den bedömningen nästan alltid på månadsvis, eller tätare.

Att automatisera avstämningen förändrar inte den bedömningen, men den sänker priset för att göra den ofta. Bokio radar upp samma poäng i sin genomgång av varför avstämning bör göras regelbundet: ett fel som upptäcks efter en månad är billigt att rätta, samma fel efter ett år kan kräva konsulttimmar för att nysta upp.

Steg 7: Var kommer människan in?

Sist kommer kontrollkedjan: AI föreslår och flaggar, människan godkänner. En ren match blir grön och kräver inget beslut. Varje avvikelse kräver ett mänskligt beslut innan bokslutet stängs, och AI:n bokför aldrig något på egen hand.

I praktiken betyder det att systemet aldrig skriver en rättelse i bokföringen. Det lägger fram underlaget och väntar på ett godkännande eller en instruktion. Själva körningen tar minuter. Människans jobb är att gå igenom avvikelselistorna, inte att leta efter dem. Bokföringslagen (1999:1078) lägger bokföringsansvaret på bolaget, inte på ett verktyg, och den ansvarsfördelningen ska synas i hur systemet är byggt, inte bara i ett avtal.

Det är kärnan i att automatisera avstämningen utan att ge upp kontrollen: maskinen gör det tröttsamma arbetet med att läsa nio filer och jämföra dem rad för rad. Människan gör det enda AI:n aldrig ska göra: ta ansvar för siffran som till slut bokförs.

Vilken tech stack behöver du?

En automatiserad avstämning byggs på tre lager: ett skriptlager som tuggar filerna, en AI-agent som förstår dem och en schemaläggning som ser till att det faktiskt händer varje månad.

Tre lager, del för del

• Python och pandas läser in filerna, normaliserar ordernycklar och belopp, och bygger mastertabellen samt de sex avvikelselistorna. Det är samma verktyg oavsett om källan är en Excel-export, en CSV eller en PDF-tabell som först behöver läsas ut.
• En AI-agent, till exempel byggd på Claude eller en annan stor språkmodell, profilerar nya filformat automatiskt, skriver revisionsrapportens sammanfattning i klarspråk, och flaggar vilka avvikelser som ser ovanliga ut jämfört med tidigare månader.
• Schemaläggning kör hela kedjan månadsvis, från insamling till färdig rapport.

Resultatet varje månad är detsamma oavsett verktyg, klart att skicka vidare till den som ansvarar för bokslutet – oavsett om det landar i Fortnox, Visma eller ett annat bokföringsprogram. Vad ett sådant bygge brukar kosta, och när det lönar sig för just din volym, finns i kostnadsguiden för AI-agenter och i vår besparingskalkylator.

Ingen av de tre delarna kräver att du river upp något befintligt. Python och pandas körs mot filerna du redan exporterar, AI-agenten läggs till som ett skript i samma flöde, och schemaläggningen är en cron-rad, inte ett nytt system att lära ut till hela teamet. Det är samma pragmatiska princip som styr resten av det vi bygger: automatisera avstämningen ovanpå det som redan fungerar.

Vanliga frågor