Bokföring med Make och n8n: tre recept som faktiskt funkar

TL;DRMake och n8n är rätt nivå mellan 'chatta med Claude' och 'bygg en custom integration'. Tre konkreta recept: Stripe-försäljning, avgifter och utbetalningar bokförda rätt, leverantörsfaktura från inkorgen, daglig runway till Slack. Webhooks vs polling, vanliga fel, och varför du inte ska försöka göra allt på en gång.

Du behöver inte välja mellan "bokföra manuellt" och "bygga en egen integration". Den intressanta nivån ligger emellan: Make och n8n. Drag-and-drop-verktyg som tar emot webhooks, anropar accounteds REST-API och kör flöden du designar utan att skriva kod.

Det här är tre recept som funkar mot API:t som det ser ut idag. Endpoints, fält och konton är kontrollerade mot koden.

När Make/n8n är rätt nivå

Tre alternativ för att automatisera bokföring:

Nivå	Verktyg	Bra för
Chatt	Claude/ChatGPT via MCP	On-demand uppgifter, undersökning, månadsstängning
Low-code	Make, n8n	Schemalagda flöden, event-baserat, integration mellan SaaS
Custom	Egen kod mot REST/MCP	Komplex logik, hög volym, specifika krav

Make/n8n är där du landar om du vill ha "när X händer i system A, gör Y i accounted" utan att anlita en utvecklare. Du designar flödet, det körs på schema eller vid webhook, och du har en körlogg i båda verktygen.

ChatGPT, Claude och din ledger visar chatt-nivån. Den här artikeln handlar om Make/n8n-nivån.

Recept 1: Stripe-försäljning, avgifter och utbetalningar

Det frestande flödet är att vänta på Stripes utbetalning och bokföra allt på en gång: intäkt, avgift och bank i en verifikation. Det är fel, och en tidigare version av den här artikeln visade just det. Stripe ger dig tre olika affärshändelser med tre olika underlag: försäljningen (ditt kvitto eller din faktura till kunden), avgifterna (Stripes månadsfaktura till dig) och utbetalningen (pengar som flyttas mellan två av bolagets egna konton). De bokförs var för sig, och utbetalningen kan beroende på dina Stripe-inställningar komma varje dag eller en gång i månaden.

Så här ser det ut när det är rätt:

Händelse	Datum	Underlag	Debet	Kredit
Försäljning via Stripe	Försäljningsdagen	Ditt kvitto eller din faktura	1686 Stripe-saldot	30xx Försäljning + 26xx Utgående moms
Stripes avgifter	Månaden fakturan avser	Stripes månadsfaktura	6570 Bankkostnader (kortavgift), annat kostnadskonto + 2645 (övriga Stripe-tjänster)	1686 + 2614
Utbetalning till banken	Dagen pengarna landar	Utbetalningen i Stripe och på kontoutdraget	1930 Företagskonto	1686

Fyra regler bär upp tabellen:

1. Stripe-saldot är ett eget konto. Behandla det som ett bankkonto och använd kontot bara för Stripe. BAS har inget konto som heter Stripe. Vanligast är 1686 Fordringar för kontokort och kuponger (BAS 2026, äldre kontoplaner använder 1580), och det är det konto Stripe-kopplingen i accounted lägger upp. Tar du bara emot till exempel Klarna och Swish via Stripe, och inga kort, passar 1684 Kortfristiga fordringar hos leverantörer bättre: fordran har då inget med kort att göra, den är på Stripe som leverantör av betaltjänsten. Båda hamnar på samma rad i balansräkningen. Välj ett och håll fast vid det.

2. Försäljningen bokförs på försäljningsdagen, med ditt eget underlag. Verifikationen innehåller försäljningen och momsen, inget annat. Underlaget är det du gav kunden: kvittot eller fakturan som visar vad som såldes. Det går att göra en verifikation per betalning eller en samlingsverifikation per dag. Bokföringsnämnden tillåter att likartade affärshändelser samma dag bokförs i sammandrag, så länge det utan svårighet går att se vilka affärshändelser som ingår (BFNAR 2013:2). Underlaget för sammandraget är då dagens kvitton, eller en lista över dem med vad som såldes. Stripes avgift hör inte hemma här: underlaget ska stämma med innehållet i verifikationen, och ditt kvitto till kunden säger ingenting om vad Stripe tog betalt av dig.

