SaaS-nøgletal: MRR, churn, LTV og CAC forklaret på dansk

SaaS-nøgletal er de få tal der viser om et abonnementsprodukt vokser sundt: MRR (den månedlige tilbagevendende omsætning), churn (de kunder og kroner du mister), LTV (hvad en kunde er værd over hele forholdet) og CAC (hvad det koster at skaffe en ny kunde). Tallene hænger sammen, så når du først har styr på MRR og churn, kan du regne resten ud. Herunder får du formlerne, ét gennemgående regneeksempel i kroner og SQL der trækker tallene direkte ud af databasen.

Jeg er udvikler og ikke revisor. Min vinkel er, at tallene skal beregnes ens hver gang og komme ud af systemet uden et regneark.

Den korte version

Tabellen viser de syv tal de fleste SaaS-iværksættere har brug for. Eksemplerne bygger på et opdigtet B2B-værktøj med 100 betalende kunder ved månedens start: 80 betaler 500 kr. om måneden, og 20 betaler 4.800 kr. om året. Alle beløb er ekskl. moms.

Min beslutningsregel er enkel. Følg MRR og churn hver måned fra den første betalende kunde. LTV og CAC bliver først brugbare, når du har så mange kunder og måneder bag dig at én enkelt opsigelse ikke vælter tallene.

Skridtene frem til de første betalende kunder gennemgår jeg i min komplette guide til at bygge en SaaS.

MRR: den månedlige tilbagevendende omsætning

MRR (monthly recurring revenue) er summen af hvad alle dine aktive, betalende abonnementer er værd pr. måned. Alle de andre nøgletal bygger på det, så definitionen skal ligge fast fra start. Fire regler dækker de fleste tilfælde:

• Årsabonnementer deles med 12. En kunde der betaler 4.800 kr. i januar, bidrager med 400 kr. i MRR i hver af årets 12 måneder, ikke med 4.800 kr. i januar.
• Moms holdes ude. Den er ikke din omsætning.
• Engangsbeløb holdes ude: oprettelsesgebyrer, betalt onboarding, konsulenttimer og tilkøb der ikke gentages.
• Gratis konti og kunder i prøveperiode tæller ikke med, før de betaler.

Rabatter er en vurderingssag. Stripe trækker altid varige rabatter fra, lader dig selv vælge for tidsbegrænsede, og kalder fradraget en mere konservativ tilgang i Stripes definitioner af MRR, churn og LTV. Jeg trækker alle løbende rabatter fra: 50 % rabat for evigt gør en 500-kroners-kunde til en 250-kroners-kunde.

MRR er et øjebliksbillede

Det interessante er derfor bevægelsen fra måned til måned, og den kan deles op i fem dele. I eksemplet ser den næste måned sådan ud:

• Ny MRR: 10 nye kunder på månedsabonnement, +5.000 kr.
• Ekspansion: 4 kunder tilkøber en ekstra bruger til 250 kr., +1.000 kr.
• Kontraktion (nedgradering): 2 kunder fjerner en bruger, -500 kr.
• Churn: 2 månedskunder opsiger, og 1 årskunde fornyer ikke, -1.400 kr.
• Reaktivering: tidligere kunder der kommer tilbage, 0 kr. denne måned.

MRR ender på 52.100 kr. Væksten ser fin ud, men opdelingen viser noget som totalen skjuler: uden de nye kunder var MRR faldet. Hvordan din prismodel påvirker ekspansion og ARPU, kan du læse om i indlægget om prismodeller til SaaS, og hvordan du vælger.

Churn: kunder og kroner der forsvinder

Churn skal måles på to måder, fordi tallene fortæller to forskellige historier.

Kunde-churn er antal kunder der stopper, divideret med antal kunder ved periodens start. I eksemplet er det 3 ud af 100, altså 3 %. Omsætnings-churn er den MRR du mister til opsigelser og nedgraderinger, divideret med MRR ved start: (1.400 + 500) ÷ 48.000, eller knap 4 %.

