PSP-fees reconciliëren: van rate card naar herstelboeking

Op 12 oktober 2026 staat er €3.379,80 op de bank, terwijl je op basis van je orders en je PSP-contract €3.385,30 verwachtte. Het verschil van €5,50 lijkt klein totdat het elke maand terugkomt, op de verkeerde fee-regel staat of nooit wordt geclaimd. Dan is het geen afronding meer, maar stille margeschade.

De lastige vraag is niet of de payout klopt. De vraag is welke fee-regel volgens welke contractversie had moeten gelden, waarom de settlement iets anders laat zien, wie het verschil claimt en wanneer een herstelboeking veilig genoeg is. Deze gids loopt die keten uit met PrestaShop 9, Mollie of Stripe en AFAS Profit als concrete context. Productdetails, prijsinformatie en documentatie zijn gecontroleerd op 12 oktober 2026.

PSP-fee-reconciliatie is het vergelijken van de contractuele rate card met de feitelijke fee-regels in een settlement, per payment-ID en fee-type. Je rekent het verwachte bedrag opnieuw uit, verklaart afwijkingen zoals kaartclassificatie, valuta of volume, legt een claim vast en boekt recovery pas na bewijs en menselijke vrijgave.

Wat je nodig hebt voordat je één fee gaat claimen

Je hebt vier waarheden nodig die je niet in één spreadsheet mag verstoppen:

1. De contractuele waarheid. De rate card, addenda, ingangsdatum, valuta, volumetrap, betaalmethode en uitzonderingen. Bewaar ook de versie die op de transactiedatum geldig was.
2. De transactiewaarheid. Payment-ID, orderreferentie, bedrag, valuta, betaalmethode, kaartregio of kaarttype als de PSP die levert, capture- en refundstatus en de datum waarop de fee ontstond.
3. De settlementwaarheid. Payout- of settlement-ID, fee-ID of balance transaction-ID, fee-type, bedrag, settlementvaluta, transactiedatum, settlementdatum en rapportversie.
4. De boekhoudkundige waarheid. De clearingrekening, fee-rekening, periode, ERP-ID, vrijgavebesluit en de vraag of een recovery al als vordering mag worden geboekt.

De PrestaShop 9-resource order_payments bevat onder meer order_reference, id_currency, amount, payment_method, conversion_rate en transaction_id. Dat is de orderkant. De PSP blijft de bron voor de feitelijke status, settlement en fee. De bredere PrestaShop-AFAS-geldstroom met vaste order-, payment-, payout- en AFAS-ID’s is de onderlaag; deze gids voegt de contract- en feecontrole toe. Bewaar de economische, settlement- en bankperiode apart, zoals bij een maandclose met bankfeed, payouts, refunds en chargebacks.

Gebruik voor Mollie het Settlement Report. Dat rapport splitst een settlement op in revenue, deductions en costs en beschrijft onder costs onder meer payment method fees, chargeback fees, refund fees, notification fees, fee reimbursements, invoice rounding en invoice compensation; via de Settlements API haal je totalen en gedetailleerde payment-, refund-, chargeback- en capturegegevens op.

Gebruik bij Stripe het Payout reconciliation report als je automatische payouts gebruikt. De itemized CSV bevat payments, refunds, disputes, fees en andere balance transactions, terwijl Stripe een payout groepeert op de geschatte aankomstdatum en niet op de datum waarop je bank de storting boekt. Een bankregel mag dus niet de enige periodebron zijn.

Bij Adyen zie je goed waarom een generieke kolom fee tekortschiet. Adyen onderscheidt per transactie onder meer interchange, scheme fees, markup en commission, dagelijkse processing fees en maandelijkse volume-aanpassingen en gebruikt daarvoor meerdere rapporten, waaronder een Payment accounting report, een Payment processing invoice en een Settlement details report.

Leg je rate card vast als rekenregels

Een rate card is geen PDF die je alleen archiveert. Maak er een versieerbare tabel van met ten minste:

De openbare Mollie-prijspagina is bruikbaar als referentie, niet als jouw contract. Op 12 oktober 2026 toont die pagina onder meer €0,32 voor iDEAL en Wero in Nederland, 1,80% plus €0,25 voor EER-consumentenkaarten, 2,90% plus €0,25 voor EER-commerciële kaarten en 3,25% plus €0,25 voor kaarten van buiten de EER. Een volumecontract, partnerafspraak of andere rekening kan afwijken. Zet daarom altijd de ondertekende rate card boven een openbare webpagina.

Rechten, opslag en testdata

Je hebt leesrechten op PrestaShop, de PSP en het ERP nodig. Voor AFAS Profit is OAuth Client Credentials de passende flow voor een automatische koppeling zonder gebruiker. AFAS beschrijft dat de applicatie een client-ID en geheim gebruikt, een access-token voor één uur krijgt en daarna opnieuw een token aanvraagt; alleen de aan die App connector gekoppelde Get- en UpdateConnectoren zijn beschikbaar.

Richt een aparte opslaglaag in voor:

• ruwe contract- en rapportbestanden met hash en ontvangsttijd;
• genormaliseerde fee-regels;
• de rate-cardversie en gebruikte rekenregel;
• de verwachte fee, feitelijke fee en afwijking;
• claim-ID, eigenaar, deadline, bewijs en providerreactie;
• voorgestelde boeking, goedkeurder en read-back van het ERP.

Een workflowhistorie is geen duurzaam financieel dossier. NIST beschrijft logbeheer als een combinatie van infrastructuur en robuuste processen. Bewaar dus de gebeurtenis, tijd, bron, uitkomst en identiteit van degene die een herstelbesluit nam, niet alleen de laatste groene status. SP 800-92 is gepubliceerd op 13 september 2006.

0/8

• Geldige rate-cardversie met ingangsdatum en bron opgeslagen
• Payment-ID, settlement-ID en fee-ID zijn als unieke sleutels gekozen
• Fee-type en settlementvaluta komen afzonderlijk in het datamodel
• Mollie Settlement Report, Stripe itemized CSV of Adyen-rapport is beschikbaar
• PrestaShop 9, PSP en ERP leveren testdata met bekende bedragen
• Claim-eigenaar, deadline en bewijsstatus staan in een uitzonderingsqueue
• Fee-rekening, clearingrekening en herstelbeleid zijn door Finance goedgekeurd
• AFAS read-back en terugvalprocedure zijn getest

Concrete stappen: van rate card naar gecontroleerde recovery

1. Bevries de contractversie en maak de rekenregel uitvoerbaar

Neem eerst één afgesloten periode, bijvoorbeeld 1 tot en met 5 oktober 2026. Koppel die periode aan precies één rate-cardversie. Noteer de tijdzone en leg vast of volumetrap en omzetbelasting op transactiedatum, settlementdatum of factuurdatum worden bepaald. Laat Finance dit besluit vastleggen voordat je gaat rekenen.

Zet iedere regel om naar een formule:

verwachte fee = (feegrondslag × percentage) + vaste fee + toeslagen - kortingen

De feegrondslag is niet altijd het ordertotaal. Soms gaat het om captured amount, soms om settled amount, soms om een bedrag na split of refund. Sla daarom fee_base_amount op en leg vast waar die waarde vandaan komt.

Voor een vast bedrag gebruik je percentage = 0 en voor een percentage zonder vaste component fixed_fee = 0. Rond pas af op het niveau dat je contract voorschrijft. Als je per transactie op twee decimalen afrondt, mag je de totale maandfee niet opnieuw berekenen door de maandomzet op een gemiddelde rate te zetten. Dat kan een echt verschil verbergen.

Controlepunt: voor één payment-ID kun je laten zien welke rate-cardregel is gekozen, welke grondslag is gebruikt, welke afronding geldt en welke verwachte fee daaruit komt.

2. Haal payment, settlement en ERP apart op

Maak geen match op alleen bedrag en datum. Haal drie bronpakketten op:

1. Paymentbron: orderreferentie, payment-ID, bedrag, valuta, betaalmethode, kaartclassificatie of land als de PSP die levert, en status.
2. Settlementbron: payout- of settlement-ID, fee-ID, fee-type, bedrag, valuta, transactiedatum, settlementdatum, rapportversie en eventuele parent payment-ID.
3. ERP-bron: bestaande boekings-ID, rekening, periode, bedrag, externe sleutel en status van de write.

Mollie-webhooks leveren het ID van het gewijzigde object. Je haalt daarna de actuele status op. Dat geldt voor payments, refunds en chargebacks. Mollie adviseert om snel HTTP 200 terug te geven, omdat een webhook na 15 seconden als mislukt geldt en tot tien keer opnieuw kan worden aangeboden over maximaal 26 uur. Gebruik de webhook als wekker, niet als settlementregel.

Bij Stripe kies je het datumbereik rond de geschatte aankomstdatum van de payout. Download de itemized CSV en bewaar de originele versie. Bij Adyen houd je de per-transactie feegegevens en de maandelijkse invoice naast elkaar. Dat onderscheid voorkomt dat je een maandelijkse volume-aanpassing dubbel aan elke payment hangt.

Controlepunt: dezelfde settlement twee keer importeren maakt één bronversie met twee ontvangstlogs, niet twee fee-regels.

3. Reken de fee per payment en per fee-type opnieuw uit

Normaliseer de verschillende PSP-formaten naar één intern schema:

Bereken daarna per regel:

drift = actual_fee - expected_fee

Bewaar ook een redenstatus. Een bruikbare set is:

• no_drift
• rate_card_mismatch
• fee_type_mismatch
• card_classification
• volume_tier
• fx_or_currency
• refund_or_chargeback
• rounding
• timing
• unknown_requires_review

Gebruik unknown_requires_review als vangnet, niet als eindstation. Een model dat elk onbekend verschil als afronding markeert, maakt de administratie stil in plaats van correct.

4. Verklaar de drift voordat je een claim opent

Een afwijking van €0,11 kan verschillende oorzaken hebben. Loop ze in deze volgorde af:

1. Is de juiste rate-cardversie gebruikt? Controleer ingangsdatum, merchant account en volumestaffel.
2. Is de fee aan dezelfde betaling gekoppeld? Zoek op payment-ID, niet op orderbedrag.
3. Is het fee-type gelijk? Een chargeback fee, refund fee of notification fee is geen processing fee.
4. Is de kaartclassificatie gelijk? Controleer consument, commercieel, EER en buiten EER aan de hand van de PSP-data.
5. Is de valuta gelijk? Reken percentage en vaste component in de afgesproken verwerkingsvaluta. Boek FX-afwijking apart.
6. Is er een volume- of maandcorrectie? Adyen verwerkt sommige fee-aanpassingen op maandbasis. Mollie kan kosten en reserves op settlementniveau aggregeren.
7. Is het een echte providerfout? Pas na deze controles is een claim inhoudelijk klaar.

De onafhankelijke Payrails-gids noemt fee mismatch, FX drift, partial refund en timing difference als vier terugkerende klassen van reconciliatieverschillen. De praktische les is bruikbaar: classificeer eerst, wijs daarna eigenaarschap toe.

Controlepunt: iedere afwijking heeft één redenstatus en een bewijslink. Een regel met alleen “verschil” mag niet naar recovery.

5. Sluit de settlement op componentniveau

Gebruik een PSP-clearingrekening. De basiscontrole is:

beginstand clearing + payments - refunds - chargebacks - fees + correcties - payout = eindstand clearing

Een payout is dus de cashuitkomst van de settlement, niet de omzetregel. De feeclaim verandert de payout niet terug in een ander bedrag. Eerst registreer je wat de PSP werkelijk heeft ingehouden. Daarna volgt de claim als apart proces.

Maak per settlement een control record met:

• settlement_id;
• som van payments;
• som van refunds;
• som van chargebacks;
• som van fees per fee-type;
• som van andere correcties;
• payoutbedrag;
• verschil;
• reviewer en eindstatus.

Bij een afwijking in de payout bekijk je eerst de onderliggende fee-, refund- en chargebackregels. Een bankregel van €3.379,80 kan perfect aansluiten op de settlement, terwijl de settlement zelf toch €5,50 te veel fee bevat. Bankreconciliatie en contractreconciliatie zijn twee controles.

Voor de boekhoudperiode geldt de factuur of economische transactie als leidend volgens je beleid, niet de datum waarop de PSP uitbetaalt. De Belastingdienst schrijft bij het factuurstelsel dat de factuurdatum bepaalt in welk tijdvak de btw wordt aangegeven; bij verkoop aan particulieren kan het moment van de prestatie gelden. Laat je accountant de precieze behandeling van fee, recovery en creditnota bepalen.

6. Open een claim met herstelbewijs

Open pas een claim wanneer de drift aantoonbaar is. Gebruik een claimrecord zoals:

recovery_claim_id = mollie-2026-10-05-fee-001

Bewaar daarin:

• contract- en rate-cardversie;
• merchant account en PSP;
• payment-ID’s en settlement-ID;
• fee-type en feitelijk bedrag;
• verwachte fee en rekenregel;
• totale afwijking en valuta;
• oorzaakstatus;
• rapportversie en hash;
• bewijsbestand of export;
• gewenste oplossing: credit, correct settlement of contractaanpassing;
• eigenaar, ingediendatum, deadline en providerreactie.

Maak twee soorten recovery uit elkaar:

• Terugvordering van historische drift. Je vraagt geld terug omdat de provider volgens de geldige afspraak te veel heeft ingehouden.
• Toekomstige correctie. De contractregel of merchantconfiguratie wordt aangepast zodat nieuwe payments goed worden geprijsd.

Een credit in de volgende settlement is geen bewijs dat de oorspronkelijke claim correct was. Match de recovery met de claim-ID en controleer of de provider de juiste fee-type, periode en valuta gebruikt. Een provider kan een credit op totaalniveau geven. Dan bewaar je het providerbewijs en verdeel je de credit intern pas na goedkeuring.

7. Geef de herstelboeking pas vrij na read-back

De veilige volgorde is:

1. Boek de feitelijke fee zoals de PSP hem werkelijk heeft ingehouden.
2. Zet de drift op claim_pending, niet automatisch op omzet of recovery-inkomsten.
3. Laat Finance de claim en voorgestelde rekening goedkeuren.
4. Boek een recovery pas wanneer de providercredit of een formeel akkoord aantoonbaar is.
5. Lees het ERP-object terug op externe sleutel, bedrag, valuta, periode, rekening en bron-ID.
6. Als de write time-out, zoek eerst het bestaande object op. Maak geen nieuwe sleutel.

De rekeningnamen hieronder zijn illustratief. Laat rekeningnummers en btw-behandeling door de accountant vastleggen.

Als de periode al gesloten is, maak je een nieuw correctie-event met verwijzing naar de oorspronkelijke fee-regel. Overschrijf de oude boeking niet. Een herstelboeking moet kunnen antwoorden op drie vragen: welke bron was fout, wie gaf herstel vrij en waar staat de providercredit?

Na deze stappen is duidelijk waar het werk zit. De connector haalt data op. De controle bepaalt welke rate-cardregel hoort bij welk payment-ID. De recovery vraagt bewijs en opvolging. De boeking is pas het einde, niet de manier om het verschil te verbergen.

Valkuilen die fee-recovery onbetrouwbaar maken

Je vergelijkt de bankpayout met de orderomzet

De bank ziet een netto payout. De orderlaag ziet brutobedragen. Fees, refunds, chargebacks en correcties zitten ertussen. Mitigatie: sluit eerst settlement op componentniveau en koppel daarna de payout aan de bank.

Je gebruikt de openbare prijskaart als contract

