Dunning-agent på autopilot

TL;DREn dunning-agent läser kundreskontran varje morgon, identifierar förfallna fakturor, skickar standardiserade påminnelser i tre steg, och eskalerar. På en huvudbok som är ett API är det 150 rader Python eller ett Make-flöde på en eftermiddag. De flesta småföretag har 50 000 kr eller mer i onödig kapitalbindning som dunning-automation löser. Här är receptet.

Indriven kapitalbindning är pengar du redan tjänat men inte fått. För de flesta småföretag ligger den någonstans mellan 30 000 och 200 000 kr i onödig drift, helt enkelt för att ingen kommit till att skicka påminnelse. En dunning-agent fixar det utan att du behöver tänka på det. Här är hur du bygger en.

Vad agenten ska göra

Agenten är aktiv, inte rapporterande. Den producerar handlingar, inte PDF:er. Konkret:

1. Varje arbetsdag morgon: läs aktiva kundfakturor från reskontran.
2. Identifiera förfallna: fakturor där förfallodatum passerats med 1+ dagar.
3. Kolla påminnelsestatus: var i sekvensen ligger varje förfallen faktura?
4. Skicka nästa steg: om dagsavståndet stämmer med sekvensen, skicka påminnelse.
5. Logga: registrera att påminnelse skickats så nästa körning vet var den är.
6. Vid sista steget: lägg fakturan på "Manuell uppföljning"-listan för dig att hantera.

Det är hela agenten. Inget fancy. Mest disciplin i datamodellen.

Sekvensen

Standardpraxis i Sverige:

Dag (efter förfallodag)	Åtgärd	Avgift
1	Vänlig påminnelse 1	-
8	Påminnelse 2 med påminnelseavgift	60 kr
16	Sista påminnelse innan inkasso	60 kr
24	Markera för manuell uppföljning / inkasso	-

Du kan justera intervallen. Vissa branscher kör tighter (1, 5, 10, 15 dagar) för att indrivningstid är kortare. B2B kör vanligen längre (1, 14, 30, 45) eftersom större företag har långsammare betalningsrutin.

Inkasso är ett separat steg som vanligen sköts av en extern leverantör (Visma Collectors, Visma Inkasso, Kreditor). Det är inte agentens jobb att skicka till inkasso automatiskt. Det är agentens jobb att lägga ärendet på din "att hantera"-lista efter sista påminnelsen.

Implementering: tre nivåer

Nivå 1: Make eller n8n-flöde (en eftermiddag)

För 90 procent av användarna är low-code rätt val.

Flödet:

1. Trigger: schemalagt 09:00 mån-fre.
2. HTTP GET: /api/invoices/ar?status=overdue&include_payment_terms=true. Returnerar alla förfallna fakturor med dagsavstånd från förfallodatum.
3. Loop över fakturor: för varje förfallen faktura, kolla last_dunning_action_at och avgör nästa steg.
4. Conditional: om dagsavstånd matchar nästa steg, skicka påminnelse.
5. HTTP POST: /api/invoices/{id}/send-reminder med mall (1, 2, eller 3).
6. Logga: gnubok registrerar automatiskt att påminnelsen skickats.

Mallar för påminnelse 1, 2 och 3 sätter du upp i gnubok-UI. Make-flödet refererar bara till mallnamnet ("vänlig-1", "med-avgift", "sista-innan-inkasso").

Slutkostnad: gratis på n8n self-hosted, ~100 kr/mån på Make.

Nivå 2: Python-bot (en dag)

För användare som vill ha mer logik (smart eskalering, kund-specifika regler, integration med Slack-notiser).

import requests
from datetime import date, timedelta

API = "https://app.gnubok.se/api"
TOKEN = "din-token"
HEADERS = {"Authorization": f"Bearer {TOKEN}"}

SEKVENS = [
    {"days_overdue": 1, "template": "vanlig-1", "fee": 0},
    {"days_overdue": 8, "template": "med-avgift", "fee": 60},
    {"days_overdue": 16, "template": "sista-innan-inkasso", "fee": 60},
    {"days_overdue": 24, "template": None, "action": "flag_manual"},
]

