September 2013: SpeakUp trapt af
Het is de hoogste tijd: SpeakUp gaat aan de IBAN. Deze overgang heeft impact op het reilen en zeilen van onze afdeling finance, maar de echte nitty gritty zit natuurlijk in de IT: Onze eigen portal-omgeving waarin alle facturatie wordt gedaan. De kern van het verhaal rond IBAN-incasso’s is ‘open standaarden’, geen probleem zou je zeggen want bij SpeakUp zijn open standaarden de drijvende veer achter onze innovatie. Helaas, zoals Andrew Tanenbaum al zei “The nice thing about standards is that there are so many of them to choose from”, dat hebben we dan ook aan den lijve ondervonden.
De betrokken afdelingen komen samen en een plan wordt getrokken. De overgang op IBAN-nummers is klein en kun je amper een project noemen: een paar cijfers en letter voor de bestaande cijfertjes plakken, en klaar. De IBAN-incasso’s vormen wel een leuke uitdaging. Bedrijven die geen gebruik maken van automatische incasso hebben het een stuk makkelijker!
Incasso variëteit
Nieuw met de komst van IBAN: bedrijfsincasso’s. Dit is een contract, waarbij de bank van de klant akkoord moet geven op het contract. Dit moet omdat deze incasso on-omkeerbaar is: storneren is niet mogelijk. Bijkomend met het oog op ‘standaarden’: de SNS-bank doet hier niet aan mee. Mede door de bijbehorende papierwerk bij deze vorm van incasso’s heeft SpeakUp ervoor gekozen om deze vorm niet te gaan gebruiken maar vast te houden aan de ‘gewone’ incasso.De gewone (voor SpeakUp interessante) incasso is de doorlopende machtiging: SpeakUp zal immers maandelijks een bedrag afschrijven bij een groot deel van haar klanten. Deze is bij IBAN flink ingewikkelder geworden: Een incasso-poging kan in vier categorieën vallen:
- “once” – Een eenmalige incasso, niet in gebruik bij SpeakUp
- “first” – De eerste in de serie van de doorlopende incasso
- “recurring” – De tweede en alle volgende in de serie
- “last” – De laatste in de serie MAG gemarkeerd worden als ‘last’, maar dit is niet verplicht. Soms weten we nog niet dat een incasso-transactie de laatste zal zijn, het kan namelijk voorkomen dat een klant opzegt, en er daarna geen bedrag meer geïncasseerd hoeft te worden. SpeakUp besluit deze ‘last’ geheel niet te gaan gebruiken.
We houden er 2 over: first en recurring.
Incasso-referentie
Nieuw is de incasso-referentie. Dit is een kenmerk (een stukje tekst, of voor techneuten: een ‘string’) die uniek moet zijn voor de volgende zaken:
- Voor SpeakUp
- Voor dit IBAN-nummer
- Voor deze klant in deze incassorelatie met SpeakUp, het ‘mandate’
Een speurtocht die ons naar oktober brengt geeft angst. Het lijkt erop dat de klant deze referentie zelf mag bepalen. Gelukkig spreekt de documentatie van de verschillende banken elkaar tegen, waardoor we voor de variant kunnen kiezen die ons geschikt lijkt: SpeakUp zal besluiten welke referentie de klant krijgt, tevens zal SpeakUp die pas aan de klant mededelen NADAT hij het incasso-contract heeft ondertekend: op de eerste factuur, en daarna in herhaling op iedere volgende factuur.
De referentie is dan ook het debiteurnummer (wie geen debiteur is, heeft toch geen incasso) gevolgd door een appendix “-001”. Dit geeft de mogelijkheid voor de klant om een keer een ander IBAN-nummer te krijgen, of om het incasso-contract op te zeggen en een tijdje later opnieuw aan te gaan: in die situatie zal de appendix gestaag opgehoogd worden: “-002”, “-003” etc.
Teken-datum
De ondertekendatum moet ook bijgehouden worden in de mandate, en bij iedere incasso-poging meegestuurd worden naar de bank. Voor klanten die al vóór het IBAN-tijdperk een incasso-relatie met SpeakUp hadden, moet de datum 1 november 2009 gebruikt worden.
November: development
In november gaan de developers echt van start om de overgang te realiseren. Alle plekken waar bank-nummers konden worden ingevuld worden vervangen door IBAN-velden. Een IBAN-nummer is (in Nederland) 8 tot 9 tekens langer (bij oud-postbank klanten NOG langer), bevat plotseling letters, en de oude 11-proef is vervangen door een 97-proef. De IBAN bestaat uit:
- Het oude bank of gironummer
- De 2 letter-landcode
- De 4 letter-bankcode
- Een 2 cijferig controlegetal
Dit controlegetal is zo gekozen dat na een ingewikkelde formule een getal deelbaar is door 97. Door het controlegetal goed te kiezen is dit ALTIJD mogelijk. Dit is gedaan (net als vroeger de 11-proef) om typfouten te detecteren. Het is namelijk niet mogelijk om met 1 typfout een geldig IBAN-nummer te creëren. Pas als er minimaal 2 typfouten gemaakt worden, ontstaat er een kleine kans dat het toevallig een geldig IBAN-nummer is.
First en recurring
Zoals genoemd is er verschil tussen een first en een recurring incasso-poging. Om dit goed bij te houden moeten we bijhouden of er al een eerste incasso is geweest:
- Nee → dan is de eerstkomende poging “first”
- Ja → dan is de eerstkomende poging “recurring”
Om het ingewikkeld te maken kan een incasso-poging door de bank tegengehouden worden. In sommige van die gevallen telt de ‘first’ poging daardoor geheel niet mee. De volgende poging zal dan ook wederom als ‘first’ bij de bank moeten worden aangeboden. Dit betekent dat de gegevens over ‘of er al een eerste incasso is geweest’ ook gereset moeten kunnen worden.
Test-run
Het is november, we zijn klaar voor een test-run. Dankzij de geweldige open standaard (voorzien van een dik document met uitleg: nice) “XML-PAIN” genereren we twee incasso-opdracht-files. Hierin stoppen we enkele niet-bestaande klanten, met verzonnen, doch geldige IBAN-nummers. Deze sturen we naar de bank voor validatie: 1 file voor ‘first’ en 1 file voor ‘recurring’.
Het resultaat is teleurstellend. De bank heeft andere ideeën over de open standaard: “ja, dat staat er wel, maar wij kunnen dat niet verwerken”. We zijn verplicht om bij alle pogingen in de batch-file te vermelden dat de BIC-code ‘not provided’ is. Of we de gebruikte library even kunnen aanpassen, anders gaat het feest niet door. Navraag levert op dat de Rabobank, ABN AMRO bank en ING bank allemaal hun eigen modificaties hebben gemaakt in de XML-PAIN-standaard.
