01 — Waarom
De ene fout die de bank niet voor u tegenhoudt
De meeste fouten in een betaalbestand worden door iemand tegengehouden. Een kapot bestand wordt bij het uploaden geweigerd. Een controletotaal dat niet klopt wordt geweigerd voordat er iets beweegt. Vervelend, en ongevaarlijk.
Dezelfde factuur twee keer betalen is geen van beide. In het bestand ziet de tweede betaling er precies zo uit als de eerste: geldige IBAN, geldig bedrag, geldige structuur. De bank heeft geen reden om hem te weigeren — dus doet hij dat niet. U hoort het als de leverancier erover begint, of bij het aflettern van de rekening. Of het geld terugkomt hangt dan af van de goede wil van de ander.
Het gebeurt op de gewoonste manier: een batch twee keer geëxporteerd, een betaling met de hand toegevoegd terwijl de oorspronkelijke nog liep, een goedkeuringsronde die twee bestanden opleverde. Niets spectaculairs — precies daarom zoekt niemand ernaar.
02 — En de dure typefout
Een IBAN draagt zijn eigen controlecijfer
Teken drie en vier van een IBAN zijn een controlegetal over de rest (ISO 13616, modulo 97-10). Eén verkeerd cijfer ergens in het nummer en de rekensom klopt niet meer — een typefout kan hier dus worden opgevangen, offline, zonder iemand iets te vragen.
Is het nummer fout en toch geldig, dan bereikt het geld een bestaande rekening die niet van uw leverancier is. Is het fout en ongeldig, dan komt de betaling dagen later terug en is de factuur stilletjes te laat geworden. Beide zijn twee seconden rekenen waard.
Sleep de facturen er meteen bij
Alles hierboven is het bestand tegen zichzelf gehouden: past de kop bij de inhoud, kloppen de controlecijfers, staat er iets dubbel. Eén vraag kan het bestand niet zelf beantwoorden — is dit het bedrag dat de factuur vraagt?
Een nul te veel in een ERP levert een volkomen geldige betaling op. 12.000 en 1.200 zijn allebei goed gevormde bedragen, doorstaan allebei elke formaatcontrole, en de bank voert uit wat er in het bestand staat. Het komt boven bij het aflettern — dan staat het geld al op de rekening van iemand anders.
Sleep de facturen dus samen met het betaalbestand. Koppelen gebeurt op
het factuurnummer in de omschrijving — zo lettert de andere kant ook af — en dan
worden de bedragen naast elkaar gelegd. Scheidingstekens doen er niet toe:
RE-2026/0417 en RE20260417 zijn hetzelfde nummer.
Liever niet koppelen dan verkeerd koppelen: factuurnummers korter dan vijf tekens blijven buiten beschouwing (die raken in elke tekst iets), en een omschrijving die twee facturen noemt wordt overgeslagen. Verschillende valuta worden gemeld in plaats van omgerekend — een koers raden om iemand een fout aan te wrijven is geen goede ruil.
Incasso
Een incassobatch (pain.008) loopt door dezelfde controles, omdat daarin dezelfde dingen misgaan — alleen treft het iemand anders. Een verkeerde IBAN betekent dat die incasso dagen later terugkomt terwijl de factuur allang de deur uit is. En dezelfde klant twee keer belasten is niet gewoon één bedrag te veel: het is een klacht, een storno, en binnen SEPA kan de klant acht weken lang zonder opgaaf van reden terugvorderen. Het geld gaat terug. De kosten niet.
Twee dingen worden hier bewust niet beoordeeld: de mandaatgegevens, en of het sequentietype (FRST / RCUR / FNAL) het juiste is. Beide hangen ervan af of deze klant al eerder is belast, en dat staat niet in het bestand. Niets zeggen is beter dan raden.
Er wordt niets geüpload
Een betaalbatch bevat elke leverancier die u heeft, wat u ze betaalt en hun rekeningnummer. Zo’n bestand geef je niet aan een webformulier. Het wordt in de browser gelezen: open de ontwikkelaarstools, tabblad Netwerk, sleep een bestand erin — er gaat geen enkel verzoek naar buiten. Of: laad de pagina, trek de netwerkverbinding eruit, en sleep het bestand er alsnog in. Het werkt gewoon door.
Voor de rest van deze site geldt hetzelfde: facturen in een tabel, één factuur tegen EN 16931 houden en de volledige regellijst.