def get_overdue_invoices():
    r = requests.get(f"{API}/invoices/ar", params={"status": "overdue"}, headers=HEADERS)
    return r.json()["invoices"]

def days_since_due(invoice):
    due = date.fromisoformat(invoice["due_date"])
    return (date.today() - due).days

def last_reminder_step(invoice):
    actions = [a for a in invoice["dunning_actions"] if a["type"] == "reminder_sent"]
    return len(actions)

def next_step_due(invoice):
    days = days_since_due(invoice)
    sent = last_reminder_step(invoice)
    if sent >= len(SEKVENS):
        return None
    next_threshold = SEKVENS[sent]["days_overdue"]
    return days >= next_threshold

def send_reminder(invoice, step):
    config = SEKVENS[step]
    if config["template"] is None:
        # Sista steget: flagga för manuell hantering
        requests.post(
            f"{API}/invoices/{invoice['id']}/flag",
            json={"reason": "manual_followup_required"},
            headers=HEADERS,
        )
    else:
        requests.post(
            f"{API}/invoices/{invoice['id']}/send-reminder",
            json={"template": config["template"], "fee": config["fee"]},
            headers=HEADERS,
        )

# Huvudloop
for invoice in get_overdue_invoices():
    if next_step_due(invoice):
        step = last_reminder_step(invoice)
        send_reminder(invoice, step)
        print(f"Sent step {step+1} for invoice {invoice['number']} ({invoice['customer']})")

Cirka 50 rader plus mallnamn. Schemalägg som cron eller systemd-timer. Skicka summering till Slack i slutet om du vill ha synlighet.

Nivå 3: MCP-agent via Claude (en kväll, mer dynamik)

Om du redan har gnubok MCP-server kopplad (se MCP-server för bokföring) kan du köra dunning som en MCP-workflow:

Schemalagd prompt till Claude varje morgon:
> Stäm av kundreskontran. Identifiera förfallna fakturor.
> Skicka påminnelser enligt vår sekvens (1, 8, 16, 24 dagar).
> Sammanfatta vad du har gjort i ett kort meddelande till #finance i Slack.

Claude kallar gnubok_get_ar_ledger, gnubok_list_invoices, gnubok_send_invoice för respektive påminnelse. Du godkänner i batch om medel-risk-godkännande är aktiverat. Allt loggas i audit-loggen.

Fördelen: agenten kan göra mer dynamiska bedömningar. "Den här kunden brukar betala på dag 35, hoppa över påminnelse 1 och vänta till dag 14 innan första utskick." Det skulle vara mycket logik i nivå 2 men är trivialt i prompten på nivå 3.

Nackdelen: kostar lite mer per körning (Claude API-tokens) och kräver att MCP-kopplingen är väl konfigurerad.

Vad du behöver i din kontoplan

Inget exotiskt. Men för att räkna effekt:

• 1510: kundfordran (där dina utestående fakturor ligger)
• 3590: påminnelseavgifter (intäkt från avgifter)
• 3591: dröjsmålsränta (om du tar ut)
• 6360: konstaterad kundförlust (för fakturor som aldrig betalas)

Om du saknar något av dessa: lägg till dem. BAS 2026 har dem som standard.

Mått som spelar roll

Sex veckor efter att agenten körts mätbart:

• Genomsnittlig betalningstid (DSO): bör sjunka 5–15 dagar för typiska B2B-kunder, mer för B2C.
• Aktiv kapitalbindning: total summa av förfallna fakturor över 30 dagar. Bör sjunka 30-50%.
• Inkasso-eskalering: ska ligga oförändrat eller marginellt högre. Om det rusar är något fel med påminnelsesekvensen (t.ex. för tighta intervall).
• Kundklagomål: ska vara nästan noll. Om kunder börjar klaga på "för aggressiva påminnelser" är mallen för hård. Mjuka upp.

Tre saker att tänka på