Er omsætnings-churn højere end kunde-churn, er det dine større kunder der går eller skærer ned. Det er som regel værre end det modsatte.

Tre ting snyder ofte:

1. Nettochurn skjuler tab. Trækker du ekspansion fra, får du nettochurn: (1.900 minus 1.000) ÷ 48.000 = 1,9 %. Tallet er nyttigt, men a16z advarer om at nettochurn undervurderer skaden, så følg altid bruttochurn ved siden af.
2. Månedlig churn kan ikke ganges med 12. Mister du 3 % om måneden, mister du omkring 31 % om året og ikke 36 %, fordi du hver måned mister 3 % af et lidt mindre antal kunder.
3. Definitionen skal ligge fast. Stripe dividerer med kunderne ved start plus de nye kunder i perioden, hvilket i eksemplet giver 3 ÷ 110 = 2,7 %. Ingen af delene er forkert, men skifter du definition undervejs, kan du ikke sammenligne måneder.

En del churn er slet ikke en beslutning. Det er et kort der udløber, eller en betaling der fejler. Hvordan du finder og stopper den slags, står i indlægget om tekniske årsager til at SaaS-kunder opsiger.

LTV og CAC: hvad en kunde er værd, og hvad den koster

LTV (kundens livstidsværdi)

LTV (lifetime value) er et skøn over hvad en gennemsnitskunde bidrager med, før vedkommende stopper. Den simple formel er ARPU divideret med kunde-churn, og det er også sådan Stripe regner den. Med 480 kr. og 3 % churn giver det 16.000 kr.

Det tal er for optimistisk, fordi det regner på omsætning. a16z anbefaler i stedet at bruge dækningsbidraget, altså omsætningen minus de variable omkostninger ved at betjene kunden: hosting, betalingsgebyrer, support og eventuelle AI-kald. Med en dækningsgrad på 80 % bliver LTV 480 × 0,8 ÷ 0,03 = 12.800 kr.

Formlen er også meget følsom. Mister du én kunde mere, så churn går fra 3 til 4 %, falder LTV fra 12.800 til 9.600 kr. Med få kunder kan LTV derfor hoppe tusindvis af kroner, uden at noget reelt har ændret sig. Et mere jordnært tal er værdien af kundens første år: med 3 % churn er en ny kunde i gennemsnit betalende i godt 10 af de første 12 måneder, svarende til cirka 3.900 kr. i dækningsbidrag.

CAC (omkostning pr. ny kunde)

CAC (customer acquisition cost) er dine samlede salgs- og marketingomkostninger i en periode divideret med antal nye betalende kunder i samme periode. Virksomheden i eksemplet bruger 30.000 kr. på annoncer, værktøjer og indhold og får 10 nye kunder. CAC er 3.000 kr.

Det er let at regne CAC for lavt. Tag rabatter, gratis måneder og henvisningsbonusser med, som a16z også påpeger. Sælger du selv, så sæt en timepris på din tid. Ellers ser kanalen billig ud, indtil du skal betale en anden for at gøre arbejdet. Skeln også mellem samlet CAC for alle kanaler og CAC for betalt markedsføring alene. Kun det sidste viser om annoncekronerne betaler sig.

Tilbagebetalingstid: LTV og CAC sammen

LTV på 12.800 kr. mod CAC på 3.000 kr. er et forhold på godt 4 til 1. Jeg synes dog tilbagebetalingstiden er nemmere at handle på: CAC divideret med det månedlige dækningsbidrag pr. kunde. Her er det 3.000 ÷ 384 (480 × 0,8), altså knap 8 måneder. Så længe skal en ny kunde blive, før anskaffelsen er tjent hjem. Er tilbagebetalingstiden længere end den tid dine kunder typisk bliver, taber du penge på hver ny kunde.

Sådan trækker du nøgletallene ud af din egen database

Stripe og andre betalingsløsninger viser kun MRR og churn for de betalinger der går gennem dem. Har du kunder på faktura, flere betalingsløsninger, eller vil du se omsætning og produktbrug side om side, skal tallene komme fra din egen database. Sådan ville jeg sætte det op i en Laravel-app med Laravel Cashier, men princippet gælder i alle stacks.

