Rekeningnummer controleren vóór je betaalt: het verificatieproces

Je SEPA-betaalbestand zag er goed uit toen het de afdeling verliet. Dan komen de meldingen binnen. Een leverancier zegt dat de betaling nooit is aangekomen. HR vraagt waarom het salaris van een medewerker is teruggekomen. Iemand ziet dat een leverancier vorige week nieuwe bankgegevens doorgaf, maar niemand weet wie dat heeft goedgekeurd. Tegen de middag zit je team CSV’s te exporteren en IBAN’s met het oog te vergelijken.

Op dat moment is rekeningnummer controleren geen administratieve bijzaak meer, maar kerninfrastructuur van je betaalproces. Een goed proces doet twee dingen tegelijk: het houdt duidelijke fouten buiten je betaalrun, en het bevestigt dat een formeel geldig rekeningnummer ook echt de juiste bestemming is. Dit artikel gaat over dat tweede deel: het verificatieproces vóór je betaalt, van de eerste invoer tot het moment dat je het SEPA-bestand maakt.

Waarom mislukte betalingen meer zijn dan een ongemak

De eerste kosten van een mislukte SEPA-betaling zie je direct: iemand onderzoekt de terugboeking, corrigeert de begunstigde en betaalt opnieuw. De tweede kosten zie je minder snel: finance verliest vertrouwen in de eigen stamgegevens, goedkeurders voegen handmatige controles toe en betaalruns duren langer omdat niemand het bestand nog vertrouwt.

Het gaat meestal mis in gewone situaties. Een nieuwe leverancier mailt een IBAN. Een medewerker wijzigt zijn rekening voor declaraties. Een vaste leverancier stapt na een fusie over naar een andere bank. Elk moment lijkt routine, tot één veld fout is of één verzoek frauduleus.

• Crediteurenadministratie belandt in uitzonderingswerk en bereidt de volgende run niet voor.
• Leveranciers raken geïrriteerd en jagen op facturen die finance als betaald beschouwt.
• Goedkeurders worden trager, ook bij legitieme wijzigingen.
• Het audittrail verzwakt als controles via mail of spreadsheetopmerkingen liepen.

Er is ook een fraudekant. Bij CEO-fraude en valse wijzigingsverzoeken hoeft een aanvaller je betaalsysteem niet te kraken; hij hoeft alleen iemand te overtuigen een leveranciersrecord naar zijn rekening om te zetten. Meer daarover in factuurfraude voorkomen.

Kernpunt: mislukte betalingen komen zelden door één grote systeemstoring. Ze ontstaan door kleine gaten in de controle die zich op schaal herhalen.

Stap 1: de formele controle van het IBAN

Voordat je eigenaarschap controleert, moet je systeem foute gegevens direct weigeren. Deze eerste laag is structurele validatie. Ze zegt niet van wie de rekening is, maar voorkomt dat onmogelijke gegevens verder komen.

Een goede IBAN-validatie kijkt naar:

1. Landcode: de eerste twee tekens bepalen lengte en opbouw (een Nederlands IBAN heeft 18 tekens).
2. Controlegetal: vangt veelvoorkomende typfouten en verwisselde cijfers af (MOD-97).
3. BBAN-structuur: het nationale deel volgt landspecifieke regels, in Nederland de bankcode van vier letters plus tien cijfers.
4. Normalisatie: spaties verwijderen, hoofdletters afdwingen en ongeldige tekens weigeren.

Scheid validatie van verificatie. Validatie vraagt of de gegevens formeel mogelijk zijn. Verificatie vraagt of de rekening bestaat, actief is en bij de bedoelde begunstigde hoort. Een formeel correct IBAN kan nog steeds van de verkeerde partij zijn, bijvoorbeeld omdat iemand het verkeerde record kopieerde of een vals wijzigingsverzoek accepteerde.

Vuistregel: lees “geldig formaat” nooit als “veilig om te betalen”.

Pas dezelfde basiscontroles toe, of de gegevens nu binnenkomen via een ERP-formulier, een leveranciersportaal of een geïmporteerde spreadsheet: valideren bij invoer, bij elke wijziging en vóór de export, met één centrale validatielogica in plaats van verschillende formules op verschillende plekken.