Innehåll i mallen. Påminnelse 1 ska vara informativ och vänlig. Påminnelse 2 ska vara tydlig och nämna avgiften. Påminnelse 3 ska vara strikt och nämna inkasso. Inte tvärtom.

Pause-funktion för enskilda kunder. Vissa kunder har en konstig betalningscykel (kvartalsfaktura, godkännandeflöde med tre veckors fördröjning). Sätt en flagga på de kunderna att hoppa över första påminnelsen. gnubok stödjer detta via en dunning_strategy-fält per kund.

Helger och högtider. Schemalägg agenten att inte köra på helger eller storhelger. Inget värre än att kunder får påminnelse 09:00 första juldagen. Make/n8n har inbyggda calendar-villkor; för Python-versionen lägg till en check mot ett kalenderbibliotek.

Värt att förstå om dunning-strategi i stort

Påminnelser är inte ett straff. De är information. Många kunder glömmer faktiskt, särskilt om fakturan landade i ett semestermejl. En vänlig påminnelse efter 1 dag löser 60–80 procent av sena betalningar utan friktion.

Friktion uppstår vid påminnelse 2 (med avgift) och påminnelse 3 (med inkasso-hot). Det är där kunder börjar bråka. Och det är där de borde börja bråka, om de har anledning. Om en kund hör av sig efter påminnelse 2 och säger "vi har en disput om leveransen" så är det en värdefull konversation. Du vill veta det.

Vad du gör nu

Tre steg:

1. Definiera din sekvens. Vilka dagar, vilka mallar, vilka avgifter. 30 minuter i ett dokument med en penna.
2. Skapa mallarna i gnubok. Inställningar, Fakturamallar, Påminnelser. Skriv tre mallar, en per steg. 30 minuter.
3. Sätt upp agenten. Make-flöde, Python-script, eller MCP-prompt. En eftermiddag.

Sex veckor senare ska du ha 30–50 procent mindre i utestående förfallen kapitalbindning. Det är vanligen 30 000–150 000 kr i kassan som du tidigare hade utestående.

Det är vad Bokföringen som tillväxtmotor menar med att bokföringen är aktiv, inte rapporterande. Dunning är det enklaste exemplet på samma idé.

Den dåligaste tiden att bygga det här är när du upptäcker att hälften av reskontran är förfallen. Den bästa är nu.

Vanliga frågor

Vad är dunning?

Engelsk term för aktiv inkrävning av förfallna fakturor. På svenska används vanligen 'kravhantering' eller 'påminnelseprocess'. Dunning-agent är samma sak fast automatiserat: ett system som varje dag identifierar förfallna fakturor och vidtar åtgärder enligt en mall, utan att en människa behöver tänka på det.

Är det lagligt att skicka påminnelser automatiskt?

Ja. Inkassolagen reglerar vad du får skriva och hur du får eskalera, inte om en människa eller maskin skickar mejlet. Standardpraxis: påminnelse 1 utan avgift, påminnelse 2 med påminnelseavgift 60 kr, sedan inkasso. Allt detta kan en agent göra.

Behöver jag betala dröjsmålsränta-modulen?

Beror på din strategi. För B2B-kunder är det vanligare att skicka påminnelser utan ränta tills inkasso. För B2C kan dröjsmålsränta automatiseras enkelt. gnobok har inbyggd dröjsmålsränteberäkning enligt räntelagen om du aktiverar det.

Vad händer om kunden bråkar tillbaka?

Agenten ska aldrig svara på inkommande mejl. Den skickar bara utgående påminnelser enligt schema. Inkommande kundkontakter går till en människa. Det är hur du undviker att en agent ska ta diplomatiska beslut den inte borde.

Hur ofta körs agenten?

En gång per dag, vanligen morgon. Den läser reskontran, identifierar förfallna fakturor, kollar var de står i påminnelsesekvensen, och skickar nästa steg om dagsavståndet är rätt. Slutar köras på helger eller vid förkonfigurerade pauser (semester, högtider).