Koppel een Mollie-settlementregel aan een webshoporder met een vaste matchvolgorde: directe betalingsidentiteit eerst, daarna gecontroleerde metadata en pas als laatste een begrensde omschrijvingsfallback. Bedrag en datum alleen zijn onvoldoende. Een settlement bevat betalingen, refunds, captures, kosten en chargebacks die elk een andere financiële betekenis kunnen hebben.
Waarom een uitbetaling niet één order is
Mollie bundelt meerdere transacties in settlements. De bank ziet één uitbetaling, terwijl administratie per onderliggende betaling of correctie wil weten bij welke webshoporder en AFAS-boeking zij hoort. Een refund kan bovendien in een latere maand vallen dan de oorspronkelijke verkoop. Matching moet daarom de transactielevenscyclus volgen en niet alleen uitbetalingsbedrag tegen dagomzet zetten.
Bewaar betaal-ID’s vanaf checkout door de orderketen. Wanneer settlementdata later komt, is die identiteit de sterkste koppeling. Metadata zoals ordernummer en winkel helpt als tweede route, mits zij binnen dezelfde werkruimte wordt gevalideerd. Een tekstomschrijving kan nuttig zijn voor oudere of POS-transacties, maar verdient lagere zekerheid en zichtbare beoordeling.
Matchvolgorde en bewijsniveau
| Stap | Signaal | Bewijsniveau | Actie bij conflict |
|---|---|---|---|
| 1 | Exacte Mollie payment/order-ID | Hoog | Controleer dubbele identiteit |
| 2 | Gevalideerde metadata met winkel en order | Hoog na scopecontrole | Niet buiten werkruimte zoeken |
| 3 | Bekende AFAS- of webshopreferentie | Middel | Vergelijk lifecycle en inhoud |
| 4 | Begrensde omschrijvingsfallback | Laag | Menselijke beoordeling |
| Geen match | Alleen bedrag/datum | Onvoldoende | Ongekoppeld laten |
Dit is technische reconciliatie, geen boekhoudkundig advies. Laat grootboekkeuzes en verwerking door een bevoegde financieel verantwoordelijke vaststellen. De integratielaag in Connect kan de identiteiten en uitkomsten controleerbaar bewaren.
Fictief voorbeeld: refund in de volgende settlement
Fictief voorbeeld: webwinkel Atlas Thee ontvangt betaling `tr_A` voor order AT-901. De payment-ID wordt bij de order opgeslagen. Twee weken later krijgt de klant een gedeeltelijke refund, die in een andere settlement verschijnt. De matcher koppelt zowel betaling als refund via dezelfde gecontroleerde lifecycle aan AT-901, maar behoudt beide transactietypen en bedragen afzonderlijk.
In dezelfde settlement staat een POS-regel zonder payment-ID, met alleen “ATLAS 904” in de omschrijving. Er bestaat zowel order AT-904 als een oudere factuur 904. De fallback levert geen unieke, sterke match op en maakt een aandachtstaak in plaats van automatisch te boeken. Dit fictieve voorbeeld toont waarom een overtuigend bedrag nog geen identiteit is.
Maandafsluitingscontrole
- Zijn alle settlementregels naar type geclassificeerd: betaling, refund, capture, fee of chargeback?
- Heeft iedere automatische match een herleidbare identiteit en werkruimte?
- Staan lage-zekerheidsmatches apart van bevestigde matches?
- Worden late refunds en credits over maandgrenzen gevolgd?
- Kan een onzekere financiële write vóór herhaling bij AFAS worden geverifieerd?
- Is een ongekoppelde regel zichtbaar met eigenaar en volgende controle?
Laat Desk voor een order de relevante betalings- en refundstatus tonen, maar scherm gevoelige financiële details af volgens rol. De technische relatie met webshop en ERP wordt verder toegelicht bij WooCommerce en AFAS.
Bouw de reconciliatie herhaalbaar op. Een settlement kan eerst worden ingelezen voordat alle gerelateerde refunds, creditnota’s of AFAS-facturen zichtbaar zijn. Bewaar daarom de bronregels onveranderlijk en bereken de actuele matchstatus opnieuw zonder eerdere bevestigde identiteiten te vervangen. Maak onderscheid tussen “nog niet beschikbaar” en “inhoudelijk afwijkend”. Een late factuur kan een tijdelijke open post oplossen; een verschillend nettobedrag vraagt echt onderzoek. Gebruik een peildatum en toon wanneer iedere bron voor het laatst succesvol is ververst.
Controleer ook één-op-veel-relaties. Een order kan meerdere captures of refunds hebben, terwijl één settlementregel soms een kostcomponent vertegenwoordigt die niet aan precies één order hoort. Dwing zo’n kostenregel niet in een ordermatch om het rapport volledig te laten lijken. Rapporteer per categorie welk deel exact gekoppeld, voorlopig gekoppeld, gezamenlijk verantwoord of ongekoppeld is. Leg bij handmatige matching de gekozen bronidentiteit en reden vast. Zo kan een volgende maandrun de beslissing respecteren en blijft een auditor in staat om van AFAS-record terug naar payment en webshoporder te navigeren.
Maak correctie omkeerbaar. Als een medewerker een match later onjuist blijkt te vinden, ontkoppel dan de relatie met een auditreden en laat de originele settlementregel intact. Herbereken afhankelijke rapportages gecontroleerd. Overschrijf nooit het bronrecord om het gewenste saldo te laten ontstaan; dan verdwijnt het bewijs dat nodig is om de fout te begrijpen.
Wil je settlementregels aan aantoonbare orderidentiteiten koppelen? Laat Yindle jouw matchvolgorde en uitzonderingen uitwerken.