3. Avgifterna bokförs från Stripes månadsfaktura. Tänk på den som en elräkning. Stripe drar avgifterna från saldot under hela månaden, och i början av nästa månad kommer fakturan (tax invoice, under Documents i Stripes dashboard) som specificerar alla avgifter per produkt. Den är underlaget, och den bokförs i den månad den avser: julifakturan bokförs i juli även om den kommer i augusti. Avgifterna har olika moms:

   • Kortavgiften, alltså procentsatsen Stripe drar per betalning, är en betaltjänst. Skatteverket anser att kortinlösarens avgift till betalningsmottagaren är undantagen från moms (ställningstagande 2022-01-28, dnr 8-1422447). Den bokas på 6570 utan moms.
   • Stripes andra produkter, till exempel Billing, Invoicing (fakturor som betalas i efterhand), Tax och Radar, är inga betaltjänster. De köps från Stripes irländska bolag och redovisas med omvänd skattskyldighet: ruta 21 för inköpet, ruta 30 och 48 för momsen.

   Är du osäker på en rad, fråga din revisor innan du automatiserar den.

4. En avgift som dras i efterskott hör till månaden då tjänsten användes. Avgifter för till exempel Invoicing dras i klump en gång per dag, minst en dag och ibland upp till fem dagar i efterskott. Avgiften för 31 juli dras alltså från saldot först i augusti, men momsen följer den månad tjänsten användes, så den hör till juli. Sedan juli 2026 tar Stripes månadsfaktura med sådana avgifter efter när tjänsten användes, inte efter när de drogs, så bokför du från fakturan hamnar de rätt. Övergångsfakturan för juli 2026 kan därför omfatta mer än en kalendermånad (Stripe förklarar ändringen). Bokför du i stället avgifterna efter saldots rörelser hamnar de på dragningsdagen, och vid varje månadsskifte i fel momsperiod.

En följd av regel 3 och 4: bokföringens 1686 är inte lika med Stripe-saldot varje dag. Under månaden ligger bokföringen högre än Stripe med de avgifter som dragits men ännu inte bokförts. När månadsfakturan är bokförd stämmer det, bortsett från avgifterna för månadens sista dagar som Stripe drar först i nästa månad. Stäm av 1686 mot Stripe vid månadsskiftet, med den skillnaden förklarad.

Med Stripe-kopplingen i accounted. Koppla Stripe under Kopplingar så blir Stripe-saldot ett eget konto på 1686. Varje natt hämtas saldots rörelser till transaktionsinkorgen: varje betalning med sitt bruttobelopp, avgiften som en egen rad, återbetalningar, tvister, justeringar och utbetalningar. Ingenting bokförs automatiskt. Du bokför raderna som på ett bankkonto: betalningen som försäljning, eller mot kundfakturan om kunden betalade via betalningslänken, och utbetalningen som en överföring till 1930. Avgiftsraderna bokför du inte en och en. Bokför månadsfakturan som en verifikation enligt regel 3 och koppla sedan månadens avgiftsrader till den (i API:t POST /transactions/{id}/link-journal-entry), så bokförs ingen avgift två gånger. Kör du Stripe behöver du inte Make för att få in rörelserna.

Bygger du själv (annan betalväxel, egen logik, eller för att du vill förstå flödet) är det tre scenarion.

Scenario A: försäljningen, varje morgon.

1. Trigger: Schema, varje dag 06:00.
2. Read: Hämta gårdagens balance transactions från Stripe (GET /v1/balance_transactions med created[gte] och created[lt] för dygnet). Summera bruttobeloppet på charge-raderna per momssats. Momssatsen och vad som såldes kommer från din egen orderdata, eller från Stripe Tax om du använder det, inte från balance transaction. Avgiften på raderna låter du vara: den bokförs i scenario C.
3. HTTP: POST /api/v1/companies/{companyId}/journal-entries med en samlingsverifikation daterad försäljningsdagen:

POST /api/v1/companies/{companyId}/journal-entries
Authorization: Bearer gnubok_sk_live_…
Idempotency-Key: stripe-sales-2026-07-14
Content-Type: application/json

{
  "fiscal_period_id": "a8f1…",
  "entry_date": "2026-07-14",
  "description": "Stripe-försäljning 2026-07-14 (40 betalningar)",
  "lines": [
    { "account_number": "1686", "debit_amount": 50000, "credit_amount": 0, "line_description": "Stripe-saldot, brutto" },
    { "account_number": "3001", "debit_amount": 0, "credit_amount": 40000, "line_description": "Försäljning 25 %" },
    { "account_number": "2611", "debit_amount": 0, "credit_amount": 10000, "line_description": "Utgående moms 25 %" }
  ]
}