Een publieke Mollie-prijs kan veranderen of niet gelden voor jouw volume, merchant account of contract. Mitigatie: bewaar de geldige ondertekende rate-cardversie en gebruik openbare prijzen alleen als plausibiliteitscontrole.

Je slaat alleen total_fee op

Een totaalbedrag kan bestaan uit processing, interchange, scheme, markup, refund fee, chargeback fee, FX of een factuurcorrectie. Mitigatie: bewaar fee-type, fee-ID, parent payment, valuta en rapportregel afzonderlijk.

Je matcht op bedrag en datum

Twee payments kunnen hetzelfde bedrag hebben. Een settlement kan betalingen uit meerdere dagen bevatten. Mitigatie: gebruik payment-ID, settlement-ID en fee-ID als vaste sleutelset. Bedrag en datum zijn controles, geen identiteit.

Je behandelt een kaartclassificatie als providerfout

Een commerciële kaart kan volgens contract een ander tarief hebben dan een consumentenkaart. Mitigatie: controleer de kaartclassificatie en de voorwaarden voordat je claimt. Een hoger tarief is pas drift wanneer de contractregel en de feitelijke classificatie niet bij elkaar passen.

Je zet FX in dezelfde driftbak

Een fee in EUR, een payment in PLN en een payout in EUR kunnen een verschil laten zien zonder dat het percentage verkeerd is. Mitigatie: bewaar paymentvaluta, settlementvaluta, wisselkoers en feegrondslag afzonderlijk.

Je boekt de claim als opbrengst zodra hij is ingediend

Een claim is nog geen recovery. Mitigatie: gebruik claim_pending buiten de definitieve opbrengstboeking en boek pas na providercredit of formele bevestiging.

Je maakt na een time-out een nieuwe sleutel

De eerste write kan al zijn uitgevoerd terwijl het antwoord verloren ging. Mitigatie: lees eerst ledger en ERP terug. Hergebruik dezelfde idempotente sleutel voor dezelfde handeling. De replay-redenering achter deze regel staat ook in het onderscheid tussen event-ID en financiële sleutel.

Mollie ondersteunt voor POST-aanroepen een Idempotency-Key; dezelfde sleutel levert binnen één uur een gecachte respons op en vooral gedeeltelijke refunds kunnen zonder dezelfde sleutel dubbel worden uitgevoerd. Die providerbescherming is tijdelijk. Je eigen ledger en recovery-ID blijven daarom nodig.

Je boekt in een gesloten periode door de oude regel te wijzigen

Een wijziging zonder nieuw event maakt het eerdere besluit onzichtbaar. Mitigatie: gebruik een nieuw correctie-event met oorspronkelijke bron, nieuwe providerreactie, beslisser en read-back.

Je laat de uitzonderingsqueue eigenaarloos

Open is geen eigenaar. Mitigatie: wijs per claim één verantwoordelijke en vervanger aan, zet een deadline en maak de volgende actie verplicht. Een onverklaard verschil zonder naam is geen automatisering, maar uitstel.

Beslis-kader: kant-en-klaar, orkestreren of maatwerk?

Kies op de zwaarste uitzondering. Een webshop met één PSP, één valuta en een vaste rate card kan met een standaardrapport en een boekhoudkoppeling beginnen. Een bedrijf met meerdere PSP’s, merchant accounts, entiteiten of volumecontracten heeft een eigen rate-cardmodel nodig, ook als het ordervolume klein is.

Kant-en-klaar is genoeg wanneer

Kies een bestaande connector of PSP-export als:

• je één PSP en één administratie gebruikt;
• de rate card stabiel en handmatig controleerbaar is;
• fee-types in het rapport zichtbaar zijn;
• recovery zelden voorkomt en een finance-medewerker claims handmatig opvolgt;
• de koppeling een externe sleutel en ERP-read-back kan bewaren.

De grens ligt bij de eerste structurele spreadsheet met feeverschillen. Als je daar iedere maand vijf regels uit moet zoeken, is de uitzonderingsroute al een onderdeel van je proces.

Een orkestratielaag past wanneer