Stap 2: eigenaarschap controleren, de traditionele manier

Is de structuur in orde, dan komt de lastigere vraag: is de rekening van de partij die je wilt betalen? Traditionele methodes proberen dat te beantwoorden, maar ze kosten tijd.

Methode	Wat werkt	Wat misgaat
Proefbetaling (kleine stortingen of een betaling van € 0,01)	Bekend en breed begrepen	Gebruikers haken af, typen bedragen verkeerd of reageren te laat
Bankafschrift of bankverklaring	Bruikbaar voor handmatige controle bij uitzonderingen	Documenten kunnen verouderd of bewerkt zijn en worden wisselend beoordeeld
Bevestiging per mail met contactpersoon	Snel bij stabiele relaties	Gevoelig voor imitatie en zwakke vastlegging
Akkoord in een interne spreadsheet	Makkelijk om mee te beginnen	Moeilijk te beheersen, makkelijk te omzeilen, slecht traceerbaar

Bij de klassieke methode met kleine stortingen moet de gebruiker later terugkomen en exacte centbedragen invullen. Volgens een aanbieder van verificatiediensten mislukt 3 tot 5% van die verificaties en haakt 45 tot 60% van de gebruikers handmatig af. Traditionele methodes houden een plek als terugvaloptie, maar ze horen aan de rand van je proces, niet in het midden. Begin bovendien bij de invoer: een goed opgezet machtigingsformulier voorkomt al veel invoerfouten.

Stap 3: rekeningnummer controleren via naamcheck en API

Moderne verificatie verschuift het proces van vertraagde bevestiging naar een beslissing in realtime.

Verificatie van begunstigde. Sinds 9 oktober 2025 vergelijken banken in de EU bij elke eurooverboeking de opgegeven naam met de naam van de rekeninghouder. Nederland kende dit al als IBAN-Naam-check. Je krijgt een match, een bijna-match of geen match te zien. Voor wie batches aanlevert, is het zaak dat de namen in je stamgegevens kloppen; lees hierover IBAN en rekeninghouder controleren.

API-verificatie. Verificatiediensten kunnen rekeninggegevens binnen enkele seconden bevestigen, waar proefbetalingen vroeger twee tot drie werkdagen kostten. Daardoor kan je systeem direct beslissen: toestaan, markeren of doorsturen voor beoordeling.

Een praktische workflow:

1. Invoer van bankgegevens via portaal, formulier, ERP-scherm of importbestand.
2. Structurele controle van IBAN en gerelateerde velden.
3. Verificatie-aanroep als de structuur klopt en het risico hoog genoeg is (nieuwe begunstigde, gewijzigde gegevens).
4. Classificatie: geverifieerd, afgewezen of beoordeling nodig.
5. Vastlegging met tijdstip, bronkanaal en uitkomst.
6. SEPA-bestand accepteert alleen goedgekeurde records.

Een nieuwe leverancier wordt zo pas “betaalklaar” na een positieve uitkomst. Is de uitkomst onduidelijk, dan vraag je aanvullend bewijs of gaat het naar finance. Faalt de controle, dan kan het record niet in de volgende betaalrun. Dat is veel sterker dan leveranciers eerst betaalbaar maken en pas reageren als de eerste overboeking terugkomt.

Wees eerlijk over de grenzen: dekking verschilt per bank, land en rekeningtype, niet iedereen rondt een toestemmingsflow af en sommige gevallen blijven onduidelijk. Het antwoord is niet terugvallen op spreadsheets, maar een beheerste uitzonderingsroute.

Fouten afhandelen en SEPA-compliance

Ook een goed ontworpen verificatieproces levert uitzonderingen op. Het verschil zit in hoe je ze indeelt.

Situatie	Reactie
Ongeldige structuur vóór aanlevering	Record direct weigeren en bij de bron laten corrigeren
Eigenaarschap niet te bevestigen	Begunstigde op “beoordeling” zetten en betaling blokkeren
Gewijzigde bankgegevens van bestaande leverancier	Bevestiging via een ander kanaal, met een bekend contactnummer
Herhaalde terugboeking bij dezelfde begunstigde	Stoppen met handmatig repareren en de bron van de stamgegevens onderzoeken