4. Underlag: Ladda upp dagens kvitton, eller en lista över dagens betalningar med kvittonummer, vad som såldes, belopp och moms, med POST /documents (multipart, med journal_entry_id från svaret).
5. Commit: POST /journal-entries/{id}/commit. Först nu får verifikationen sitt nummer.

Scenario B: utbetalningen.

1. Trigger: Stripe webhook payout.paid (Make och n8n har inbyggd Stripe-trigger).
2. HTTP: En verifikation på arrival_date: debet 1930, kredit 1686, med beloppet från utbetalningen. Idempotency-Key: stripe-payout-{payout_id}. Verifikationen påverkar varken resultatet eller momsen.
3. Commit som ovan, och skicka gärna en rad till #finance i Slack.

Scenario C: avgifterna, en gång i månaden.

1. Trigger: Schema, den 6:e varje månad. Stripe gör månadsfakturan tillgänglig runt den 5:e.
2. Underlag: Ladda ner förra månadens faktura under Documents i Stripes dashboard. Summera som kontroll månadens avgifter från balance transactions (fältet fee på varje rad, plus beloppet på rader av typen stripe_fee); skiljer summan sig från fakturan är det nästan alltid avgifter som dras i efterskott, se regel 4.
3. HTTP: En verifikation daterad sista dagen i månaden fakturan avser, med beloppen från fakturan:

POST /api/v1/companies/{companyId}/journal-entries
Authorization: Bearer gnubok_sk_live_…
Idempotency-Key: stripe-fees-2026-07
Content-Type: application/json

{
  "fiscal_period_id": "a8f1…",
  "entry_date": "2026-07-31",
  "description": "Stripe-avgifter juli 2026 enligt månadsfaktura",
  "lines": [
    { "account_number": "6570", "debit_amount": 812, "credit_amount": 0, "line_description": "Kortavgifter, momsfri betaltjänst" },
    { "account_number": "6540", "debit_amount": 120, "credit_amount": 0, "line_description": "Stripe Invoicing" },
    { "account_number": "4535", "debit_amount": 120, "credit_amount": 0, "line_description": "Inköp av tjänster från annat EU-land (ruta 21)" },
    { "account_number": "4598", "debit_amount": 0, "credit_amount": 120, "line_description": "Motkonto beräknad omvänd moms" },
    { "account_number": "2645", "debit_amount": 30, "credit_amount": 0, "line_description": "Beräknad ingående moms (ruta 48)" },
    { "account_number": "2614", "debit_amount": 0, "credit_amount": 30, "line_description": "Utgående moms omvänd skattskyldighet (ruta 30)" },
    { "account_number": "1686", "debit_amount": 0, "credit_amount": 932, "line_description": "Dras från Stripe-saldot" }
  ]
}

4. Underlag och commit: Ladda upp fakturan med POST /documents och committa som ovan.

Två saker att veta om API:t. POST /journal-entries skapar ett utkast: det är commit-steget som bokför. Och Idempotency-Key skickas som header, inte i JSON-kroppen. Om Stripe skickar samma webhook två gånger (det händer) returnerar accounted samma svar i stället för att skapa en dubblett.

Säljer du i flera momssatser eller till kunder i andra länder behöver scenario A dela upp raderna per land och sats. Där blir den inbyggda kopplingen eller en genomgång med revisorn billigare än ett Make-scenario med femton grenar.

Vad du sparar: ett par minuter per bankdag, en avgiftsverifikation i månaden i stället för en per betalning, och verifikationer där underlaget alltid stämmer med innehållet.

Recept 2: Leverantörsfaktura från inkorgen

Inkommande leverantörsfaktura till bolagets inkorgsadress landar i accounteds inkorg och läses av automatiskt. Du vill att den ska förberedas och att du bara ska behöva titta en gång.

Flödet:

1. Trigger: accounted webhook document.uploaded (skickas när ett underlag landar). Vill du hellre polla: GET /inbox-items?unprocessed_only=true på schema, eller händelseloggen med scopet events:read.
2. Fetch: GET /inbox-items/{id} ger leverantör, belopp, datum och de avlästa raderna.
3. Decide: Känd leverantör och belopp under 5 000 kr: gå vidare. Okänd leverantör eller högre belopp: skicka bara en länk till dig själv och stanna där.
4. Förhandsgranska: POST /inbox-items/{id}/convert?dry_run=true räknar fram leverantörsfakturan (moms, valutakurs, konton) utan att spara något. Skicka förhandsgranskningen till Slack.
5. Registrera: Samma anrop utan dry_run, med en Idempotency-Key, registrerar leverantörsfakturan med dokumentet som underlag. Bokför bolaget leverantörsfakturor vid registrering skapas verifikationen direkt, så låt steg 3 vara strikt.
6. Attest: Godkännandet (POST /supplier-invoices/{id}/approve) lämnar du åt en människa. Flödet förbereder, du attesterar.

Via MCP heter samma steg gnubok_get_inbox_item och gnubok_create_supplier_invoice_from_inbox. Där stagas registreringen och bokförs inte förrän du godkänt den under Väntande i appen. Via REST registrerar anropet direkt, därav förhandsgranskningen i steg 4.

Värt att tänka på: Bygg in en spärr som aldrig registrerar fakturor över t.ex. 50 000 kr automatiskt. Du vill inte att ett flöde ska missa att en utländsk leverantör triggar omvänd skattskyldighet.

Recept 3: Daglig runway-snapshot till Slack

Det här är där low-code är som bäst. Varje morgon kl 08:00 vill du ha en uppdaterad runway-rapport i #finance.

Flödet:

1. Trigger: Schemalagd körning varje vardag 08:00.
2. HTTP: GET /api/v1/companies/{companyId}/reports/kpi?period_id={period}. Samma nyckeltal som översikten i appen: kassa, kundfordringar, momsskuld, intäkter, kostnader och trend per månad. Vill du ha resultaträkningen per månad finns reports/monthly-breakdown. Kassa från KPI-rapporten, burn från månadstrenden.
3. Format: Bygg ett Slack-block med:
   • Burn rate (denna månad vs förra)
   • Kassa just nu
   • Runway i månader
   • En visuell indikator (🟢 > 12 mån, 🟡 6–12 mån, 🔴 < 6 mån)
4. Compare: Lagra dagens snapshot i Make/n8n:s data store. Imorgon jämför mot dagens. Om burn rate avviker mer än 15 % från trenden, lägg till en varning i meddelandet.
5. Send: Slack-meddelande till #finance.

Total tid att bygga: en eftermiddag. Värdet: hela ledningen ser samma runway varje morgon, automatiskt. Du slutar svara på "vad är vår runway?" i DM. Siffrorna är aldrig bättre än bokföringen, så recept 1 och 2 gör recept 3 mer värt.

Webhooks vs polling

Make och n8n stödjer båda men de gör olika saker bra:

• Webhooks: accounted (eller Stripe) skickar händelsen till dig när den inträffar. Använd för "när X händer, gör Y direkt" (recept 1B och 2). accounted skickar 28 olika händelsetyper och signerar varje leverans med HMAC i headern X-Gnubok-Signature. Verifiera signaturen i flödet.
• Polling: du frågar periodiskt om något nytt. Använd för "kör Y enligt schema, oavsett om det hänt något" (recept 1A, 1C och 3).

Som tumregel: webhooks för event-drivet, polling för schemalagt. Tre webhook-anrop per minut på samma flöde är ett tecken på att du borde slå ihop dem.

Vanliga fel

Dubbla verifikationer. Skicka alltid en Idempotency-Key-header i POST-anrop, byggd på något stabilt (Stripes payout-id, datumet för dagssammandraget, månaden för avgiftsfakturan). Samma nyckel ger samma svar och skapar ingen ny verifikation.

Intäkt på utbetalningsdagen. Se recept 1. Utbetalningen är en överföring. Försäljningen hör hemma på försäljningsdagen.

Avgiften i försäljningsverifikationen. Försäljningens underlag är ditt kvitto, och det säger ingenting om Stripes avgift. Håll verifikationen till försäljning och moms och bokför avgifterna från Stripes månadsfaktura, i den månad fakturan avser.

Egen momslogik där den inte behövs. Leverantörsfakturor och kategoriserade banktransaktioner räknar accounted momsen på själv, inklusive omvänd skattskyldighet. Bygg inte om den i Make. När du ändå skriver en verifikation rad för rad, som i recept 1A och 1C, håll en momssats per rad och stäm av mot momsrapporten innan du lämnar in.