n8n of een vergelijkbare workflowlaag past als de regels stabiel zijn, maar data uit PrestaShop, de PSP en het ERP moet worden opgehaald. Gebruik de workflow voor webhooks, geplande rapporten, normalisatie, meldingen en queue-aanmaak. Bewaar rate-cardversies, claims, bronbestanden en herstelbesluiten in een eigen database.

n8n Cloud Starter kost op 12 oktober 2026 €20 per maand bij jaarlijkse betaling voor 2.500 workflowuitvoeringen met onbeperkte stappen. Pro kost €50 voor 10.000 uitvoeringen. Starter heeft vijf gelijktijdige uitvoeringen en maximaal vijf minuten looptijd; Pro gaat tot vijftig gelijktijdige uitvoeringen en veertig minuten. De prijs geldt per volledige workflowuitvoering, niet per stap. Dat maakt n8n een bruikbare orkestratielaag, geen vervanging voor je rate-carddatabase of boekhoudkundige vrijgave.

Maatwerk is de eerlijke keuze wanneer

Kies een eigen tussenlaag als:

• je meerdere PSP’s of merchant accounts hebt;
• rate cards per periode, entiteit, betaalmethode of volumetrap verschillen;
• recovery claims bewijs, deadlines en providerreacties nodig hebben;
• je fees per payment wilt herberekenen en terugzoeken naar de originele order;
• je een gecontroleerde herstelboeking met read-back nodig hebt;
• je ERP’s zoals AFAS Profit en Twinfield naast elkaar gebruikt.

Maatwerk is niet automatisch nodig omdat je veel betalingen hebt. Het is nodig wanneer de uitzonderingen bepalen hoe je proces werkt. De eerste echte waarde zit dan in een duurzaam model, niet in een extra scherm.

Hoeveel contract- en PSP-variatie moet je controleren?

Eén PSP, één administratie, vaste rate cardMeerdere PSP's, accounts, valuta of rate cards

Vergelijkingstabel: drie manieren om feecontrole te bouwen

Prijzen en productdetails zijn gecontroleerd op 12 oktober 2026. Een licentieprijs dekt geen mapping, boekhoudkundige keuzes, testdata of beheer.

De tabel laat ook zien wat je niet mag vergelijken. n8n is geen alternatief voor een rate card. Een Mollie- of Stripe-rapport is geen recoveryworkflow. Maatwerk is pas gerechtvaardigd als je contract- en uitzonderingsvariatie groter zijn dan de standaardkoppeling kan verklaren.

Uitgewerkt voorbeeld: €5,50 fee-drift in PrestaShop, Mollie en AFAS

Dit is oefendata om de controleketen concreet te maken. Het is geen gepubliceerde klantcase. De webshop draait PrestaShop 9, gebruikt Mollie voor betalingen en AFAS Profit voor de administratie. De rate-cardversie v2026.10 geldt vanaf 1 oktober 2026.

De verwachte fee

De batch bevat dertig EER-consumentenkaartbetalingen van €100 en tien iDEAL-betalingen van €50.

De contractuele regels in dit oefenbestand zijn:

• EER-consumentenkaart: 1,80% + €0,25;
• iDEAL: €0,32 per payment.

De verwachte fee is:

• dertig kaartbetalingen: 30 × (€1,80 + €0,25) = €61,50;
• tien iDEAL-betalingen: 10 × €0,32 = €3,20;
• totaal verwacht: €64,70.

De openbare Mollie-prijskaart toont op 12 oktober 2026 dezelfde bedragen voor deze voorbeeldcategorieën, maar de controle gebruikt de contractversie van de webshop. Dat onderscheid blijft nodig bij volumeprijzen of afwijkende merchantafspraken.

De settlement en de afwijking

Mollie levert één settlementrapport met:

• vijfentwintig kaartregels als EER-consument tegen €2,05 per payment;
• vijf kaartregels als EER-commercieel tegen €3,15 per payment;
• tien iDEAL-regels van €0,32;
• één refund van €50,00;
• geen chargebackregel.

