Live runway och burn-rate direkt från bokföringen

TL;DREn runway-dashboard som uppdateras i realtid kräver inte ett data warehouse. Två API-anrop mot huvudboken plus 80 rader Python räcker. Den här artikeln visar exakt hur: vilken formel, vilka konton, vilken cadence. Och varför nattliga batch-rapporter är fel verktyg för en metrik som ändras dagligen.

Det första någon med kassa borde göra i sitt företag är att bygga en runway-vy som inte är gjord en gång per kvartal i Excel. Inte för att Excel är fel, utan för att en siffra som ändras dagligen ska visas dagligen. Här är receptet.

Formeln

Klassisk runway:

runway = kassa / (trailing-90-dagars-burn / 90 * 30.4)

I praktiken:

• Kassa = saldo på 1930 (bank) plus likvida placeringar på t.ex. 1810
• Burn = (rörelseutgifter under senaste 90 dagar) minus (rörelseintäkter under samma period)
• Resultatet = antal månader

Vissa team räknar exklusive engångskostnader. Det är legitimt men du behöver vara konsekvent. Den enkla varianten är att räkna allt och vara medveten om att en hyresinbetalning kvartalsvis svänger siffran en månad.

Vad du behöver från huvudboken

Två API-anrop:

GET /api/balances?accounts=1930,1810&as_of=today

GET /api/reports/income-statement
  ?from=2026-02-12&to=2026-05-12&format=summary

Första returnerar kassan. Andra returnerar perioden, från vilken du beräknar burn. Det är allt.

I gnoboks MCP-server motsvarar dessa gnubok_get_balance_sheet och gnubok_get_income_statement. Båda är read-only och kostar ingen API-budget om du läser dem en gång om dagen.

Tre nivåer av implementation

Nivå 1: Slack-bot på 30 minuter

Make eller n8n-flöde:

1. Trigger: schemalagt varje vardag 08:00.
2. HTTP mot gnubok: hämta saldon och income statement.
3. Format: bygg ett Slack-block med kassa, burn, runway och en pil för riktning sedan i förrgår.
4. Send: posta till #finance.

Total tid: en eftermiddag. Total kostnad: under 100 kr/månad eller gratis på n8n.

Nivå 2: Python-bot med trendjämförelse

Ungefär 80 rader Python. Skillnaden mot nivå 1 är att botten också:

• Lagrar dagens snapshot i en SQLite-fil.
• Jämför mot snapshot från 7, 30 och 90 dagar sedan.
• Larmar i Slack om burn ändras med mer än 15 procent från trenden eller om runway sjunker under 6 månader.

import requests
from datetime import date, timedelta

API = "https://app.gnubok.se/api"
TOKEN = "din-token"

def fetch_balance(account):
    r = requests.get(
        f"{API}/balances",
        params={"accounts": account, "as_of": date.today().isoformat()},
        headers={"Authorization": f"Bearer {TOKEN}"},
    )
    return r.json()["balance"]

def fetch_burn(days=90):
    end = date.today()
    start = end - timedelta(days=days)
    r = requests.get(
        f"{API}/reports/income-statement",
        params={"from": start.isoformat(), "to": end.isoformat(), "format": "summary"},
        headers={"Authorization": f"Bearer {TOKEN}"},
    )
    data = r.json()
    return data["expenses_total"] - data["revenue_total"]

cash = fetch_balance("1930") + fetch_balance("1810")
burn_90 = fetch_burn(90)
monthly_burn = burn_90 / 90 * 30.4
runway = cash / monthly_burn if monthly_burn > 0 else float("inf")

print(f"Kassa: {cash:,.0f} kr | Burn: {monthly_burn:,.0f}/mån | Runway: {runway:.1f} mån")

Det är hela motorn. Slack-integration och trendjämförelse är ytterligare 40 rader.

Nivå 3: Inbäddat i hela rapporteringen

För större team ligger runway sida vid sida med ARR, bruttomarginal, NRR och CAC payback i ett ledningssystem. Här är gnubok en av flera datakällor och du har ett verktyg som Lightdash, Metabase eller en custom-byggd Next.js-app som drar ihop allt.