1. Gem beløbet lokalt. Cashier gemmer abonnementets status og Stripes pris-id i tabellen subscriptions, men ikke selve beløbet, jf. dokumentationen for Laravel Cashier. Du skal derfor have en tabel med pris-id, beløb i øre ekskl. moms og interval. Har et abonnement flere priser, ligger de i subscription_items, og så summerer du derfra.
2. Hold status opdateret. Cashier synkroniserer sine tabeller via Stripes webhooks, når webhook-håndteringen er sat op. Uden den står opsagte kunder stadig som aktive i din database.
3. Gem historik, ikke kun nutid. Tabellen subscriptions viser hvordan det ser ud i dag. For at beregne churn for marts skal du vide hvordan det så ud 1. marts. Den enkleste løsning er et månedligt snapshot: en tabel med dato, kunde og MRR, som en planlagt kommando fylder den 1. i hver måned.
4. Omregn alt til én måned og én valuta. Årspriser deles med 12, beløb gemmes som heltal i øre for at undgå afrundingsfejl, og kunder i euro omregnes til kroner med en fast kurs pr. måned.
5. Beregn og afstem. Når snapshots ligger der, er MRR og churn korte forespørgsler. Sammenlign med Stripes egne tal den første måned. Afvigelser skyldes næsten altid en definition: rabatter, prøveperioder eller fejlede betalinger.

Eksempel: snapshot, MRR og churn i SQL

Snapshottet gemmer hver betalende kundes MRR på dagen. Ligesom Stripe tæller det abonnementer med status active og past_due som betalende. Abonnementer i prøveperiode har status trialing og kommer derfor ikke med. I B2B er den betalende part ofte et team eller en virksomhed frem for en bruger, så sørg for at snapshottet tæller betalende konti og ikke personer. Eksemplet forudsætter én valuta.

INSERT INTO mrr_snapshots (taken_on, user_id, mrr_ore)
SELECT
  CURRENT_DATE,
  s.user_id,
  SUM(
    CASE p.billing_interval
      WHEN 'year' THEN p.amount_ore / 12
      ELSE p.amount_ore
    END * COALESCE(s.quantity, 1)
  )
FROM subscriptions s
JOIN prices p ON p.stripe_price = s.stripe_price
WHERE s.stripe_status IN ('active', 'past_due')
GROUP BY s.user_id;

MRR og antal kunder pr. måned er derefter en simpel gruppering:

SELECT
  taken_on,
  COUNT(*) AS kunder,
  SUM(mrr_ore) / 100 AS mrr_kr
FROM mrr_snapshots
GROUP BY taken_on
ORDER BY taken_on;

Churn for marts finder du ved at lede efter kunder der var med 1. marts, men mangler 1. april:

SELECT
  COUNT(*) AS stoppede_kunder,
  SUM(m.mrr_ore) / 100 AS tabt_mrr_kr
FROM mrr_snapshots m
LEFT JOIN mrr_snapshots a
  ON a.user_id = m.user_id
  AND a.taken_on = '2027-04-01'
WHERE m.taken_on = '2027-03-01'
  AND a.user_id IS NULL;

Divider resultatet med antal kunder og MRR fra 1. marts, så har du kunde-churn og omsætnings-churn for måneden. Ekspansion og kontraktion finder du på samme måde ved at sammenligne MRR for de kunder der findes i begge snapshots.

Fejl der får tallene til at se bedre ud, end de er

De fleste regnefejl i SaaS-nøgletal trækker i samme retning: de får forretningen til at se sundere ud. Hold øje med disse:

• Årsbetalinger tælles som MRR i den måned de betales. Det giver en kunstig top i januar og et "fald" resten af året.
• Prøvebrugere og gratis konti tælles som kunder, så ARPU og churn bliver misvisende.
• Brugere og kunder blandes sammen. Opsiger en virksomhed med 12 brugere, er det én tabt kunde, ikke 12.
• Kunder med en fejlet betaling står som aktive i månedsvis. Stripe tæller past_due med i MRR, men regner abonnementet som churn, når det ender som ubetalt. Beslut selv hvor længe en kunde må stå med en fejlet betaling, før du regner den som tabt.

