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-payouts till verifikation, leverantörsfaktura-godkännande, 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, kallar gnoboks REST-API, och kör flöden du designar utan att skriva kod.

Det här är tre recept som faktiskt funkar i produktion idag. Riktiga endpoints, riktiga steg.

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 gnubok" utan att anlita en utvecklare. Du designar flödet, det körs på schema eller vid webhook, och du har en audit-trail 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 payouts → verifikation

Varje gång Stripe gör en utbetalning till ditt bankkonto vill du att verifikationen bokförs automatiskt i gnubok. Inget skäl att klicka i appen.

Flödet:

1. Trigger: Stripe webhook payout.paid (Make/n8n har inbyggd Stripe-trigger).
2. Read: Hämta payout-detaljer (amount, fee, arrival_date, currency).
3. HTTP: POST mot gnoboks /api/transactions med:

{
  "date": "{{ arrival_date }}",
  "description": "Stripe payout, {{ description }}",
  "lines": [
    { "account": "1930", "debit": {{ amount - fee }} },
    { "account": "3001", "credit": {{ amount }} },
    { "account": "6570", "debit": {{ fee }} }
  ],
  "idempotency_key": "stripe-{{ payout_id }}"
}

4. Notify: Skicka en kort Slack-message till #finance med summan och länk till verifikationen.

idempotency_key är viktigt. Om Stripe skickar samma webhook två gånger (det händer) blir bokföringen ändå bokad en enda gång. gnubok avvisar dubbletten tyst.

Vad du sparar: ~3 minuter per payout. Räknat på 30 payouts per månad: 90 minuter, varje månad, alltid korrekt.

Recept 2: Leverantörsfaktura → godkännandeflöde

Inkommande leverantörsfaktura till din e-post landar i gnoboks inbox via mejlhook. Du vill att den ska kategoriseras automatiskt och köas för ditt godkännande, utan att du loggar in.

Flödet:

1. Trigger: gnubok webhook inbox.item.created (skickas när en faktura landar i inbox).
2. Fetch: Kalla /api/inbox/{{ item_id }} för att få fakturadetaljer (leverantör, belopp, OCR-extraherade rader).
3. Decide: Om beloppet är under 5 000 kr OCH leverantören finns sedan tidigare → kategorisera automatiskt mot tidigare motpartsmall. Om över eller okänd leverantör → kategorisera men markera som "kräver din uppmärksamhet".
4. HTTP: POST mot /api/supplier-invoices med kategoriseringen.
5. Notify: Skicka ett strukturerat meddelande i Slack med en "Godkänn"-knapp som länkar direkt till gnubok-webbens godkännandeflöde.

Det här ersätter inte ditt godkännande. Det förbereder det. Du går från att kategorisera + godkänna till att bara godkänna.

Värt att tänka på: Bygg in en spärr som inte kategoriserar fakturor över t.ex. 50 000 kr automatiskt. Du vill inte att en agent 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 låg-kod är som bäst. Varje morgon kl 08:00 vill du ha en uppdaterad runway-rapport i #finance.

Flödet:

1. Trigger: Schemalagd kör varje vardag 08:00.
2. HTTP: GET /api/reports/kpi?metric=runway&window=90d.
3. Format: Bygg ett strukturerat 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 > 15 % från trenden, lägg till en varning i meddelandet.
5. Send: Slack-message till #finance.

Total tid att bygga: en eftermiddag. Värdet: hela ledningen ser samma runway varje morgon, automatiskt. Du slutar att svara på "vad är vår runway?" i DM.

Webhooks vs polling

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

• Webhooks: gnubok skickar händelsen till dig sekunden den inträffar. Använd för: "när X händer, gör Y omedelbart" (recept 1 och 2).
• Polling: du frågar gnubok periodiskt om något nytt. Använd för: "kör Y enligt schema, oavsett om det hänt något" (recept 3).

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

Vanliga fel

Dubbla verifikationer. Använd alltid idempotency_key i POST-anrop. gnubok tar bort dubbletter tyst.

Felaktig moms-beräkning. Bygg inte momslogiken själv i Make/n8n. Skicka beloppen och låt gnubok räkna momsen. Den vet svenska reglerna, omvänd skattskyldighet, EU-handel.

Glömma felhantering. Båda verktygen har felköer. Sätt upp en notifikation till Slack/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 direktintegration via MCP

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 LLM:en bestämmer vilka verktyg som ska kallas.

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

• Make/n8n för "varje fredag, varje ny Stripe-payout, varje leverantörsfaktura"
• Claude/MCP för "Stäng april", "Hitta varför moms avvek", "Stäm av de senaste tolv inbetalningarna"

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

Vad du börjar med

Recept 1 (Stripe payouts) är det enklaste och har snabbast payback om du redan kör Stripe. Bygg det först. När det har kört utan fel i två veckor, lägg på recept 2. När det också är stabilt: recept 3.

Hela gnoboks REST-API är dokumenterat under Utvecklare. API-token genereras under Inställningar i appen. Webhook-konfiguration ligger i samma vy.

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 gnubok. Båda funkar bra; välj baserat på resten av din stack.

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 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?

Inget felaktigt landar i huvudboken. Alla skrivoperationer mot gnubok valideras deterministiskt, felaktiga anrop avvisas. Felade flöden landar i Make/n8n:s felkö där du kan inspektera och köra om. Audit-loggen visar exakt vad som hände.

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 fredag, varje ny Stripe-payout). Claude/MCP är bra för on-demand uppgifter ('stäng månaden', 'hitta vad som saknas'). De använder samma underliggande API.

Hur dyrt blir det?

Make har en gratisplan upp till 1 000 operations/månad, n8n är gratis self-hosted. För de tre recepten i den här artikeln räcker gratisplanen för de flesta enpersonsföretag. När du växer in i 10+ automationer landar de flesta i 99–299 kr/månad på Make eller infrakostnad på n8n.