Bankafstemming is jarenlang een zware, dagelijkse administratieve klus geweest. Met Advanced Bank Reconciliation (ABR) in Dynamics 365 Finance verandert dat: importeren, valideren, matchen en afstemmen worden geautomatiseerd én controleerbaar. Een terugblik op ons webinar, met de praktijkinzichten van consultant Ümit Poslu.

Webinar terugblik · Spreker: Ümit Poslu , Microsoft Certified Trainer & D365 Finance & Operations consultant · Georganiseerd door Your IT Professionals

Onlangs verzorgde Ümit Poslu voor Your IT Professionals een webinar van een uur over Advanced Bank Reconciliation in Microsoft Dynamics 365 Finance & Operations. Ümit werkt al ruim veertien jaar met Microsoft ERP met een consequente focus op Finance. In deze blog vatten we de kern van die sessie samen: wat ABR doet, hoe je het inricht, waar de matching rules het verschil maken, en welke valkuilen je uit de praktijk maar beter vooraf kent.

Waarom Advanced Bank Reconciliation?

Vóór deze functionaliteit was bankafstemming in F&O grotendeels handwerk. Je vulde het bankafschrift handmatig in, vinkte transactie voor transactie af, en voegde nieuwe regels voor bankkosten of rente met de hand toe. Dat is een dagelijkse, foutgevoelige klus, en daarom werd in veel projecten een ISV-oplossing ingezet om het proces dragelijk te houden.

ABR pakt dit op drie vlakken aan:

• Automatisering. Elektronische bankafschriften worden geïmporteerd en automatisch gematcht met de financiële transacties in F&O. Alle data (bedrag, betalingskenmerk, factuurnummer, naam van de klant) zit immers al in het systeem.
• Controle. Validatie op saldo, datum en valuta, een gebruiksvriendelijk side-by-side worksheet, en een volledige audit trail via een reconciliation ID waarmee je de historie altijd kunt terugzien.
• Schaalbaarheid. Batchverwerking voor zowel de import als de matching, en herbruikbare rule sets. Een afschrift met honderden regels kan zo op de achtergrond worden afgehandeld, zonder dat een gebruiker zit te wachten.

Goed om te weten: Microsoft heeft ABR in stukjes uitgerold. Functionaliteit die je standaard zou verwachten, zoals batch-import, kwam pas in latere releases beschikbaar. Veel onderdelen zijn inmiddels uit preview en staan standaard aan, maar het loont om in Feature management te controleren of alle ABR-functies daadwerkelijk zijn ingeschakeld. Staat er iets uit, dan kan de end-to-end oplossing onverwacht haperen.

Het proces in één oogopslag

De end-to-end flow van ABR is heel consistent. Van een ruw bankbestand naar een gevalideerde, afgestemde reconciliatie verloopt het in zes stappen:

1. Import: het bankafschrift (CAMT.053, MT940 of BAI2) wordt ingelezen, handmatig of via een geautomatiseerde batch.
2. Validate / Confirm: het systeem controleert bankrekening, saldo en datums voordat er iets wordt gematcht.
3. Worksheet: de statementregels en de F&O-banktransacties komen side-by-side in het reconciliation worksheet.
4. Matching rules: de ingestelde rule set draait en herkent automatisch zoveel mogelijk transacties.
5. Uitzonderingen: wat niet automatisch matcht, los je handmatig op of automatiseer je verder.
6. Mark as reconciled: het afschrift wordt definitief afgestemd; bridging accounts worden leeggeboekt.

De inrichting: bankrekening, parameters en Electronic Reporting

De setup begint bij de bankrekening in Cash and bank management. Daar zet je Advanced bank reconciliation op Yes, koppel je het juiste statement format (bijvoorbeeld CAMT.053 of MT940) en vul je de bankrekeninggegevens in. Bij meerdere bankrekeningen activeer je dit per rekening. Op basis van het IBAN in het XML-bestand herkent F&O bij de import automatisch om welke bankrekening het gaat.

Een belangrijke parameter op de bankrekening is Reconcile after import: hiermee wordt het statement bij binnenkomst al gevalideerd én wordt direct de default matching rule set uitgevoerd. Koppel je daar ook nog batchverwerking aan, dan importeert en matcht het systeem volledig op de achtergrond, op een vast tijdstip.

