‘Neem IBAN-overstap serieus’

In september 2013 was het voor ons de hoogste tijd: SpeakUp ging 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 ons 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”. Dit 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 zijn 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 hebben wij 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 twee 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 nádat 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 2013: development

In november gaan de developers echt van start om de overgang te realiseren. Alle plekken waar banknummers 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 áltijd 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.

December 2013: klaar voor de start?

In december wordt het grootste deel van onze software aangepast naar IBAN, alle banknummers worden geconverteerd, de mandates worden aangemaakt en voorzien van het unieke kenmerk. Ook worden de klanten ingelicht zoals voorgeschreven. Resellers en andere plekken waar de SOF’s (Service Order Form) staan worden geüpdatet. We sturen nog één test-run. Deze voldoet wel aan de open ABN-standaard: groen licht! De billingronde van 2 januari zal volledig volgens IBAN verlopen. Wat kan er mis gaan?

Januari 2014: IBAN in productie

Helaas komen we nog wat pijnpuntjes tegen die in development/test niet zijn opgemerkt. We zijn met een multidisciplinair team uit de organisatie flink druk om zowel op IT-, procesmatig als administratief vlak de punten op te lossen. Een bloemlezing:

Probleem 1:
IBAN-nummers zijn case-insensitive. Een hoofdletter of een kleine letter zou geen verschil maken. Voor de PAIN-file (of tenminste de gebruikte library) is dit echter WEL van belang. Natuurlijk zijn er onder de nieuwste klanten een paar die wel kleine letters gebruikten. De fix is simpel: nu worden die IBAN-nummers aangepast, en voor volgende maand wordt iets geschreven dat de IBAN-nummers live converteert naar hoofdletters.

Probleem 2:
Met enkele dagen vertraging sturen we de PAIN-files naar de bank. We maken zelf de fout om een deel van de incasso-pogingen aan te vragen op 14 januari, terwijl het ook mogelijk was om de incasso al op 12 januari uit te laten voeren.

Probleem 3:
Op 15 januari blijkt dat een bestaande klant (pre-IBAN) met een bestaand incasso-contract geen ‘recurring’ incasso is, maar een ‘first’… “dat staat dan verkeerd in de documentatie”. Als klap op de vuurpijl accepteert een deel van de banken deze incasso-poging wel, ookal mag dat niet. Sommige bronnen noemen dat ‘coulance’, andere bronnen spreken van een bug. Feit is dat een aanzienlijk deel mislukt, en een aanzienlijk deel wel goed door gaat. Voor een deel van de problemen besluit SpeakUp een ouderwetse Clieop-incasso te doen, voor een ander deel doen we een nieuw (first!) poging.

Een groot voordeel bij de oplossing van dit probleem: in het IBAN-nummer is te zien welke bank het betreft, in verband met de eerder genoemde coulance, is dat nog wel erg handig: de ‘coulance’ wordt niet toegepast door ING en Rabobank.

Probleem 4:
Vroeger, toen een banknummer nog maar 9 tekens had, kreeg je na een incasso-poging zoveel bij-schrijvingen als er geslaagde incasso’s waren. Zo kun je perfect zien welke klant wel, en welke klant niet, betaald heeft: matchen was mogelijk op omschrijving, op banknummer, op tenaamstelling en zelfs op bedrag: ideaal. Nu krijg je één mega-bijschrijving, van de som van alle incasso-items en losse afschrijvingen voor de mislukte incasso’s.

Voorbeeld: 3 klanten moeten 10, 20 en 40 euro betalen. De incasso-batch is dan 70 euro. Als er 1 mislukte (bijvoorbeeld omdat het IBAN-nummer niet bestaat) kregen we vroeger 2 bijschrijvingen: 10 en 40 (die van 20 ging niet door). Nu krijgen we 1 bijschrijving: 70 euro en 1 afschrijving: 20. Gelukkig meldt de documentatie dat de specificatie van die mega-bijschrijving gewoon gedownload kan worden: in de CAMT.053-file, en die kunnen we al correct inlezen, dat is al lang getest dankzij de testfiles die de bank aanbiedt.

Probleem 5:
De zogeheten CAMT.053-file (niet vernoemd naar het netnummer van Enschede, maar veroorzaakt doordat het de opvolger is van CAMT.052) zal de specificatie van de bijschrijvingen bevatten. Een (heerlijke) open standaard, die lijkt op de PAIN-standaard. Gewoon UTF8… zou het moeten zijn. Jammer: een e met een trema en meer van die grappen, maar dan volgens ASCII, en niet volgens UTF8. Die truc zat niet in de proef-file! Dit kan de administratie niet inlezen. SpeakUp is natuurlijk een redelijk techneutenbolwerk, dus die tekens zijn na de erkenning dat er een fout in de file zit snel omgebouwd naar echte, leesbare UTF8. Ook leuk: de bedragen in de proef-file waren keurig “123,45”, terwijl in de werkelijke file “000000000000123,45000” staat. Mag wel, maar is toch anders.

Probleem 6:
Die specificatie van de incasso-batch, die in CAMT.053 aangetroffen kan worden… die is er niet. In allerijl wordt de PAIN-file geconverteerd naar iets leesbaars, zodat we alsnog (dan maar handmatig) de administratie kunnen bijwerken.

Door al deze zaken komt het geld natuurlijk een flink stuk later binnen dan gebruikelijk. Gelukkig hebben we die ruimte wel, maar je plant er natuurlijk niet op.

Februari: fingers crossed

En dan is het al snel februari. De nieuwe billingronde wordt gedaan. We laten ons niet uit het veld slaan. Er worden, as we speak, nog import scripts geschreven om de incasso-batch in te lezen in het administratieprogramma. Op die manier hebben we de foutieve CAMT.053-files, die toch de beloofde informatie niet bevatten, helemaal niet nodig. De IBAN-incasso opdrachten liggen bij de bank. Tot nu toe geen reden om aan te nemen dat er incasso-pogingen mis gaan.

Geen IBAN?

Interessant nieuws komt mij ter ore: er zijn bedrijven die eenvoudig gestopt zijn met de automatische incasso. Hun klanten mogen voortaan weer aan de slag met een handmatige overschrijving. De nieuwe incasso is voor deze bedrijven teveel hoofdpijn.

Tenslotte

Hoewel de deadline verlegd is naar 1 augustus, adviseren wij om de IBAN overstap toch serieus te nemen en al eerder een IBAN-incasso poging te doen. Eventuele slechte ervaringen geven dan tenminste de ruimte om de maand erna terug te vallen op de ouderwetse methodes. Wie te lang wacht heeft die optie niet meer. We hebben ook begrepen dat er conversiediensten worden geboden om ‘gewoon ouderwets’ CLIEOP aan te leveren, maar daar wordt natuurlijk echt alleen de bank blij van.

Voor bedrijven die niet werken met incasso’s is de overgang minder ingewikkeld. Wie aan de slag wil met bedrijfsincasso’s: heel veel succes, vanwege alle administratieve rompslomp daar omheen heeft SpeakUp die geheel terzijde gelaten.


Frits van Proosdij is Projectleider bij SpeakUp.

Over Frits van Proosdij

Laatste artikelen