Je crediteurenstroom controleert het bedrag, niet de tenaamstelling

Sinds 9 oktober 2025 kijkt je bank bij een euro-overboeking of de naam van de ontvanger bij het rekeningnummer hoort. Bij precies de betalingen waarmee jij je leveranciers betaalt, hoeft dat niet. Lever je meerdere opdrachten als één bestand aan, en dat is wat elk boekhoudpakket doet, dan mag die controle eruit. Dat is geen gaatje in de uitvoering. Zo staat het in de verordening.

Dat gat is er niet omdat iemand het heeft gemaakt. Het is er omdat vrijwel niemand doorhad dat de controle bestond.

De controle op het rekeningnummer was in de meeste bedrijven namelijk nooit een processtap. Ze was een bijproduct van het overtypen. Iemand las een IBAN van een factuur, tikte hem over in het betaalscherm en zag daarbij dat hij anders was dan vorige maand. Haal die handeling weg en de controle verdwijnt mee, zonder dat iemand hem heeft afgeschaft en zonder dat het ergens genotuleerd staat.

Mijn stelling over geautomatiseerde crediteurenverwerking is dus scherper dan "let op factuurfraude". Ze is deze: automatisering lost het overtypen op en levert uit zichzelf nul fraudeweerstand op ten opzichte van de handmatige situatie. Wat ze wel oplevert is snelheid, en snelheid is precies wat een vervalst rekeningnummer nodig heeft.

De keten beantwoordt één vraag, en dat is de andere niet

Een moderne crediteurenstroom is niet ongecontroleerd. Integendeel: er zitten meer controles in dan in de ordner met papieren facturen van tien jaar geleden. De software leest leverancier, factuurnummer, bedrag en btw uit de PDF. Werk je met bestellingen, dan legt een driewegcontrole de inkooporder, de goederenontvangst en de factuur naast elkaar voordat er iets betaalbaar wordt. Boven een drempelbedrag tekent een tweede persoon. Kleine prijsverschillen vallen binnen een tolerantie, grote worden een uitzondering op iemands bureau.

Al die controles beantwoorden dezelfde vraag: klopt deze factuur? Klopt het bedrag, klopt de btw, is dit besteld, is dit geleverd, mag deze persoon hiervoor tekenen. Het is een goed antwoord op een goede vraag, en welke laag je daarvoor nodig hebt hangt vooral af van je factuurvolume en je boekhoudpakket, niet van de featurelijst van een tool.

Er is alleen een tweede vraag, en die stelt niemand: gaat dit geld naar deze leverancier? Een factuur kan tot op de cent kloppen, netjes matchen met de order, keurig binnen het mandaat vallen en toch landen op een rekening die drie weken oud is.

In software is een rekeningnummer geen waarde, maar een sleutel

Kijk hoe een pakket zo'n nummer eigenlijk behandelt. Moneybird analyseert de bijlage van een inkoopfactuur en zoekt het bijbehorende contact op KVK-nummer, btw-nummer, IBAN, e-mailadres, adres en telefoonnummer. Het rekeningnummer helpt dus vooral bij de vraag van wie deze factuur is. Zet je daarna de betaling klaar, dan vult het pakket het IBAN, de naam, het bedrag en de omschrijving over uit die factuur.

Dat is geen fout in Moneybird, en het geldt net zo goed voor de zwaardere pakketten. Het is de logica van elke uitleeslaag: velden worden geëxtraheerd om een document te plaatsen en een boeking te vullen, niet om ze te wantrouwen. Een AI die facturen verwerkt dwing je daarom in een vast schema met leverancier, factuurnummer, IBAN, datum, bedrag en btw als verplichte velden. Uitlezen is alleen geen verifiëren. Een veld dat je extraheert heb je nog niet gecontroleerd, en een nummer dat als sleutel dient wordt zelden als bewering behandeld.

Zo verhuist het rekeningnummer van de factuur naar het betaalbestand zonder dat er ergens een vraagteken achter is gezet.

De naamcontrole waarvan je aanneemt dat je bank hem doet

Hier zit het misverstand dat ik het vaakst tegenkom, en het is een begrijpelijk misverstand. De IBAN-Naam Check is voor Nederlandse betalers al jaren vanzelfsprekend, en sinds de Europese verordening voor instant betalingen moet elke betaaldienstverlener in de eurozone die verificatie aanbieden. Bij een gewone digitale overboeking draait ze mee zonder dat je er iets voor doet.

Voor zakelijke bulkbestanden schrijft diezelfde verordening iets anders voor. Artikel 5c(6) verplicht betaaldienstverleners om gebruikers die geen consument zijn juist een manier te geven om die verificatie uit te zetten zodra ze meerdere betaalopdrachten als pakket aanleveren. De European Payments Council, die het onderliggende schema beheert, vat de gevolgen droog samen: bedrijven zijn niet verplicht deze diensten te gebruiken en kunnen zich voor bulkbestanden afmelden. De verwerking van zo'n controle over een bulkbestand valt buiten het schema zelf, en de aansprakelijkheid blijft hoe dan ook bij de zakelijke betaler liggen.

In de praktijk zie je dat terug in je bankomgeving. Rabobank biedt zakelijke klanten een aparte IBAN-Naam Checker aan waarin je je betaalbestand uploadt, en schrijft er zelf bij dat je niet verplicht bent die controle te gebruiken en bij betaalbestanden zelf bepaalt of je vooraf controleert. Het gecontroleerde bestand wordt niet automatisch verwerkt: je downloadt de afwijkingen als CSV, past ze met de hand aan in je boekhoudprogramma en stuurt het bestand daarna alsnog in. Kies je ervoor geen controle te doen of negeer je een waarschuwing, dan ben je zelf verantwoordelijk als het geld bij de verkeerde ontvanger landt.