Hvornår du ikke behøver bygge noget selv

Det er ikke alle der skal have nøgletallene bygget ind i systemet, og jeg vil hellere sige det her end sælge dig en opgave du ikke har brug for.

• Går alle betalinger gennem Stripe, og har du én eller to planer, så brug Stripes eget Billing-overblik. Det viser MRR, churn, ARPU og LTV, og du kan selv vælge hvordan rabatter tæller med. Det kræver ingen udvikling.
• Har du under 20-30 betalende kunder, er procenttal mest støj. Et regneark med kunde, beløb, startdato og slutdato er nok, og tiden er bedre brugt på at tale med kunderne.
• Kører du med freemium eller gratis prøveperiode, er konvertering ofte vigtigere end churn de første måneder. Forskellen på modellerne gennemgår jeg i indlægget om freemium, gratis prøveperiode eller betaling fra dag ét.

Det betaler sig først at bygge det selv, når du har kunder på faktura, flere betalingsløsninger, årsaftaler med individuelle priser, eller når du vil se omsætning og produktbrug side om side. Valget af betalingsløsning afgør hvor meget arbejde det er, så kig gerne på sammenligningen af Stripe, Paddle og danske løsninger til abonnementsbetaling først.

Næste skridt: sådan kommer du i gang

Start med definitionerne, ikke med et dashboard. Skriv ned hvad der tæller som en betalende kunde, og hvordan du håndterer årsabonnementer, rabatter, valuta og fejlede betalinger. Hold derefter fast i det, så månederne kan sammenlignes.

Når MRR og churn er på plads, er det næste tal aktivering: hvor mange nye kunder der faktisk tager produktet i brug. Det kræver hændelser fra selve produktet, og værktøjerne til det sammenligner jeg i indlægget om GA4, Plausible og PostHog.

Skal tallene bygges ind i en SaaS du allerede har, eller i en ny du er ved at planlægge, kan du se hvordan jeg arbejder med udvikling af SaaS-produkter.

Ofte stillede spørgsmål

Hvad er en god churn-rate for en SaaS?+

Der findes ikke ét godt tal, fordi churn afhænger meget af hvem du sælger til. Produkter til små virksomheder og enkeltpersoner har typisk højere churn end produkter til større virksomheder med årsaftaler. Sammenlign derfor hellere med dig selv over tid end med et gennemsnit fra nettet. Stiger churn tre måneder i træk, er det et signal, uanset niveauet.

Hvordan regner jeg churn, når kunderne har årsabonnement?+

Mål fornyelsesraten for de kunder der faktisk var til fornyelse i perioden. En årskunde kan kun stoppe én gang om året, så i den månedlige kunde-churn ser årskunder kunstigt stabile ud. Fornyer 18 ud af 20 årskunder i januar, er fornyelsesraten 90 %. Har du både måneds- og årskunder, så opgør dem hver for sig.

Er MRR det samme som omsætningen i regnskabet?+

Nej. MRR er et driftstal der viser den løbende værdi af dine abonnementer, mens regnskabet følger bogføringsreglerne. En årsbetaling på 4.800 kr. i januar tæller som 400 kr. i MRR hver måned, men hvordan den periodiseres i regnskabet, afhænger af din regnskabspraksis. Spørg din revisor om den del, og brug MRR til at styre forretningen.

Hvor ofte skal jeg kigge på mine SaaS-nøgletal?+

Månedligt er en god rytme for MRR og churn, så tallene følger faktureringsperioden. Tilmeldinger og aktivering kan du følge ugentligt, da de reagerer hurtigere på ændringer i produktet og markedsføringen. LTV og CAC rykker sig langsomt og er mest brugbare at gennemgå hvert kvartal, når der er data nok til at udjævne udsvingene.