Bruttomarginal per kund i realtid

TL;DRDu vet vad du fakturerar varje kund. Du vet sällan vad varje kund faktiskt kostar dig. Bruttomarginal per kund kräver att intäkter och allokerade kostnader ligger i samma huvudbok, kopplade via objektkoder. Med en API-baserad huvudbok är det 100 rader Python och en nattlig cron att räkna det rätt. Här är receptet.

Det är skillnad på vad du fakturerar och vad du tjänar. Den vanliga missuppfattningen i tillväxtbolag är att tro att intäkten är pengarna. Den är inte. Bruttomarginalen är pengarna. Och bruttomarginalen är intäkt minus de direkta kostnaderna för att leverera till den specifika kunden.

För att räkna det rätt behöver du att intäkter och kostnader är kopplade till samma kund i samma datakälla. Det är vad huvudboken är till för. Här är hur du sätter upp det.

Vad du faktiskt vill räkna

Bruttomarginal per kund i procent:

bruttomarginal % = (intäkt - direkta kostnader) / intäkt

Som siffra i kronor:

täckningsbidrag = intäkt - direkta kostnader

Båda är intressanta. Procentsatsen visar effektivitet (är denna kund lönsam i sig?). Kronan visar bidrag (hur mycket täckningsbidrag tjänar vi totalt på denna kund?).

För beslut: en kund med 90% bruttomarginal men 1 000 kr i intäkt är ofta mindre värdefull än en kund med 30% bruttomarginal men 100 000 kr i intäkt. Räkna båda.

Vad räknas som "direkta kostnader"

Direkta kostnader är de som inte hade funnits om kunden inte funnits. Konkret:

SaaS-företag:

• Hosting/infrastruktur för den specifika kunden (om allokerbart)
• Direct support timmar (kontolisten på 7xxx-konton, allokerade)
• Customer success / onboarding-resurser för stora kunder
• Tredjepartskostnader för API:er som vidarefaktureras (t.ex. AI-tokens, om kunden använder dem)

Konsultbolag:

• Konsulttid (lönekostnad allokerad till kund via tidrapporter)
• Underleverantörers fakturor allokerade till kund
• Resor och hotell relaterade till leveransen

E-handelsbolag:

• Varukostnad (KVS) per kund-order
• Frakt
• Returkostnader
• Betalningsprocessorns avgifter

Vad som INTE räknas:

• Marknadsföring (CAC ligger separat)
• Allmän administration
• Lokalkostnader
• Vd-lön
• Mjukvarulicenser som är allmänna

Det här är fundamentet. Om du har allmänna kostnader allokerade som direkta blir bruttomarginalen lägre och du fattar fel beslut om vilka kunder som är värdefulla.

Steg 1: Sätt upp objektkoder

Svensk BAS har en konvention för objektkoder i 9000-serien. Vissa system kallar det dimensioner, vissa kallar det kostnadsställen. Det är samma sak.

I gnubok skapar du en objekttyp "Kund" och en kod per kund:

GET /api/objects
[
  { "code": "K001", "type": "customer", "name": "Acme AB" },
  { "code": "K002", "type": "customer", "name": "Bolaget X" },
  ...
]

Du behöver inte tagga varje kund manuellt. Vid fakturering taggas intäktsraderna automatiskt med kundens objektkod. Vid leverantörsfakturor som du allokerar mot specifik kund behöver du tagga vid bokföring.

Steg 2: Tagga intäkter (automatiskt)

När du fakturerar en kund i gnubok skapas en verifikation som ser ut såhär:

#VER A 123 20260512 "Faktura 2026-018 Acme AB"
{
#TRANS 1510 {OBJEKT=KUND;K001} 12500.00
#TRANS 3001 {OBJEKT=KUND;K001} -10000.00
#TRANS 2611 {OBJEKT=KUND;K001} -2500.00
}

{OBJEKT=KUND;K001} är objekttaggen. Den följer raden i huvudboken och blir filtrerbar i alla rapporter.

Om du fakturerar via API blir det automatiskt taggning vid gnubok_create_invoice om kunden har en objektkod.

Steg 3: Tagga direkta kostnader (vid bokföring)

Det här är där disciplinen spelar roll. När du bokför en leverantörsfaktura som är direkt allokerbar till en kund, tagga den med kundens objektkod.

Exempel: du köper en AWS-instans dedicerad till en kund för 3 000 kr/månad.

#VER L 56 20260501 "AWS Acme-instans"
{
#TRANS 6540 {OBJEKT=KUND;K001} 2400.00
#TRANS 2641 {OBJEKT=KUND;K001} 600.00
#TRANS 2440 {OBJEKT=KUND;K001} -3000.00
}

I gnobok-UI: vid kategorisering av leverantörsfakturan, dropdown för objektkod. Ta den till vana. Det är 5 sekunder extra per faktura men det är skillnaden mellan att räkna bruttomarginal rätt och att gissa.

För återkommande kostnader (konsulttid, dedicerade resurser) kan du sätta upp en mall så att taggningen sker automatiskt vid varje månadsfakturering.

Steg 4: Räkna bruttomarginalen

API-anropet:

curl https://app.gnubok.se/api/reports/customer-margin \
  -H "Authorization: Bearer $TOKEN" \
  -G \
  -d "from=2026-01-01" \
  -d "to=2026-05-12"

Returnerar:

{
  "period": { "from": "2026-01-01", "to": "2026-05-12" },
  "customers": [
    {
      "customer_id": "K001",
      "customer_name": "Acme AB",
      "revenue": 125000.00,
      "direct_costs": 32400.00,
      "gross_margin": 92600.00,
      "gross_margin_percent": 74.08
    },
    {
      "customer_id": "K002",
      "customer_name": "Bolaget X",
      "revenue": 89000.00,
      "direct_costs": 67200.00,
      "gross_margin": 21800.00,
      "gross_margin_percent": 24.49
    }
  ]
}

Du ser direkt vilka kunder som är lönsamma och vilka som drar ner snittet. För dashboard-byggande: dra detta in i Metabase, Lightdash eller en custom Next.js-app.

Vad du gör med datan

Tre vanliga beslut som blir bättre med kundmarginal:

1. Pris-justering

Kunder under 50% bruttomarginal: kandidater för prishöjning eller scope-reduktion vid förnyelse. Inte automatik, men en signal att titta.

2. Customer success-allokering

Kunder med hög marginal och hög ARR förtjänar mer dedikerad customer success. Kunder med låg marginal får standardiserad onboarding via dokumentation.

3. Beslut att inte förnya

Kunder med konsekvent negativ bruttomarginal trots flera kvartal av justeringar: kandidater för icke-förlängning. Det är en svår beslut men det är ärligare att fatta det med data än utan.

Vad du inte ska göra

Räkna kundmarginal månadsvis och dra slutsatser per månad. En kund som tar 20 timmar onboarding första månaden ser dålig ut den månaden, fantastisk de följande. Räkna rullande 6–12 månader.

Mixa in akquisitionskostnaden i bruttomarginal. CAC är ett separat mått (CAC payback, LTV/CAC). Bruttomarginal är efter akvisition.

Försöka allokera alla kostnader. Vissa kostnader är genuint icke-allokerbara. Lämna dem oallokerade och rapportera dem separat som overhead.

Räkna före intäktsperiodisering. Om en kund betalar för helåret i januari är intäkten 1/12 per månad, inte allt i januari. Använd periodiserade intäkter i bruttomarginalberäkningen.

Konkret recept för att komma igång

1. Identifiera dina topp-20 kunder efter omsättning senaste 12 månaderna.
2. Skapa objektkoder för dem (K001, K002, ...) i gnubok.
3. Tagga deras pågående fakturor framåt med rätt objektkod.
4. Identifiera direkta kostnader för var och en (hosting, support-tid, underleverantörer) och tagga dessa.
5. Kör customer-margin-rapporten efter en månad.

Två månader senare har du tillräckligt med data för att se tydliga mönster. Tre månader senare kan du fatta beslut.

För teknisk fördjupning i hur gnoboks rapporter fungerar: se Live runway och burn-rate direkt från bokföringen för samma typ av direktläsning från huvudboken.

Varför inte ett data warehouse?

Du kan absolut bygga det här i Snowflake plus dbt och alla tunga verktyg. För 200 kunder och tre månaders historik är det overkill. För 20 000 kunder och fem års historik blir det rimligt.

Brytpunkten är vanligen när du har:

• 1 000+ kunder
• 5+ datakällor som behöver kombineras
• Behov av historiska transformationer (ändrade kontoplaner, ändrade allokeringsregler)

Före brytpunkten är direktläsning från huvudboken snabbare att bygga, snabbare att underhålla, och uppdaterar i realtid. Det är vad Bokföringen som tillväxtmotor menar med "huvudboken är inte slutdestinationen, den är källan".

Vad du gör nu

Logga in i gnubok. Gå till Inställningar, Objekt, och skapa objektkoder för dina topp-10 kunder. Tagga nästa månads fakturor och leverantörsfakturor när de bokförs. Kör customer-margin-rapporten på första maj efter månaden.

Det är 30 minuter setup och 5 minuter per dag i ny disciplin. Värdet är att du för första gången vet vilka kunder som faktiskt är lönsamma.

Vanliga frågor

Vad är bruttomarginal per kund?

Intäkter från en kund minus direkta kostnader för att leverera till samma kund, uttryckt som procent av intäkten. För ett SaaS-företag är direkta kostnader vanligen hosting, support, customer success. För ett konsultbolag är det allokerad konsulttid.

Varför kan jag inte räkna det i Stripe eller i mitt CRM?

Stripe har intäkterna men inte kostnaderna. CRM:et har relationen men inte siffrorna. Bara huvudboken har båda kopplade till samma kund via objektkod eller verifikationstext. Det är därför det måste räknas på bokföringsdatan, inte på CRM-datan.

Behöver jag tagga varje verifikation med kundnamn?

Varje direkt-allokerbar verifikation, ja. Använd objektkoder (BAS-standardens objektkonton 90xx-99xx eller systemets egna dimensioner). När du faktura en kund tagga försäljningsintäkten med kundens kod. När du betalar för dedicerad infrastruktur, tagga kostnaden likadant.

Vad gör jag med overhead som inte går att allokera?

Lämna oallokerat. Bruttomarginal per kund täcker bara direkta kostnader per definition. Overhead (löner till management, kontorshyra, allmänna verktyg) räknas i resultaträkningen som helhet, inte per kund. Var konsekvent: blanda inte in overhead i kundkostnaden.

Hur ofta uppdateras siffrorna?

Sekunden en verifikation bokförs. Om du kör en nattlig cron som dragit ut alla kunders bruttomarginal är morgonens siffror baserade på gårdagens stängning. Om du läser via API i realtid har du minutens läge. Skillnaden spelar sällan stor roll för marginalanalys.