Lees dat rustig terug. De enige systemische controle op de ontvanger is bij zakelijke bulkbetalingen een los product, in een los scherm, met een aparte autorisatie, waarvan de uitkomst met de hand terug moet naar het pakket waar je net al het handwerk uit hebt gehaald. Dat is geen controle die een geautomatiseerde stroom overleeft. Dat is een controle die er structureel uit valt.

Om eerlijk te zijn: dit is geen epidemie

De sterkste tegenwerping is niet dat het gat niet bestaat, maar dat het zelden wordt gebruikt en dat de geautomatiseerde stroom per saldo veiliger is dan wat ervoor zat. Dat argument verdient meer krediet dan het meestal krijgt.

De cijfers zijn ook geen ramp. De Fraudehelpdesk telde over 2025 aan de zakelijke kant 327 meldingen van CEO-fraude en 1.146 van acquisitiefraude, met misbruik van bedrijfsgegevens als hoogste schadepost op 286.000 euro. Dat is heel Nederland, in een heel jaar. Wie op basis daarvan besluit dat zijn veertig facturen per maand geen extra poort nodig hebben, redeneert niet gek. En de geautomatiseerde keten is echt beter dan de schoenendoos: alles is gelogd, de leverancier staat één keer vast in plaats van in vijftien mailtjes, en een factuur blijft niet meer twee maanden onder een stapel liggen.

Twee dingen breken dat argument. Het eerste is dat een logboek geen controle is. Het vertelt je achteraf wie het rekeningnummer wijzigde, niet vooraf of die wijziging klopt. Forensiek is prachtig als je weet dat je moet zoeken, en bij een geslaagde betaling weet niemand dat.

Het tweede is de vorm van het risico. Dit is geen frequentierisico maar een staartrisico: het gebeurt zelden, en dan in één keer, voor het bedrag van een echte factuur, aan een leverancier die je echt hebt. Het Amerikaanse IC3 registreerde over 2025 in deze categorie 24.768 meldingen en ruim 3 miljard dollar schade, gemiddeld ruim een ton per melding, en dat gaat vrijwel altijd over precies dit patroon: gekaapt mailverkeer met een leverancier en een gewijzigde betaalinstructie. Een controle die je zelden nodig hebt maar die dan alles scheelt, weeg je niet af tegen de kans. Je weegt hem af tegen zijn kosten, en die zijn hier bijna nul.

Een gewijzigd rekeningnummer is een mutatie, geen factuurveld

Dat laatste is de kern. Zolang je het rekeningnummer als een veld op een factuur ziet, moet je het bij iedere factuur opnieuw controleren, en dan is elke controle te duur. Behandel je het als wat het is, een mutatie op je crediteurstamgegevens, dan controleer je het één keer per wijziging. Een leverancier verandert misschien eens in de vijf jaar van bank. Dat zijn een paar momenten per jaar, ook bij honderden facturen per maand.

De zwaardere pakketten hebben die vorm al ingebouwd, wat me sterkt in het idee dat het de juiste vorm is. AFAS beschrijft het toevoegen en wijzigen van bankrekeningen bij crediteuren expliciet als een proces onder het vier-ogen-principe, waarbij een crediteur pas betaald kan worden zodra de gewijzigde bankrekening is gecontroleerd en goedgekeurd. In Visma.net zit er een schakelaar voor in de functionaliteit: zet je het vierogenprincipe bankgegevens aan, dan wordt een vastgelegde bankrekening pas vrijgegeven voor betalingen zodra een tweede gebruiker hem goedkeurt, in een eigen scherm waarin alle crediteuren met een nieuwe of gewijzigde rekening op je wachten. In beide gevallen is niet de factuur het onderwerp van de goedkeuring, maar de wijziging.

Dat is een ander soort controle dan de goedkeuringsflow die je al hebt. Een mandaatschema toetst een bedrag tegen een bevoegdheid. Een mutatiestroom toetst een verandering tegen de werkelijkheid, en vraagt om bevestiging langs een ander kanaal dan waar het verzoek binnenkwam. Een telefoontje naar een nummer dat je zelf al had, dus niet naar het nummer onderaan die mail.

Hetzelfde patroon zag ik bij vertrekkende medewerkers: een account uitzetten trekt niet in wat die medewerker zelf aan koppelingen en tokens heeft uitgegeven, omdat die uitgifte nooit als eigen gebeurtenis werd vastgelegd. De oplossing is ook daar geen extra vinkje op een checklist, maar een moment dat je expliciet maakt op de plek waar het ontstaat.

Wat automatisering erft, en wat ze weggooit

Elke automatisering neemt de expliciete stappen over en laat de impliciete liggen. Wat iemand ooit heeft opgeschreven komt mee: goedkeuren, matchen, boeken, archiveren. De controles die niemand ooit opschreef omdat ze nu eenmaal in de handeling zaten, komen niet mee. Ze verdwijnen stil, en het duurt vaak jaren voor iemand merkt dat ze weg zijn.

Dat is geen argument tegen automatiseren. Het is een ontwerpvraag die je bij elke weggehaalde handeling één keer moet stellen: welke controle deed deze mens hier per ongeluk? Bij het overtypen van een inkoopfactuur is het antwoord bekend. Iemand keek naar het rekeningnummer. Nu niemand meer overtypt, moet dat kijken ergens anders staan, met een naam, een eigenaar en een moment. Anders is het enige wat er van die controle over is de aanname dat ze er nog is.