Vergeet de nummerreeksen niet, Download ID, Statement ID en Reconcile ID zijn verplicht. Ontbreekt er één, dan stopt de import met een melding dat het systeem geen statement-ID kan genereren.

De configuratie om de bankbestanden in te lezen loopt via Electronic Reporting. Via Workspaces > Electronic reporting importeer je de laatste versie van het Advanced bank reconciliation statement model uit de Microsoft-repository. Dit ondersteunt ISO20022/CAMT.053, MT940 en BAI2, en is uitbreidbaar voor bankspecifieke layouts. Wie al een ISV-oplossing draait, heeft ER vaak al ingericht, maar voor ABR is een eigen, actuele configuratie vereist.

Transaction codes: de basis voor goede herkenning

In een CAMT.053-bestand zitten allerlei transacties met eigen codes. Map je deze codes correct, dan wordt de herkenning eenvoudiger en automatiseerbaar. Klassiek voorbeeld: periodieke bankkosten met een vaste transactiecode. Koppel je daar een grootboekrekening aan, dan wordt zo’n regel automatisch op de juiste rekening geboekt, zonder handwerk. Komen bepaalde transacties vaker terug, dan is dat het signaal om ze via transaction codes verder te optimaliseren.

Matching rules: de motor onder de oplossing

Als er één onderdeel is dat de kwaliteit van ABR bepaalt, dan zijn het de matching rules. Een matching rule bevat criteria om statementregels te selecteren én om de bijbehorende F&O-banktransacties te vinden. Meerdere rules bundel je in een rule set, waarin je ook de volgorde bepaalt, van specifiek naar generiek.

Een typische rule set redeneert stapsgewijs, bijvoorbeeld:

1. Kijk eerst naar de openstaande leveranciersbetalingen en match ze met de bestaande bridging-transacties (op factuurnummer, bedrag, referentie).
2. Kijk daarna naar de openstaande klanttransacties en zoek de bijbehorende payment journals.
3. Is er voor een klantfactuur geen bridging-transactie? Boek dan automatisch een klantbetalingsjournaal en vereffen vervolgens de openstaande post.

Sterke criteria, en de risico’s van te brede regels

De kracht zit in scherpe selectiecriteria: bedrag, boekingsdatum met tolerantie, payment reference, en document- of factuurnummer. Bovendien kun je velden uit het XML-bestand gelijkstellen aan velden in F&O, wat de herkenning verder verbetert.

De keerzijde: te brede criteria leiden tot foutieve matches. Match je alleen op bedrag, en heb je maandelijks terugkerende bedragen bij verschillende leveranciers, dan pakt het systeem simpelweg de eerste openstaande post, en houd je achteraf juist méér handwerk over. Andere aandachtspunten: bij meerdere mogelijke matches vraagt het systeem om een review, en een verkeerde transaction code mapping kan een match zelfs blokkeren. Reden te meer om dit grondig in de testfase mee te nemen.

Matching actions en matching types

Per rule kies je een matching action. De belangrijkste:

• Match with bank document: koppel een statementregel aan een bestaande banktransactie (betalingen, cheques).
• Mark new transactions: als de F&O-transactie ontbreekt; de regel wordt als nieuw gemarkeerd en later geboekt.
• Clear reversal statement lines: voor bankfouten en terugboekingen, waarbij origineel en reversal tegen elkaar wegvallen.
• Generate voucher: boek bankkosten of rente direct naar het grootboek, eventueel volledig automatisch.

Let op het matching type, dat je per rule moet instellen. One-to-one is het meest voorkomend, maar de praktijk is weerbarstiger: betaalt één klant drie facturen in één transactie, dan heb je one-to-many of many-to-one nodig om dat te herkennen. Many-to-many is het meest complexe scenario, bijvoorbeeld meerdere klanten die gezamenlijk betalen, en vraagt om extra testinspanning. In de praktijk dupliceer je matching rules dus over verschillende types.

Het reconciliation worksheet

