De fleste økonomiafdelinger har adgang til kreditdata. Færre har dem der, hvor beslutningen faktisk bliver truffet.
Kreditvurderingen ligger i én fane. Leadet ligger i CRM (jeres salgssystem). Ordren ligger i ERP-systemet (jeres økonomi- og ordresystem). Og mellem dem sidder et menneske, der skal huske at slå op, inden ordren bliver frigivet. Ikke tre uger efter.
Problemet er sjældent mangel på data. Det er placeringen, der er problemet.
Denne guide handler om kreditvurdering i ERP og CRM: hvordan I flytter kreditdata ind i arbejdsgangen, hvad I kan automatisere, hvad der stadig kræver et menneske, og hvordan de tre veje ind (Connect, API og MCP) spiller sammen i stedet for at konkurrere.
Hvorfor kreditvurdering hører hjemme i ERP og CRM, ikke i et faneblad ved siden af
En kreditvurdering, der bor i en separat portal, er et manuelt opslag. Den afhænger af, at nogen husker at slå op, og husker det på det rigtige tidspunkt. Det holder sjældent, og det koster på tre måder.
Timingen skrider. I tjekker kunden ved oprettelsen. Men risikoen opstår ikke ved oprettelsen. Den opstår 14 måneder senere, når kunden har mistet sin største aftale, har fået ny ledelse og pludselig bestiller for det dobbelte. Konkursrisiko er ikke et tal, I aflæser én gang og lægger i mappen. Den bevæger sig hele tiden i baggrunden, og kunden blev godkendt i en anden virkelighed.
Dækningen bliver skæv. Mennesker slår de store kunder op. De slår ikke de 3.000 små op. Virksomheder taber sjældent penge på den kunde, alle holder øje med. De taber dem i halen, hvor ingen kigger.
Konsistensen forsvinder. To kollegaer, samme kunde, to forskellige konklusioner, fordi kreditpolitikken lever i hovederne og ikke i et system med en fast, afstemt proces. Det er ikke sløseri. Det er, hvad der sker, når en regel ikke er skrevet ned et sted, hvor den kan køre af sig selv, eller bare ligger i skuffen.
Regnestykket bagved er ubarmhjertigt. Med en overskudsgrad på 5 % skal I sælge for 2 mio. kr. ekstra for at dække et enkelt tab på 100.000 kr. Kreditarbejde er ikke en administrativ funktion. Det er et af de få steder i huset, hvor en times arbejde kan være flere millioner værd på toplinjen.
Pointen er ikke, at I skal have mere data. Pointen er, at beslutningen skal træffes baseret på det rigtige datagrundlag, på det rigtige tidspunkt, det sted hvor arbejdet i forvejen foregår.
Hvad kan I automatisere, og hvad kræver stadig et menneske?
Den ærlige version, for ikke alt bør automatiseres, og det er en dårlig idé at lade som om.
Princippet er enkelt: automatisér det gentagne og objektive. Reservér mennesker til undtagelser og afvejninger.
En god integration gør ikke jeres kreditansvarlige overflødig. Den fjerner de 90 % rutineopslag, så der er tid til de 10 %, der faktisk er svære, og som er dem, der afgør, om året ender med et plus eller et minus på bundlinjen.
Kreditvurdering i CRM: Stop den dårlige aftale, før den bliver solgt
Salg skaber risikoen. Økonomi arver den. Det er ikke ond vilje. Det er rækkefølgen. Når kreditvurderingen først sker efter underskriften, er samtalen allerede tabt: enten siger I nej til en aftale, sælgeren har brugt to måneder på, eller også siger I ja til noget, I ikke burde.
Løsningen er ikke at bremse salget. Det er at flytte beslutningsgrundlaget frem i processen.
Sådan ser det ud i praksis:
- Emnet oprettes automatisk med alle stamdata fra CVR, uden manuel indtastning og uden dubletter
- Kreditvurderingen sker allerede ved oprettelsen, så sælgeren kan se med det samme, om emnet overholder jeres kreditpolitik, og ikke spilder sin tid
- Score, kreditmaks og alt andet relevant står på virksomhedskortet, så snart emnet er oprettet
- Betalingsbetingelser kan læses direkte af sælgeren, mens kunden er i røret
- Tilvalg: En ordre, der ikke overholder kreditpolitikken, kan ikke godkendes uden tilladelse oppefra
Fortæl Salg, hvad de får ud af det. Det her er ikke en håndbremse. Det er prioritering. Sælgeren bruger sin tid på de aftaler, der bliver betalt, og slipper for at love betalingsbetingelser, som Økonomi ruller tilbage en uge senere. „Jeg vender tilbage“ bliver til „det kan vi godt“. Det er en bedre salgsoplevelse, ikke en dårligere.
Det er også her, siloen mellem salg og økonomi rent faktisk forsvinder: ikke ved et månedligt møde, men ved at de to afdelinger for første gang kigger på det samme tal på samme tidspunkt.
Kreditvurdering i ERP: Kreditmaks, ordreblokering og løbende overvågning
CRM er der, hvor risikoen først opstår. ERP er der, hvor pengene rent faktisk bevæger sig. Fem mekanismer bærer det meste af værdien:
- Datavask og løbende opdatering af stamdata. Det er det kedelige punkt, og det er dér, værdien starter. Ved oprettelse hentes navn, adresse, CVR-nummer og selskabsform direkte fra registret, så debitorkartoteket ikke fyldes med tastefejl og dubletter. Bagefter holdes stamdata opdaterede af sig selv: flytter kunden, skifter den navn eller ophører den, slår det igennem i ERP-systemet uden at nogen retter i hånden.
- Kreditmaks pr. debitor, sat af politikken. Ikke et tal, nogen skrev i 2021. Et tal, der følger af jeres regler og opdateres, når grundlaget ændrer sig.
- Blokering eller advarsel på ordreniveau. Ordren overstiger maks, eller kundens score er faldet under jeres tærskel, og systemet reagerer i selve ordreflowet frem for i en rapport ugen efter.
- Løbende virksomhedsovervågning af alle debitorer. Konkursbegæringer, ledelsesskift, ejerskifte, betalingsanmærkninger, nye regnskaber. Kundeporteføljen bliver tjekket hele tiden, ikke én gang om året.
- Ekstern risiko holdt op mod jeres egen betalingshistorik. Det her er den vigtigste, og den, mange springer over.
Den bedste kreditvurdering er ikke den eksterne score alene. Det er den eksterne score set sammen med, hvordan kunden rent faktisk betaler jer. Jeres aldersfordelte saldoliste er det stærkeste signal, I har, og ingen andre har det. En kunde med pæn score, der er begyndt at betale 20 dage for sent hos jer, er en anden historie end den samme score hos en kunde, der altid betaler til tiden.
Når begge dele bor i ERP-systemet, kan de holdes op mod hinanden automatisk. Når de bor hvert sit sted, bliver de det sjældent eller aldrig.
Rækkefølgen der virker: overvågning først, integration bagefter
Her er et mønster, der går igen hos de virksomheder, der får mest ud af kreditdata, og som er værd at kopiere.
De starter ikke med et integrationsprojekt. De starter med overvågning på den eksisterende debitorliste, fordi det kan sættes op på en eftermiddag og med det samme viser, hvor mange af deres kunder der faktisk overholder kreditpolitikken, og hvor mange der bevæger sig. Derefter udvider de: flere overvågede virksomheder, flere brugere, og typisk flere lande, når det går op for dem, at den svenske, norske eller tyske del af porteføljen aldrig er blevet vurderet efter samme målestok.
Først dér kommer integrationen. På det tidspunkt er den nem at beslutte, fordi alle i huset allerede kender tallene og kan se, hvad det koster at slå dem op manuelt, eller slet ikke slå dem op.
Den omvendte rækkefølge er den dyre. Et integrationsprojekt, der starter som et it-projekt uden at nogen i Økonomi har brugt data endnu, bliver en skrivebordsøvelse, en prioriteringsdiskussion og en udskydelse til næste kvartal. Vi har set den slags tage flere år om at komme i gang. Ikke fordi teknikken er svær, men fordi ingen kan svare på, præcis hvilken værdi det skaber.
Anbefalingen er enkel: kør overvågning et par måneder først. Så ved I, hvad integrationen skal indeholde, før I installerer den.
Og en advarsel i samme åndedrag: en integration uden en politik og en arbejdsgang omkring sig bliver et datadump. Data lander i systemet, ingen ændrer adfærd, og når kontrakten skal fornyes, kan ingen forklare, hvad den gjorde godt for. Tag stilling til, hvilke beslutninger data skal ændre, før I trækker dem ind.
Tre veje ind: Connect, API og MCP
Integration af kreditdata bliver ofte stillet op som et enten-eller mellem de tre. Se dem nærmere som lag, hvor de fleste ender med to af dem.
De to sidste rækker er hele pointen, og de er værd at læse to gange.
En automatisk integration er deterministisk. Samme kunde, samme regler, samme svar, hver gang, for hele porteføljen og med et revisionsspor. Det er dét, der må blokere en ordre eller sætte en kreditramme.
En AI-assistent er ikke deterministisk. Den formulerer sit svar på ny, hver gang. Det gør den fremragende til at undersøge, sammenligne og forklare. Og uegnet til at være den instans, der siger nej til en ordre.
Automatiseringen træffer beslutningen. Assistenten forklarer den.
Hvilke systemer taler vi om?
I praksis er det mange af de samme systemer, der går igen hos danske og nordiske virksomheder: Microsoft Dynamics 365 Business Central, SAP, Microsoft D365 F&SCM, SuperOffice CRM, Dynamics 365 Sales, Salesforce, HubSpot, Uniconta og e-conomic. Kører I noget af det, findes vejen ind allerede. Kører I et ældre eller specialbygget system, går vejen typisk gennem API eller SFTP. Det er lige så farbart. Det kræver bare en udvikler til selve implementeringen.
Cocktailen: Jeres ERP-MCP plus Risika MCP
Her bliver det interessant. Flere og flere ERP- og CRM-leverandører udgiver deres egne MCP-servere, så en AI-assistent kan læse jeres egne data. Når både jeres forretningssystem og Risika er tilgængelige for den samme assistent, opstår der en type spørgsmål, intet dashboard besvarer, fordi svaret kræver data fra to systemer på én gang.
To eksempler på, hvad det åbner for:
Genforhandling med en eksisterende kunde. En kunde beder om længere kredittid eller en højere kreditramme. I stedet for at gætte kan I stille ét spørgsmål: hvordan har kunden betalt os de seneste 12 måneder, og hvordan ser deres seneste regnskab og scoreudvikling ud? ERP-systemet leverer betalingshistorikken og det udestående. Risika leverer regnskabet, likviditeten og retningen på scoren. En kunde, der altid betaler til tiden og lige har afleveret et bedre regnskab, kan roligt få mere plads. En kunde, der er begyndt at trække betalingen og samtidig har fået forringet score, skal ikke. Det flytter samtalen fra en mavefornemmelse til et konkret udgangspunkt, og det tager ét spørgsmål frem for en formiddag på tværs af to systemer.
Look-alike-lister ud fra jeres egne vundne aftaler. Tag de kunder ud af CRM, der rent faktisk betaler til tiden, og bed om nordiske selskaber, der ligner dem på branche, størrelse og økonomi. Det interessante er ikke den første liste. Det er, at arbejdet bliver en samtale: I kan stramme kriterierne, fjerne de brancher der ikke passer, lægge et omsætningsinterval på og få listen igen med det samme. Fem gennemløb på en halv time, hvor det før var en eksport, et LOPSLAG() i Excel og en formiddag.
Tre spørgsmål af samme type, som er relevante på økonomisiden:
„Vis mig vores 20 største debitorer efter udestående. Hvem af dem har fået forringet kreditscore de seneste 90 dage?“
ERP leverer det udestående. Risika leverer scoreudviklingen. Krydset findes ingen steder i forvejen.
„Den her kunde blev blokeret i går. Hvorfor, og hvad er vores samlede eksponering mod hele koncernen bagved?“
Risika leverer ejerskabsstrukturen og de tilknyttede CVR-numre. ERP leverer saldi på hvert af dem. Svaret er den reelle eksponering, ikke eksponeringen på ét CVR-nummer.
„Deler nogen af vores kunder direktør eller ejerkreds med et selskab, der er gået konkurs i år?“
Et opslag i person-relationer holdt op mod jeres debitorliste. Klassisk svindelindikator, og i dag et halvdagsprojekt.
Men lad være med at forveksle de to lag. Cocktailen erstatter ikke den automatiske kreditpolitik. Den forklarer den. Automatiseringen kører i baggrunden på hele porteføljen, døgnet rundt, uden at nogen spørger. MCP er til mennesket, der skal forstå en beslutning, forberede et bestyrelsesoplæg eller undersøge en mistanke.
Et praktisk råd: giv assistenten læseadgang, ikke skriveadgang. Den skal kunne læse jeres debitorer. Den skal ikke kunne ændre en kreditramme.
Hvor går grænserne?
En sprogmodel skal ikke sætte kreditmaks. Samme spørgsmål kan give lidt forskellige formuleringer. Det er fint til analyse. Det er ubrugeligt som politik, og det holder ikke i en revision.
Dataadgang er ikke det samme som datastyring. Beslut, hvem der må se hvad, før I åbner adgangen. Kreditoplysninger om virksomheder er ikke persondata, men ejerskabs- og personrelationer rører ved personer. Det kræver en stillingtagen, ikke en antagelse.
Ingen automatisering uden undtagelser. Hvis en sælger ikke kan få en undtagelse behandlet inden for en dag, finder vedkommende en vej uden om systemet. Så har I hverken kontrol eller overblik. Byg proceduren til undtagelser samtidig med reglen, ikke bagefter.
Skidt ind, skidt ud. Hvis jeres debitorkartotek ikke har korrekte CVR-numre, virker ingen af delene. Det er kedeligt, og det er første skridt.
Revisionsspor. En beslutning, der blokerer en ordre, skal kunne dokumenteres: hvorfor, på hvilke data, hvornår. Deterministiske integrationer giver det. En chatlog gør ikke.
Sådan kommer I i gang
- Ryd op i stamdata på debitorer. Har I ikke CVR-numre på alle, kan de matches på navn og adresse, eller I kan få lavet en datavask hos jeres dataleverandør. Start her, uanset hvad I ellers gør.
- Sæt overvågning på den eksisterende debitorliste. Det tager en eftermiddag og viser med det samme, hvor meget der bevæger sig i jeres portefølje.
- Skriv kreditpolitikken som regler. Ikke principper, men tærskelværdier. „Score under X giver forudbetaling“ virker. „Vi udviser rettidig omhu“ virker ikke.
- Lad systemet advare i en måned, før det blokerer. I opdager hurtigt, om tærsklerne er sat rigtigt, uden at genere salget imens.
- Integrér, når I ved hvad der skal ind hvor. Automatisér de 80 % standardsager. Hold de store og de skæve manuelle.
- Giv MCP til dem, der analyserer. Økonomichef, kreditchef, controller. Ikke hele huset.
- Mål på noget konkret. Andel af ordrer med gyldig kreditvurdering. Tid fra ordre til frigivelse. Tab i procent af omsætningen. Antal kunder under overvågning. Antal sager med automatisk beslutning.
Nedenfor finder du de to oversigter samlet: hvad I kan automatisere, og hvordan Connect, API og MCP forholder sig til hinanden. Derefter følger svar på de spørgsmål, vi oftest får.
Den rigtige risiko er ikke et sats. Det er en strategi. Og en strategi skal kunne køre af sig selv, også de dage, hvor ingen husker at slå op.