Aanmaningsagents: onze AR-audit voor we een offerte sturen

Een operations lead bij een Rotterdamse logistiek-broker stuurt ons een Google Sheet. 412 regels. Kolom F heet "Dagen te laat". Kolom G heet "Laatste herinnering". In de mail staat: "Kun je een agent bouwen die dit afhandelt, zodat mijn team er niet elke donderdag mee kwijt is?"

Ons antwoord is altijd ja. Maar nooit nu meteen.

Voor we ook maar één euro offreren, auditen we de data onder die spreadsheet. Niet omdat we de operations lead niet vertrouwen. Wel omdat een aanmaningsagent die op foute AR-data draait sneller schade aanricht dan een vermoeide mens ooit kan. De checklist hieronder is degene die we doorlopen voor we een getal op de offerte zetten.

Waarom de audit voor de offerte komt

Een aanmaningsagent is een versterker van vertrouwen. Hij stuurt nette, goed getimede, accuraat geschreven berichten naar je klanten, op basis van wat jij hem aan input geeft. Als de data zegt dat een klant 47 dagen te laat is, schrijft de agent alsof die klant 47 dagen te laat is. Als die klant in werkelijkheid twee weken geleden heeft betaald via een bankrekening die niemand heeft afgeletterd, heb je een boze klant en een ongemakkelijk gesprek met je CFO.

De agent zelf is het simpele deel. Op het moment van schrijven hebben we er veertien in productie draaien. Het werk dat de fee waard is, gebeurt voor de agent bestaat, op drie plekken waar de data stilletjes met zichzelf in tegenspraak is.

Aging-buckets die liegen

Elk boekhoudpakket spuwt aging-buckets uit. Nul tot 30 dagen, 31 tot 60, 61 tot 90, 90 plus. Ze zien eruit als de waarheid. Dat zijn ze niet.

De eerste vraag die we stellen: vanaf welke datum wordt er geteld? Je krijgt een andere bucket afhankelijk van of het rapport zich richt op de factuurdatum, de vervaldatum, de leverdatum, of de datum waarop de factuur is geopend in het AP-portaal van de klant. We hebben Exact Online-accounts gezien waar twee derde van de "60+ dagen"-bucket facturen waren die de klant negen dagen geleden had ontvangen, omdat het ERP standaard aging deed op factuurdatum terwijl de afgesproken betaaltermijn netto-90 was. Een agent die op die data aanmaningen stuurt, zou op elke regel fout zitten.

De tweede vraag: zit er iets in de bucket dat al betaald is? Deelbetalingen produceren spookfacturen op drie manieren. Een factuur van €1.800 met een deelbetaling van €1.200 kan nog steeds als €1.800 openstaand staan als de betaling is gematcht aan een creditnota in plaats van aan de factuur. Bulkbetalingen die tien facturen dekken maar als één bankregel binnenkomen, laten er negen openstaan tot iemand ze handmatig splitst. Creditnota's die op het verkeerde factuurnummer zijn geboekt, blijven voor eeuwig in de bucket hangen.

De derde vraag: wie bepaalt wanneer een factuur wordt geannuleerd? Bij een Belgische klant met een Magento-plus-Twinfield-setup konden sales reps een factuur "void" zetten in de CRM, maar die void synchroniseerde nooit naar Twinfield. Het aging-rapport bleef negen maanden lang voided facturen aanmanen. Klanten werden geïrriteerd. Niemand merkte het op totdat we de audit deden.

Geschilredenen die nooit het systeem hebben gehaald

Open een willekeurig AR-systeem en kijk naar het dispute-veld. Het is bijna altijd leeg, of het staat op een waarde als "algemeen geschil". Open nu de customer service inbox en zoek op de zin "we gaan dit niet betalen". Je vindt tientallen geschillen die nooit in het systeem van administratie zijn beland.

Dit is de tweede plek waar een aanmaningsagent dingen kapot maakt. Geschillen leven op vijf plekken die we standaard nakijken:

• Het dispute- of hold-veld van het boekhoudpakket, dat meestal leeg is.
• De customer service inbox (Front, Help Scout, Zendesk, of een gedeelde Gmail-label).
• Notities van sales reps in de CRM, vaak een vrij "Laatste contact"-veld.
• Het AP-portaal van de klant zelf, waar ze facturen soms markeren als "in review".
• Slack- of Teams-DMs tussen de klant en hun accountmanager.

De eerste vier kunnen we bereiken via een integratie. De vijfde niet, maar we vragen er altijd naar. Als accountmanagers geschillen in DMs afhandelen en ze nooit opschrijven, zal geen enkele agent ze opvangen, en heb je een procesfix nodig voor automatisering, niet erna.