Het worksheet is het scherm waar het samenkomt. Links staan de banktransacties uit het afschrift, rechts de transacties uit F&O (zoals bridging-posten van leveranciersbetalingen). Het systeem vergelijkt beide kanten op basis van je matching rules; wat matcht, verschijnt onder het tabblad Matched transactions, en alleen wat overblijft hoef je nog handmatig op te lossen.

Je kunt filteren op bijvoorbeeld bedrag, factuurnummer, klant of leverancier, wat de lijst overzichtelijk houdt. Handmatig matchen kan één-op-één of via multiselect, handig wanneer meerdere regels bij één post horen. En vanuit ditzelfde scherm kun je voor herkende bankkosten meteen een Generate voucher of Generate payment journal uitvoeren. Wie ABR vergelijkt met klassieke ISV-vereffeningsschermen, ervaart dit overzicht, met een duidelijke splitsing tussen gematchte en niet-gematchte regels, vaak als een stuk gebruiksvriendelijker.

Modern Bank Reconciliation: cash application, vouchers en bridging

Bovenop ABR biedt Microsoft de zogenaamde Modern Bank Reconciliation, met extra mogelijkheden: validate & confirm op statementniveau, payment journals genereren vanuit statementregels, vouchers genereren vanuit het worksheet en verbeterde matching rules.

Voor cash application geldt: gebruik default journals op de bankrekening, en géén journaal met een approval-workflow (de boekingen verlopen immers geautomatiseerd). Het invoerveld bij een customer payment journal kan leeg blijven, maar de settlement met de openstaande post is wel degelijk correct.

Bridging payments tot slot werken in twee stappen: een betaling wordt eerst op een bridging account geboekt en pas na bankclearing op de bank-hoofdrekening. Zet je de feature aan, bepaal je het bridging account per bankrekening en stel je een clearing journal in, dan wordt bij het afstemmen van het afschrift de tussenrekening netjes leeggeboekt, met minder handmatige bridging journals als resultaat.

Best practices uit de praktijk

• Begin klein bij het testen. Ümit’s eigen les: niet starten met een bestand vol regels, want dan raak je het overzicht kwijt. Begin met één openstaande klantfactuur en één statementregel, controleer de match, en bouw het van daaruit op.
• Test met echte bestanden. Gebruik een echte CAMT.053 en echte bankcodes, geen kunstmatige testdata.
• Ontwerp van specifiek naar generiek en combineer waar mogelijk amount + reference + date.
• Standaardiseer referenties en zet het factuurnummer in de omschrijving waar dat kan.
• Houd rekening met je ISV. Een bestaande ISV-oplossing kan de standaard ABR-functionaliteit in de weg zitten of zelfs uitsluiten. In een project bleek het nodig een aparte omgeving zónder de ISV op te zetten om configuratie en tests goed te kunnen doen.

Veelvoorkomende issues

De problemen die je het vaakst tegenkomt zijn herkenbaar: een verkeerd statement format (bijvoorbeeld een CAMT.052 in plaats van .053: de CAMT.052 is een intraday accountrapport, de .053 het einde-dag bankafschrift), een afwijkende opening balance, overlappende of buiten de periode vallende datums, te weinig matchingcriteria, een ontbrekende main account bij postings, of een nog actieve journaal-workflow. Stuk voor stuk zijn het inrichtingsdetails die je in de testfase wilt afvangen.

Checklist voor livegang

Voor de go-live houd je drie sporen in de gaten. Functioneel: bankrekeningopties akkoord, transaction codes gemapt, matching rules getest. Technisch: ER-configuratie geïmporteerd, statement format aangemaakt, data entities getest waar nodig. Operationeel: wie importeert, wie reviewt de unmatched items, en wanneer wordt een afschrift als reconciled gemarkeerd?

Tot slot

Advanced Bank Reconciliation maakt van bankafstemming wat het zou moeten zijn: een herhaalbaar, controleerbaar en grotendeels geautomatiseerd proces. De matching rules zijn daarbij de sleutel: goede referenties, correct gemapte transaction codes en doordachte rule sets bepalen de kwaliteit van de herkenning. Modern ABR vergroot de mogelijkheden verder met payment journals, vouchers en bridging clearing. De winst zit in een zorgvuldige inrichting en gedegen testen vooraf, zeker bij de overstap van een ISV-oplossing naar de Microsoft-standaard.