Debiteurenbeheer en kredietlimiet in B2B: krediet bewaken zonder handwerk

Kort antwoord. Debiteurenbeheer en kredietlimiet bewaken in B2B doe je door per klant een limiet vast te leggen op basis van omzet en betaalgedrag, en die automatisch te toetsen aan openstaande posten plus lopende orders. Bij overschrijding blokkeert het systeem de order; aanmaningen gaan vanzelf de deur uit.

In de groothandel lever ik op rekening. Dat is geen luxe maar een voorwaarde om mee te doen: betalingstermijn, kredietlimiet en minimale orderwaarde horen erbij. Het probleem is niet dat ik op rekening lever. Het probleem is dat de bewaking ervan in een spreadsheet leeft die niemand bijhoudt, terwijl een klant ondertussen voor de vierde keer een order plaatst zonder de eerste drie betaald te hebben.

Wat je echt wil: grip op je openstaande posten, niet alleen minder typen

Het doel is niet "tijd besparen op aanmaningen". Het doel is dat ik op elk moment weet wie hoeveel openstaan heeft, wie over zijn limiet zit, en welke order ik beter even niet uitlever. Cijfers die kloppen. Een debiteurenpositie die ik kan vertrouwen als ik mijn kaspositie inschat. En aanmaningen die niet afhangen van of iemand er op vrijdagmiddag aan denkt.

Een kredietlimiet is daarvoor de basis. Volgens Microsoft over Dynamics 365 bestaat de blootstelling per klant uit openstaande facturen plus lopende orders, getoetst aan de limiet. Zodra dat totaal de limiet raakt, hoort er iets te gebeuren. Handmatig gebeurt dat niet, of te laat.

Hoe je een kredietlimiet per klant bepaalt en bewaakt

De limiet zelf is geen mysterie. Een werkbare vuistregel is de verwachte maandafname als basis nemen en daar een marge op zetten, en hem bijstellen op betaalgedrag: goede betalers omhoog, structureel te laat omlaag of vooruit betalen. Kredietverzekeringkosten.nl beschrijft datzelfde principe, plus dat je bij een kredietverzekering tot een bepaald bedrag zelf de limiet mag bepalen mits je goede kredietinformatie gebruikt.

Het bepalen is dus mensenwerk. Het bewaken is dat niet. Bewaken betekent: elke order toetsen aan limiet min openstaand saldo, voordat hij de magazijnvloer raakt. Dat is precies waar het handmatig misgaat, want niemand zoekt dat per order op.

Eerst het proces doorlichten, dan pas bouwen

Voordat ik iets bouw kijk ik naar hoe het nu loopt. Vaak zitten er stappen in die ooit logisch waren en nu alleen ruis zijn. Een aanmaningstermijn van 7, 14 en 30 dagen die in de praktijk nooit gevolgd wordt. Klanten met een limiet die al drie jaar niet is herzien terwijl hun afname is verdubbeld. Een handmatige "akkoord van de eigenaar" op elke order boven een bedrag, terwijl dat akkoord prima een regel kan zijn.

Soms blijkt een stap overbodig. Soms blijkt dat de helft van de uitzonderingen voortkomt uit één klant met afwijkende afspraken. Dat is een bewuste stap, geen excuus om niets te doen. Ik wil weten welk proces ik automatiseer voordat ik het in beton giet, anders automatiseer ik de rommel.

Waarom een standaardpakket vaak net niet past

Een ERP als Microsoft Dynamics 365, AFAS, Exact of AccountView kan kredietlimieten, blokkeringsregels en automatische aanmaningen aan. Voor het gelukspad is dat prima en moet je dat ook gebruiken. Je hoeft geen kredietlogica vanaf nul te bouwen als het pakket dat doet.

De moat zit in de uitzonderingen. Een staffelklant die per productgroep een andere limiet heeft. Een dochteronderneming die op de limiet van de moeder moet meetellen. Een limiet die meebeweegt met seizoen of met openstaande creditnota's. Orders die binnenkomen via een leveranciersportaal of B2B-webshop en die de limiet pas raken nadat ze al bevestigd zijn. Dat soort logica zit zelden netjes in de standaard, en daar bouw ik de koppeling of de tussenlaag die het wel doet: de limiet wordt getoetst op het juiste moment, de blokkering landt op de juiste plek, en de aanmaning gaat uit met de juiste toon per klantsegment.

Aanmaningen die zichzelf versturen

Dynamics, AccountView en vergelijkbare pakketten kunnen openstaande posten op basis van vervaldatum, minimumbedrag en dagen sinds de laatste herinnering markeren en in batch per e-mail aanmanen. Dat is het uitgangspunt. Wat ik er omheen bouw is de beslislogica die jouw pakket niet kent: niet aanmanen als er een dispuut openstaat, een andere toon bij een A-klant dan bij een eenmalige afnemer, en een seintje naar de accountmanager voordat de derde aanmaning eruit gaat in plaats van erna. Het handwerk verdwijnt, de oordeelsvorming blijft waar die hoort.