De feitelijke fee is:

• vijfentwintig × €2,05 = €51,25;
• vijf × €3,15 = €15,75;
• tien × €0,32 = €3,20;
• totaal werkelijk: €70,20.

De drift is €70,20 min €64,70 = €5,50.

De payout is:

€3.500,00 - €70,20 - €50,00 = €3.379,80

De bankregel sluit dus aan op de settlement. Dat bewijst alleen dat Mollie €70,20 en €50,00 heeft verrekend. Het zegt nog niet of de €5,50 contractueel terecht was.

De claimbeslissing

De paymentgegevens tonen voor de vijf afwijkende kaartregels een consumentclassificatie. Het settlementrapport toont commercieel. De workflow opent daarom:

• recovery_claim_id: mollie-2026-10-05-fee-001;
• source_version: v2026.10;
• settlement_id: de rapportreferentie;
• vijf payment-ID’s;
• expected_fee: €10,25;
• actual_fee: €15,75;
• claimed_amount: €5,50;
• reason: card_classification;
• owner: Finance;
• status: evidence_ready.

Het dossier bevat de rate-cardpagina, de vijf paymentrecords, de settlementregels en de rapport-hash. Finance controleert eerst of er geen contractuele uitzondering voor deze merchant account bestaat. Pas daarna gaat de claim naar Mollie. De vijf regels vormen één claim omdat de oorzaak gelijk is, maar iedere payment-ID blijft afzonderlijk traceerbaar.

De herstelboeking

Tijdens de eerste verwerking boek je de feitelijke €70,20 als PSP-feekosten volgens de goedgekeurde mapping. De claim van €5,50 blijft claim_pending. Je boekt nog geen opbrengst.

Mollie accepteert de claim en crediteert €5,50 in de volgende settlement met een providerverwijzing. De recoveryworkflow matcht die credit op recovery_claim_id en stelt deze correctie voor:

• debet PSP-clearing: €5,50;
• credit PSP-feekosten of recoveryrekening: €5,50.

Finance keurt de correctie goed. De AFAS-write gebruikt een vaste externe sleutel, bijvoorbeeld mollie-2026-10-05-fee-001-recovery. Daarna haalt de workflow het AFAS-object opnieuw op. De read-back moet aantonen:

• het bedrag is €5,50;
• de valuta is EUR;
• de periode is de afgesproken recoveryperiode;
• de externe sleutel is uniek;
• de oorspronkelijke feeclaim is gekoppeld;
• de actor en tijd van vrijgave zijn opgeslagen.

Komt er een time-out na de AFAS-aanroep, dan zoekt de workflow eerst op deze sleutel. Bestaat de boeking al, dan slaat hij de tweede write over. Bestaat zij niet, dan herhaalt hij dezelfde payload met dezelfde sleutel. Niet met een nieuwe sleutel.

Als Mollie de claim afwijst, blijft de feitelijke fee €70,20. De claim wordt gesloten met reden en providerbewijs. Er ontstaat geen fictieve recovery. Dat is minder prettig voor de marge, maar wel een juiste administratie.

Slot: herstel begint bij het verschil dat je kunt uitleggen

Een feeverschil is pas opgelost wanneer je het kunt terugbrengen naar de contractregel, het payment-ID, het fee-type en de settlementregel die werkelijk is geboekt. De bank hoeft dan niet fout te zijn. Een payout kan exact kloppen en toch te hoge fees bevatten.

De volwassen geldstroom bewaart daarom twee controles naast elkaar: sluit de settlement op cash, en toets de fee op contract. Pas wanneer de afwijking is verklaard, de claim is onderbouwd en de providercredit is teruggelezen, mag een herstelboeking de administratie veranderen.

Wie dat proces goed bouwt, maakt van fee-reconciliatie geen maandelijkse speurtocht. Elk verschil krijgt een bron, een eigenaar, een besluit en een spoor terug naar de oorspronkelijke betaling. Dat is hoe marge weer uitlegbaar wordt.