Glömma utkastet. En verifikation som skapats men aldrig committats är inte bokförd, och ett kvarglömt utkast stoppar årsbokslutet. Låt flödet committa, eller larma om det misslyckas.

Glömma felhantering. Båda verktygen har felköer. Sätt upp en notifikation till Slack eller mejl när ett flöde felar tre gånger i rad. Annars upptäcker du det först vid bokslutet.

Bygga allt på en gång. Recept 1 i en månad. Recept 2 i en månad till. Recept 3 i månad tre. Varje flöde ska köras stadigt innan nästa läggs på.

Skillnaden mot MCP-kopplingen

Make/n8n är optimerade för event-baserade flöden mellan system. MCP-kopplingen till Claude (beskrivs i ChatGPT, Claude och din ledger) är optimerad för on-demand agentiska uppgifter där modellen bestämmer vilka verktyg som ska anropas, och där varje skrivning väntar på ditt godkännande.

Båda har sin plats. Många företag kör båda:

• Make/n8n för "varje morgon, varje ny utbetalning, varje leverantörsfaktura"
• Claude/MCP för "Stäng april", "Hitta varför momsen avvek", "Stäm av de senaste tolv inbetalningarna"

De pekar mot samma huvudbok. Det är den arkitekturen som Bokföring i AI-eran bygger på.

Vad du börjar med

Kör du Stripe: koppla Stripe i appen först, då kommer saldots rörelser in utan Make och du bokför dem enligt recept 1. Börja sedan med recept 3, som bara läser och inte kan skriva fel i huvudboken. När det har gått stabilt i två veckor, lägg på recept 2.

Hela REST-API:t, webhooks inräknade, är dokumenterat i API-dokumentationen. API-nyckeln skapar du under Inställningar → API i appen. Webhooks registrerar du via API:t (POST /webhooks) med den händelsetyp du vill lyssna på. Mer om vad du kan bygga finns under Utvecklare.

Den enda dåliga investeringen är att bygga allt på en gång och inse att tre saker går sönder samtidigt.

Vanliga frågor

Make eller n8n: vilket ska jag välja?

n8n om du vill self-hosta eller behöver mer flexibilitet i logik (JavaScript-noder, kod-block). Make om du vill ha snyggare UI och färre tekniska beslut. Funktionellt gör de samma sak mot accounted: tar emot webhooks och anropar REST-API:t. Välj efter resten av din stack.

Hur bokför man Stripe rätt?

Stripe-saldot är ett eget konto, vanligen 1686 Fordringar för kontokort och kuponger, eller 1684 Kortfristiga fordringar hos leverantörer om du inte tar emot kort. Försäljningen bokförs på försäljningsdagen mot det kontot, med bara försäljning och moms i verifikationen och ditt eget kvitto eller din faktura som underlag. Avgifterna bokförs för sig, en gång i månaden, från Stripes månadsfaktura och i den månad fakturan avser. Utbetalningen är en överföring till 1930. Kortavgiften är en momsfri betaltjänst, Billing, Invoicing, Tax och Radar köps med omvänd skattskyldighet.

Behöver jag programmera?

Nej. Båda verktygen är drag-and-drop. Du behöver förstå webhooks och HTTP-anrop på begreppsnivå (vad är en POST, vad är en header, vad är en payload) men ingen kod krävs. För mer avancerad logik kan du skriva en JavaScript-rad i n8n eller en formel i Make.

Vad händer om automationen felar mitt i en bokföring?

Varje skrivning valideras innan den sparas: en verifikation som inte balanserar, ligger i en låst period eller använder ett konto som saknas avvisas med en felkod. Verifikationer skapas som utkast och bokförs först när de committas. Felade flöden landar i Make/n8n:s felkö där du kan inspektera och köra om; Idempotency-Key gör omkörningen ofarlig.

Kan jag använda Make/n8n parallellt med MCP-koppling till Claude?

Ja. De är inte exklusiva. Make/n8n är bra för schemalagda eller event-drivna flöden (varje morgon, varje ny leverantörsfaktura). Claude via MCP är bra för on-demand uppgifter ('stäng månaden', 'hitta vad som saknas'). Båda går mot samma huvudbok.

Hur dyrt blir det?

Make har en gratisplan med 1 000 krediter i månaden och två aktiva scenarion. n8n är gratis att köra på egen server. För två av recepten här räcker gratisplanen för de flesta enpersonsföretag. Kör du alla tre i Make, eller fler flöden, behöver du en betald plan.