Vuistregel: zijn bankgegevens kort geleden gewijzigd en kwam het verzoek per mail binnen, behandel het geval dan als mogelijk gecompromitteerd tot het via een ander kanaal is bevestigd.

Compliance is voor een deel een kwestie van gegevensbeheer. Gaan IBAN’s rond in mailwisselingen of staan bankverklaringen in persoonlijke mappen, dan zit het risico buiten de XML. Beperk wie bankgegevens mag wijzigen, log wie wat wanneer veranderde, bewaar niet meer dan nodig (AVG) en zorg voor functiescheiding: wie een rekening wijzigt, keurt niet in z’n eentje de volgende betaling goed. Bij terugboekingen helpt gestorneerde incasso’s afhandelen.

Niet elke begunstigde past in de standaardroute. Bied dan een gedocumenteerde terugvaloptie met duidelijke bewijsstukken, een eigenaar en vrijgavecriteria, in plaats van informele uitzonderingen.

Een robuust betaalproces met GenerateSEPA

Een volwassen SEPA-betaalproces leunt niet op één grote controle, maar op meerdere kleine: structurele controle bij invoer, verificatie van nieuwe en gewijzigde records, goedkeuringsregels, logging en uitzonderingsafhandeling.

GenerateSEPA neemt de laatste controle vóór de bank voor zijn rekening: je zet Excel-, CSV- of JSON-bestanden om naar geldige SEPA XML, waarbij elk IBAN wordt gevalideerd voordat het bestand ontstaat. Via de API bouw je die controle in je eigen keten, zodat alleen goedgekeurde records in het betaalbestand komen.

Moment	Wat je controleert	Wie
Eerste invoer	IBAN-structuur en verificatie van eigenaarschap	Systeem, met finance bij uitzonderingen
Wijziging bankgegevens	Herverificatie plus bevestiging via ander kanaal	Crediteurenadministratie
Vóór het betaalbestand	Validatie van alle begunstigden in de batch	Systeem
Bij het bevestigen in de bank	Uitkomst van de naamcheck beoordelen	Goedkeurder
Na terugboeking	Oorzaak vastleggen en stamgegevens herstellen	Finance

Een robuust verificatieproces voegt geen bureaucratie toe; het zorgt dat elk SEPA-bestand op bankgegevens rust die je kunt vertrouwen. Controleer een twijfelachtig nummer direct met de IBAN-validator.

---

Veelgestelde vragen

Waarom is het controleren van rekeningnummers belangrijk voor SEPA-betalingen?

Een mislukte SEPA-betaling kost herstelwerk, vertraagt de maandafsluiting, zorgt voor discussie met leveranciers en kan gaten in je controle blootleggen voor fraudeurs. Wie rekeninggegevens controleert vóórdat het betaalbestand ontstaat, houdt ongeldige IBAN's en valse wijzigingen buiten de betaalrun. Dat is veel goedkoper dan achteraf afwijzingen herstellen.

Wat controleert een goede IBAN-validatie?

Een volledige IBAN-controle kijkt naar de landcode en de bijbehorende lengte, het controlegetal volgens MOD-97, de landspecifieke opbouw van het rekeningnummer en ongeldige tekens. Een IBAN dat er goed uitziet, is daarmee nog niet gecontroleerd. En ook een geldig IBAN zegt niets over wie de rekeninghouder is.

Hoe ga je veilig om met gewijzigde bankgegevens?

Elke wijziging van de rekening van een leverancier of medewerker hoort een verificatiestap te starten voordat het record in de betaalrun komt. Bevestig de wijziging via een ander kanaal dan het oorspronkelijke verzoek, leg vast wie het goedkeurde en valideer het nieuwe IBAN. Alleen een bevestiging per mail is de bekendste ingang voor betaalfraude.

Wanneer controleer je een rekeningnummer in het betaalproces?

Op drie momenten: bij de eerste invoer in je systeem, bij elke wijziging van de gegevens en nog een keer vlak voordat het betaalbestand wordt gemaakt. Wachten tot de bank een betaling afwijst is traag, duur en te voorkomen met een vaste controle vóór aanlevering.

---

Gerelateerde artikelen