Skillnaden mot nivå 2 är inte teknisk komplexitet utan organisatorisk: nu kräver det att flera personer äger samma siffra och att den används i veckans ledningsmöte.

Vanliga fallgropar

Att räkna burn på utbetalningar i stället för periodiserade kostnader. En årlig SaaS-prenumeration som betalas i januari är en utgift i januari men en kostnad fördelad över hela året. Bokföringen vet det. Bankkontot vet det inte. Räkna burn från resultaträkningen, inte från bankkontot.

Att blanda in engångskostnader. En investerarrunda, en stor refund, ett kvartal med dubbel hyra. Det är värt att ha en variant av runway som exkluderar engångar och en som inkluderar. Visa båda.

Att inte uppdatera kontoplanen. Om du har börjat använda ett nytt likviditetskonto (säg 1820 för ett räntekonto) och inte lägger till det i formeln blir kassan underskattad. Granska kontolistan kvartalsvis.

Att larma för ofta. En 15-procents-tröskel på en vardag är vettig. En 5-procents-tröskel kommer ge dig 30 larm per kvartal och du kommer sluta läsa dem.

Varför direktläsning slår nattlig batch

Den vanligaste invändningen mot att läsa huvudboken direkt är "det är bättre att ha en data-pipeline som transformerar och cache:ar". För historisk analys, ja. För en metrik som behöver vara aktuell, nej. Tre skäl:

1. Latens. En nattlig batch visar gårdagens läge på morgonens möte. När bank-feed:en uppdateras inom minuter via PSD2 är gårdagens snapshot redan inaktuell.
2. Komplexitet. En direkt läsning kräver två API-anrop. En batch-pipeline kräver Airflow, dbt, ett warehouse, transformations och datakvalitetstester. Värt det för 50 dashboards. Inte värt det för 5.
3. Förtroende. Folk litar på siffran de ser för att de vet att den kommer från källan, inte från ett mellanlager som någon glömde bort att fixa.

När du har 10+ rapportbehov och behöver historisk djupanalys, lägg på ett warehouse. Innan dess är det overkill.

Vad du börjar med

Nivå 1: Slack-bot i Make eller n8n. En eftermiddag. När den har kört i två veckor, gå till nivå 2 om du behöver larm. Nivå 3 är när organisationen är så stor att flera ska titta samtidigt.

Hela arkitekturen bygger på principen i Bokföringen som tillväxtmotor: huvudboken är ett byggblock, inte en slutdestination. Och det är fundamentet i Bokföring i AI-eran. Den här artikeln är ett av de enklaste sätten att se principen i praktiken.

Den dåligaste tiden att bygga det här är när du upptäcker att runway är kort. Den bästa är nu.

Vanliga frågor

Vad är runway?

Hur många månader företaget kan fortsätta drivas med befintlig kassa, givet nuvarande burn rate. Formel: kassa delat på snittet av rörelseförluster senaste 90 dagarna. En siffra du som grundare borde veta exakt utan att tänka.

Är inte det här vad ett ekonomisystem ska visa per default?

Egentligen ja. I praktiken kräver de flesta att du klickar in i en rapport, väljer datumintervall, exporterar till Excel. Att exponera runway som en endpoint på din huvudbok tar bort alla steg och gör det åtkomligt för Slack, dashboards och agenter.

Varför inte använda Stripe/Brex/whatever för det här?

Stripe visar intäkter, inte resultat. Det företagskort du använder visar utgifter, inte allokering. Bara huvudboken har varje rörelse kopplad till rätt konto med rätt periodisering. Runway räknat på fel underlag blir runway räknat fel.

Behöver jag programmera för att bygga det här?

Lite. Den enklaste versionen är två API-anrop som Make eller n8n kan göra utan kod. Den något mer avancerade versionen (med trendjämförelser och larm) är 80 rader Python och en cron. Inget av det är komplicerat om du har rätt API.

Hur ofta uppdateras siffran?

Sekunden en transaktion bokförs. Bank-feed:en uppdateras inom minuter via PSD2. Det är skillnaden mot system som kör nattliga batchar. Dagens runway på morgonens dashboard är gårdagens runway, vilket spelar roll mer än det låter.