Wat we met de audit-output doen: elke factuur in de aanmaningsqueue krijgt een dispute-risk-vlag. De agent stuurt nooit een stevige herinnering naar een klant met een open thread bij support, of met een "niet aanmanen"-notitie van sales. Staat de vlag aan, dan gaat de factuur naar een handmatige review-queue. Deze ene regel heeft meer relaties gered dan welke slimme copy we ook ooit hebben geschreven.

De bank-feed gap die niemand documenteert

Dit is degene waar niemand het over heeft, en het is waar de meeste aanmaningspilots stilletjes sneuvelen in productie. De vraag is simpel: hoe weet je boekhoudsysteem dat een factuur is betaald?

Bij de meeste van onze klanten is het antwoord een bank feed. De bank stuurt een afschriftbestand (meestal CAMT.053 over ISO 20022 in de EU) dat 's nachts of op een schema in het boekhoudpakket binnenkomt. Het pakket probeert elke regel automatisch te matchen aan een openstaande factuur. Wat niet matcht, valt in een tussenrekening, waar uiteindelijk een mens het aflettert.

De gap is het venster tussen "geld binnen" en "factuur gemarkeerd als betaald". Bij sommige klanten is dat venster twaalf uur. Bij andere negen dagen. We meten het voor we offreren, omdat het aanmaningsschema van de agent het moet respecteren.

De bank-feed gap heeft vier veelvoorkomende faalmodi. Eén, deelbetalingen: de klant heeft €4.200 betaald om drie facturen van elk €1.400 te clearen, maar de bankregel toont één afrekening van €4.200 die de auto-matcher niet kan splitsen. Twee, netting door payment processors: Stripe-payouts, Mollie en Adyen rekenen allemaal netto van fees en refunds af, dus een factuur van €1.000 produceert een storting van €972,40 die de matcher misloopt. Drie, FX-conversie: een USD-factuur die in EUR wordt betaald, komt binnen op een omgerekend bedrag dat afwijkt van het geboekte totaal door de spread van die dag. Vier, weekend- en feestdagenbatching: een betaling op vrijdag staat soms pas dinsdag op de feed.

Elk van deze geeft hetzelfde risico. De agent maant een klant aan die al heeft betaald. Daar kom je niet meer van terug. De klant vergeet het niet. Dus we vragen altijd twee getallen op voor we offreren: de mediane bank-feed gap en de 95e percentiel. Het aanmaningsschema start na de 95e percentiel, niet de mediaan.

Wat we terugsturen voor we offreren

De audit kost ons ongeveer drie werkdagen. Het deliverable is een rapport van één pagina met drie getallen: hoeveel facturen in de huidige openstaande AR verkeerd zijn gelabeld door de aging-bucket, hoeveel er een verborgen geschil hebben dat het administratiesysteem niet kent, en hoe de bank-feed gap op 95e percentiel eruitziet. Onder de getallen staan de drie of vier procesfixes die de klant moet doorvoeren voor de agent het bouwen waard is.

Ongeveer een kwart van de tijd raden we de klant aan de agent nog niet te bouwen. Het aanmaningswerk verbergt in die gevallen een duurder probleem stroomopwaarts. Een spreadsheet van 412 aanmaningsregels is geen aanmaningsprobleem, het is een factuur-dataprobleem met aanmanen als symptoom. De factuur-data fixen heeft meer hefboom, en dat zeggen we ook.

De andere drie kwart geeft de audit ons een schoon genoeg beeld om te offreren. Toen we de aanmaningsagent bouwden voor de Rotterdamse broker die we bovenaan noemden, was het bijna de bank-feed gap die de pilot om zeep hielp: hun tussenrekening had gemiddeld elf dagen nodig om te clearen, en de aanmaningstemplate zou in de eerste week een dozijn klantrelaties hebben verbrand. We hebben de agent uiteindelijk rechtstreeks op het CAMT.053-bestand aangesloten, zodat hij geclearde betalingen eerder zag dan het boekhoudpakket. Dat soort fix is normaal in AI-agent-werk, en daarom komt de audit eerst.

Een versie van vijf minuten die je vandaag kunt draaien

Open je aging-rapport en je customer service inbox in twee vensters. Pak willekeurig tien facturen uit de 60+ dagen-bucket. Beantwoord voor elk drie vragen: vanaf welke datum wordt hij geaged, zit er een geschillenthread in de support inbox, en is er in de laatste 30 dagen een betaling op binnengekomen? Als meer dan twee van de tien op een van die drie assen fout zitten, is je AR-data nog niet klaar voor een agent. Die gap is het werk voor dit kwartaal.