Softwarepakketten:
Beter debiteurenbeheer door optimaal reconciliëren
drs J.G. Bloem en drs P.A.F.M.G. Ploum
Jan Bloem en Patrick Ploum zijn werkzaam als executive en senior consultant bij Moret Ernst & Young Management Consultants op het gebied van inrichting van systemen voor bestuurlijke informatieverzorging.
Reconciliatie betekent simpelweg "verzoening". Bij informatiesystemen betekent reconciliëren dat gegevens uit verschillende bronnen met elkaar worden afgestemd. Binnen de debiteurenadministratie worden ontvangen bedragen (de ontvangsten) gereconcilieerd met openstaande posten (facturen). Daarbij wordt een ontvangen bedrag gekoppeld aan één of meerdere openstaande facturen of delen daarvan. Eventuele verschillen moeten worden verwerkt. De techniek die administrateurs gebruiken om de uitgevoerde reconcilatie per individuele post te registreren wordt afletteren (of soms afvinken) genoemd.
Andere vormen van reconciliatie zijn het matchen van ontvangen goederen met bestellingen of met inkomende facturen. Of - bij specifieke organisaties - in de treasury-administratie waar vorderingen worden gereconcilieerd tegen de rechten en verplichtingen die voortvloeien uit financiële instrumenten (contracten). Bij de treasury-administratie gaat het doorgaans om low volume / high value (lage frequentie en hoge bedragen). Een handmatige reconciliatie en controle is bij low volume / high value uit efficiëntie-overwegingen nog verantwoord. Binnen de financiële administratie is dat al snel niet meer het geval. De debiteurenadministratie (als onderdeel van de financiële administratie) kenmerkt zich vaak door high volume / low value: tientallen, honderden of duizenden geldstromen in de vorm van facturen en ontvangsten moeten worden gecontroleerd en boekhoudkundig juist worden afgehandeld. Handmatig afletteren van posten wordt dan een kostbare aangelegenheid en er wordt dan ook geregeld gebruik gemaakt van moderne geautomatiseerde oplossingen. Immers, tijd is geld.
Verschillende partijen hebben zich inmiddels al gebogen over elektronische reconciliatie op het gebied van debiteuren, en er worden verschillende "oplossingen" op de markt aangeboden. Aanknopingspunten liggen in de software die de verschillende banken beschikbaar stellen, de zogenaamde electronic banking pakketten (EB-pakketten), in de vele financiële pakketten (standaard software voor de grootboek- debiteuren- en crediteurenadministratie), maar ook in speciale reconciliatie-pakketten.
Maar, welke problemen moeten er in dagelijkse praktijk zoal worden opgelost? In dit artikel wordt daarover een tip van de sluier opgelicht.
De dagelijkse praktijk
De moderne ondernemer die met grote aantallen transacties heeft te maken, heeft een aantal administratieve systemen in huis, waaronder een geautomatiseerde financiële administratie en een EB-pakket van Q Q n of van verschillende banken. Soms is er ook een treasury-systeem aanwezig, maar daar abstraheren wij nu van. Waarom is regelmatig sprake van verschillende EB-pakketten? Ondernemers doen vaak zaken via verschillende banken en momenteel heeft iedere bank in Nederland een eigen methodiek om electronisch rekeningmutaties te verwerken en door te geven. Derhalve is momenteel voor bijna iedere bank aparte software nodig.
Om te reconcilieren moeten gegevens uit de EB-pakketten en die uit de financiële administratie met elkaar worden vergeleken. Het EB-pakket stelt de gegevens beschikbaar en uiteindelijk wordt het resultaat van de reconciliatie (de aflettering) in het financiële pakket verwerkt.
Door het bestaan van verschillende methodieken bij banken hebben de EB-pakketten geen gestandaardiseerde output. Daardoor moeten er verschillende interfaces worden gebouwd met het financiële pakket. En interfaces blijken in de praktijk op allerlei onverwachte hindernissen te stuiten.
Maar er is nog een ander probleem. De gegevens die de ontvangst op het elektronische dagafschrift vergezellen zijn lang niet altijd toereikend om de ontvangst te kunnen koppelen aan de desbetreffende vordering(en) die zijn opgenomen in de debiteurenadministratie. Met andere woorden: de electronisch beschikbare informatie om de reconciliatie en bijbehorende aflettering geheel automatisch door systemen (software) te laten afhandelen is niet voldoende. Als de ontvangst voortvloeit uit bijvoorbeeld een ongewijzigd acceptgirodocument of uit automatische machtiging is volautomatische reconciliatie natuurlijk zonder veel problemen mogelijk, maar veel bedrijven betalen niet via deze weg. Organisaties betalen doorgaans met behulp van betaaldiskettes en -tapes of via electronic banking en een directe lijnverbinding. Betaalt men Q Q n of enkele facturen dan zijn die gegevens nog wel terug te vinden bij de ontvangst. Maar bij complexe, samengestelde betalingen van tientallen of honderden (deel)facturen volgt de specificatie van de betaling op papier via de post. Het is natuurlijk een kleine stap om die specificatie op diskette te leveren, maar dan is die nog niet gekoppeld aan de gegevens op het elektronische dagafschrift!
Gemakshalve gingen we er nu even van uit dat de betaler wel alle moeite heeft gedaan om goeie informatie mee te sturen in zijn betaalopdrachten. Toch moeten we ons ook afvragen of die aanname wel terecht is. Het is namelijk net zo gemakkelijk om 10 facturen in een keer te betalen zonder al te nauwkeurig alle factuurnummers op te geven, of om een rond bedrag over te maken naar een leverancier, of om allerlei door de commerciële afdeling bedachte extra kortingen af te trekken, of om alle facturen door een centrale betalingsafdeling bij de moedermaatschappij te laten betalen (de betalende organisatie is dan niet gelijk aan de debiteur). Dit zijn slecht enkele voorbeelden die het dagelijkse bestaan van de debiteurenadministrateur tot een kleurrijk geheel kunnen maken. Daarnaast zijn er natuurlijk nog de ontvangsten van buitenlandse cliënten, met SWIFT-codes, verschillende valuta, koersverschillen en bankkosten.
Reconciliatie-pakketten
Er wordt dus nogal wat geëist van software die voor alle normale gevallen èn voor de uitzonderingen de debiteuren-reconciliatie optimaal moet kunnen verzorgen. Financiële pakketten bieden steeds meer functionaliteit voor het automatisch afletteren van ontvangsten en het verwerken van eenvoudige verschillen met openstaande posten, maar de debiteurenmodule van zo'n pakket schiet veelal tekort indien sprake is van meer complexe vormen van reconciliatie. Sinds enkele jaren zijn er specifieke pakketten door softwareleveranciers op de markt gebracht, die uitsluitend over functionaliteit voor het reconciliëren van ontvangsten en openstaande facturen beschikken. Enkele reconciliatiepakketten hebben een soort van kunstmatige intelligentie voor het herkennen van patronen in het betaalgedrag van debiteuren. Deze reconciliatiepakketten zijn grotendeels operationeel op personal computers (PC's).
Hoe werkt een reconciliatiepakket?
Een EB-pakket staat electronisch in verbinding met een bank. Dat pakket levert onder meer dagelijks informatie over saldi van verschillende rekeningen en over de uitgevoerde crediteringen en debiteringen. Van deze informatie is (meestal) een kopie te maken in de vorm van een eenvoudig leesbaar bestand. Dit bestand is vervolgens in te lezen in het reconciliatiepakket. Het reconciliatiepakket kan de structuur van het bestand van verschillende banken herkennen. Zo weet het bijvoorbeeld waar rekeningnummers staan, waar de bedragen, muntcodes en waar de omschrijvingen van de rekeningmutaties zijn vermeld. In die omschrijvingen staat (hopelijk) een debiteurnummer, een factuurnummer, of een ander gegeven waarmee het pakket kan herkennen bij welke openstaande post een mutatie thuishoort. Tevens zijn in het reconciliatiepakket gegevens beschikbaar van debiteurenidentificaties (bijvoorbeeld nummer en naam) en openstaande posten (bijvoorbeeld factuurnummer, bedrag).
Het reconciliatiepakket moet nu twee dingen doen, te weten:
A. Per rekeningmutatie moet worden vastgesteld dat het om een bepaalde debiteur gaat en om welke factuur, met of zonder toegestane kortingen. Maar ook bankkosten, rente bij- of afschrijvingen en andere zaken die niets met debiteurenontvangsten van doen hebben moeten worden herkend.
B. Van alle posten, herkend en niet herkend moeten `journaalposten' worden aangemaakt om de financiële administratie bij te werken.
Het herkennen van (bank)rekeningmutaties blijkt in de praktijk vaak niet zo eenvoudig als op het eerste gezicht lijkt. Aan de ene kant spelen de functionele aspecten: welke soorten gegevens worden er meegeleverd, hoe worden die herkend en verwerkt.
Aan de andere kant spelen er technische aspecten: formaten, informatieverlies en -vervorming vanaf de betalingsopdracht door de afnemer tot aan de informatievoorziening bij de leverancier. Het transmissiekanaal van het Nederlandse bancaire circuit kent z'n beperkingen. Zo is de maximale lengte van het omschrijvingsveld 6 maal 32 tekens. Een vaak voorkomend probleem hier is dat de oorspronkelijk meegegeven informatie wordt opgeknipt om het bancaire circuit te kunnen doorlopen. Soms verschijnen referentienummers bij aankomst dan gesplitst in twee delen. Het factuurnummer "9503421" wordt dan bijvoorbeeld "9503 421". Een andere verminking ontstaat bij het ontvangen van buitenlands geld. Het kan voorkomen dat een in het buitenland overgemaakt bedrag in Nederland automatisch naar guldens wordt geconverteerd, zodat het bedrag evenmin als identificatiesleutel kan dienen. Het verplicht een reconciliatie-pakket om heel creatief om te gaan met dat beetje informatie dat wel beschikbaar is bij de elektronische meldingen van bankmutaties. Een deel van de oplossing ligt natuurlijk in de afspraken die leverancier en afnemer maken over de betekenis en herkenning van de tekens in de omschrijvingsvelden. Separaat - via de normale post of electronic mail - verstuurde gegevens inzake betalingskenmerken hebben als nadeel dat ze achteraf bij de ontvangst moeten worden bijgevoegd resp. worden ingelezen.
De momenteel beschikbare reconciliatiepakketten zijn doorgaans operationeel op een PC. Dit kan bij complexe reconciliaties met veel soorten afwijkingen tussen de te vergelijken bedragen en bij grote aantallen posten tot lange verwerkingstijden leiden. Het uittesten van de performance is vaak geen gemakkelijke aangelegenheid omdat de reconciliatieregels door het pakket worden "bedacht", aan de hand van de dagelijkse praktijk. Inschattingen maken op basis van ervaringscijfers is moeilijk omdat iedere situatie eigen, vaak unieke kenmerken heeft. En bij grote aantallen posten mag het dagelijks werk op de debiteurenadministratie geen hinder van systemen ondervinden.
Reconciliatiepakketten kunnen op diverse onderdelen verschillen, zoals:
· De mate van creativiteit bij het herkennings- en verwerkingsproces? Welke herkenningssleutels (rekeningnummer, bedrag, kenmerk, overige informatie) kan het pakket hanteren? Wat doet het pakket met niet herkende posten? Op welke wijze worden verschillen verwerkt?
· De mate waarin het pakket zelflerend is. Werkt het alleen op basis van informatie uit de debiteurenadministratie die steeds opnieuw wordt gedown-loaded, of legt het zelf ook een bestand aan dat telkens wordt aangevuld? Bijvoorbeeld een bestand met bankrekeningnummers van betalers en de koppelingen daarmee met debiteuren.
· De mate van betrouwbaarheid en beveiliging. Zij er bijvoorbeeld voorzieningen die beletten dat een dagafschrift-bestand twee maal wordt verwerkt? Op welke wijze is de synchronisatie met de debiteurenmodule geregeld?
Conclusie
De kwaliteit van de reconciliatie is afhankelijk van een viertal factoren: de door de betaler meegeleverde gegevens, de kwaliteit van het bancaire circuit als informatietransmissiekanaal, tot en met het EB-pakket, het reconciliatiepakket en het financiële pakket met de formats van de financiële administratie. Reconciliatiepakketten blijken in toenemende mate toegevoegde waarde te hebben voor het debiteurenbeheer. Financiële pakketten missen in het algemeen de intelligentie om bepaalde complexe toewijzingen voor te bereiden en uit te voeren. Doch complexe situaties met veel soorten afwijkingen zijn ook op andere wijze op te lossen. Hier speelt het (eeuwige) spanningsveld tussen commercie (alles mag om de omzet te behouden en verhogen) en de administratie (alles zo simpel en uniform mogelijk). Maar realiseert de klant zich wel welke kosten gepaard gaan met iedere afwijkende betaling?