beoordeeld met een 8.2

Overstap naar IBAN Deel 2 – Succes?

2/2

December: 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 1 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: 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 1 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.

klaar om te verbinden?

Onze pioniers denken geheel vrijblijvend mee over jouw geschikte telefonie oplossing.

Vraag vandaag een offerte aan

Contactpersoon(Vereist)
Bedrijfsadres(Vereist)
Aantal gebruikers in je onderneming(Vereist)

contact opnemen

Heb je een vraag of interesse in onze dienstverlening? Wij helpen je graag op weg. Vul hier onderstaande formulier in zodat wij zo snel mogelijk contact met je op kunnen nemen.

Hoe wil je dat wij contact met je opnemen?

terugbelverzoek

Heb je een vraag of interesse in onze dienstverlening? Wij helpen je graag op weg. Laat een terugbelverzoek achter zodat wij zo snel mogelijk contact met je op kunnen nemen.