Maandafsluiting automatiseren met bankfeed, PSP-payouts, refunds en chargebacks

Op de laatste werkdag van de maand staat de bankfeed op groen, maar de PSP toont een ander bedrag. Een refund is aangevraagd, een chargeback kwam pas na de cut-off binnen en niemand weet welke afwijking nog bij wie ligt. Dat is geen probleem van één ontbrekende koppeling. Het is een probleem van periode, bewijs en eigenaarschap.

Na deze gids kun je een maandafsluiting ontwerpen waarin bankafschrift, payout-batch, fees, refunds en chargebacks ieder naar de juiste periode wijzen. Je weet welke bedragen op een clearingrekening blijven staan, welk bewijs je bewaart en wanneer een mens de periode mag sluiten. Dagelijkse CAMT.053-matching is daarbij een voorwaarde, niet het einddoel. De bestaande controleketen voor CAMT.053-bankregels en uitzonderingsvrijgave behandelt die dagelijkse invoerlaag.

De documentatie, productdetails en prijskaarten in deze gids zijn gecontroleerd op 2 oktober 2026. De Nederlandse CAMT.053-richtlijn van Betaalvereniging Nederland dateert uit 2013, dus gebruik het formaat als basis voor je parser en controleer de actuele variant bij je bank.

Period-close-reconciliatie is het gecontroleerd afsluiten van één boekhoudperiode door bankregels, PSP-transacties, payout-batches, fees, refunds en chargebacks aan dezelfde periode, bron en boeking te koppelen. De controle bewaart het originele bewijs, geeft iedere afwijking een eigenaar en laat een bevoegde persoon het afsluitbesluit nemen. Een payout is dus nooit automatisch omzetbewijs.

Wat heb je nodig voor een controleerbare maandafsluiting?

Begin met de periodekaart, niet met n8n, Make of een nieuwe connector. Je moet eerst bepalen welke datum welk soort waarheid vertegenwoordigt. Een PSP kan een betaling op 30 september verwerken, op 1 oktober uitbetalen en de bank kan hem op 2 oktober boeken. Dat zijn drie verschillende datapunten.

Leg per geldstroom minimaal dit vast:

Je hebt verder deze acht dingen nodig:

• Een vaste cut-off. Kies de tijdzone, bijvoorbeeld Europe/Amsterdam, een eindmoment en een late-eventvenster. Bewaar occurred_at, effective_at, posted_at, received_at en accounting_period afzonderlijk.
• Een bronregister. Noteer per bankrekening, PSP, administratie, valuta en entiteit hoe data binnenkomt, wie de eigenaar is en wat de terugvalroute is.
• Een clearingrekening per PSP, valuta en entiteit. De clearingrekening is de tussenstand tussen economische transactie en bankontvangst. Zet geen onbekende afwijking rechtstreeks op omzet of bankkosten.
• Duurzame sleutels. Gebruik bij Stripe bijvoorbeeld payment_intent_id, charge_id, refund_id, dispute_id, payout_id en balance_transaction_id. Bij Mollie gebruik je de payment-, refund-, chargeback- en settlement-ID's. Voeg je eigen period_close_id toe.
• Een versie van ieder bewijsstuk. Bewaar de exportdatum, queryperiode, API-versie of rapportversie, bestands-hash en ingest-tijd. Een later gedownload rapport mag de eerste bronversie niet stil overschrijven.
• Een uitzonderingsqueue. Iedere afwijking krijgt een reden, bedrag, valuta, periode, eigenaar, deadline, bewijs, volgende actie en status. Een gedeelde inbox is geen queue.
• Bevoegdheden. Leg vast wie een refund, creditnota, afboeking, chargeback-besluit en periodevrijgave mag doen. De maker van een voorstel mag niet automatisch zijn eigen afwijking vrijgeven.
• Een volledige testmaand. Neem een payout met fees, een refund, een chargeback, een late bankboeking, een dubbele webhook, een deels terugbetaalde order en minstens één onbekende regel mee.

De feed komt pas daarna. Een CAMT.053-afschrift levert boekingen en saldo-informatie aan, maar bepaalt niet hoe jij een PSP-payout ontleedt. Bewaar de bovenliggende bankregel en de onderliggende payoutregels apart. Hetzelfde onderscheid tussen bron, sleutel, synchronisatie en herstel dat geldt voor eigenaarschap per veld en reconciliatie tussen systemen voorkomt dat je bank, PSP en boekhouding tegelijk als waarheid behandelt.

Bij een abonnementsmodel blijven contract, renewal, betaling, payout, refund en chargeback aparte statussen, omdat een payout niet bewijst dat de factuur of toegang klopt. Contract, renewal, incasso en payout aan elkaar koppelen helpt om die geld- en periodeovergangen niet in één statusveld te verbergen.

Een deelrefund vraagt dezelfde precisie: orderregel, creditnota, betaling en match afzonderlijk volgen. Het bewijsprincipe geldt ook voor documenten: originele bron, match en menselijke vrijgave apart bewaren maakt herstel mogelijk zonder een eerder bestand stil te herschrijven.

0/8

• Per entiteit, valuta en PSP is een clearingrekening aangewezen
• De lokale tijdzone en cut-off zijn vastgelegd
• Bankfeed, payoutrapport, refund- en chargebackbron zijn benoemd
• Iedere bron levert een stabiele ID, exportdatum en bewijsversie
• De periodekaart onderscheidt transactie-, settlement-, bank- en ontvangstdatum
• De uitzonderingsqueue heeft eigenaar, deadline, bewijs en volgende actie
• Refund en chargeback hebben aparte statussen en besluitpaden
• Een bevoegde persoon mag de periode formeel vrijgeven

Concrete stappen: zo bouw je de close-keten

De keten werkt van bron naar besluit. Je sluit de maand niet zodra de bankregel is gematcht. Je sluit pas als de verwachte bronnen compleet zijn, de verschillen verklaard zijn en een mens het resterende risico heeft geaccepteerd.

1. Bevries de periodegrens voordat je data binnenhaalt

Maak voor elke periode een record, bijvoorbeeld 2026-09 | entiteit NL | EUR, met:

• period_start: 2026-09-01 00:00:00 Europe/Amsterdam
• period_end: 2026-09-30 23:59:59 Europe/Amsterdam
• close_cutoff_at: het moment waarop nieuwe gebeurtenissen niet meer automatisch in de periode mogen landen
• late_event_policy: de regel voor gebeurtenissen die na de cut-off binnenkomen
• close_status: open, prepared, awaiting_release, released of reopened

Gebruik geen enkele datum als universele periodekolom. Een betaling heeft een economische datum, een payout een settlementdatum en een bankregel een boekdatum. Zet ze alle drie op hetzelfde record. Een refund die op 30 september wordt aangevraagd maar pas op 2 oktober succeeded wordt, heeft minstens een refundbesluit op 30 september en een geldbeweging op 2 oktober. De boekhoudkundige behandeling en btw-mapping laat je vooraf door de accountant vastleggen. De automatisering voert die keuze uit.

Voor het factuurstelsel is de factuurdatum bepalend voor het btw-tijdvak; bij doorlopende prestaties moet de prestatieperiode op de factuur staan. Dat maakt een PSP-payout nooit leidend voor omzet of btw. De uitleg van de Belastingdienst over factuurstelsel en tijdvak is gecontroleerd op 2 oktober 2026.

Controlepunt: je kunt voor iedere late gebeurtenis aanwijzen of zij de gesloten periode corrigeert, alleen een nieuwe periode raakt of eerst menselijke beoordeling nodig heeft.

2. Leg bankfeed en PSP-bronnen als snapshots vast

Haal voor dezelfde periode vier bronpakketten op:

1. het volledige CAMT.053-afschrift of de bankfeed-export;
2. het itemized payout- of settlementrapport per PSP;
3. verkoop-, order- en factuurgegevens uit de bronadministratie;
4. refunds, chargebacks, fees en correcties uit de PSP-API of het rapport.

Sla ieder bestand op met bron, rekening, periode, exporttijd, hash en verwerkingsstatus. Bewaar de ruwe versie ongewijzigd en maak daarna een genormaliseerde versie. Als Stripe de payout aan een verwachte aankomstdatum koppelt, gebruik je die datum om het payoutrapport te selecteren. De bank kan de storting op een andere dag boeken. Stripe waarschuwt ook dat de rapportdata later beschikbaar kan zijn dan de payout zelf. In het Stripe payout reconciliation report staat ook precies welke itemized regels je kunt downloaden, waaronder payments, refunds, disputes, fees en andere balance transactions. Deze documentatie is gecontroleerd op 2 oktober 2026.

Bij Mollie is het equivalent het Settlement Report. Dat rapport groepeert revenue, deductions en costs per settlement en bevat onder meer payments, refunds, chargebacks, payment method fees, chargeback fees, refund fees en correcties. Mollie biedt de settlementinformatie als CSV, PDF, MT940, CODA en via de Settlements API. De actuele Mollie-documentatie over Settlement Reports is op 2 oktober 2026 gecontroleerd.

Controlepunt: dezelfde bronexport twee keer verwerken levert één snapshot op met een tweede ontvangstlog, niet twee keer dezelfde financiële regels.

3. Match de bankregel aan de payout, niet aan losse orders

Maak eerst de banklaag sluitend. De bankregel van € 23.850 is een ontvangst van een PSP, geen bundel van 120 losse verkopen. Koppel hem met de payout-ID, bankreferentie of settlementreferentie aan de clearingrekening. Ontbreekt een betrouwbare referentie, gebruik dan rekening, bedrag, valutadatum en een beperkt datumvenster om een voorstel te maken. Zet het voorstel in de queue als er meer dan één payout kandidaat is.

Ontleed daarna de payout op transactieniveau. De basisformule is:

netto payout = charges + positieve correcties - refunds - chargebacks - fees - negatieve correcties

Maak per component een eigen regel met bron-ID, parent-ID, periode, grootboek, btw-context en status. Een chargeback is geen negatieve verkoopregel zonder dossier. Een PSP-fee is geen onverklaard verschil. Een refund is een correctie op een specifieke betaling en mogelijk op een oorspronkelijke factuur.

De clearingrekening laat het verschil tussen economische activiteit en cash zien:

beginstand clearing + charges - refunds - chargebacks - fees - payout = eindstand clearing

Een positieve eindstand betekent dat geld of een correctie nog bij de PSP staat. Een negatieve eindstand kan wijzen op een chargeback, fee, teruggedraaide payout of een fout in de bronselectie. Laat de rekening niet automatisch op nul boeken om de maand groen te krijgen.

Controlepunt: ieder bedrag op de bankregel verwijst naar een payout of settlement, en ieder bedrag in die payout verwijst naar een betaling, refund, chargeback, fee of expliciete correctie.

4. Wijs ieder onderdeel aan de juiste periode toe

Gebruik een periodematrix. De precieze boekingsregel kan per administratie, contract en btw-regime verschillen, maar de techniek moet de verschillende gebeurtenissen kunnen bewaren.

Een late payout verandert dus niet automatisch de omzetperiode. Een refund of chargeback na de cut-off opent een nieuw correctie-event met een verwijzing naar de oorspronkelijke verkoop. Als je fiscale of verslaggevingsbeleid een andere periode voorschrijft, zet die regel expliciet in late_event_policy. Een losse timestamp van Stripe of Mollie is geen beleid.

Controlepunt: een reviewer ziet op één kaart de economische periode, de settlementperiode, de bankperiode en de gekozen boekhoudperiode.

5. Verwerk refunds en chargebacks als gescheiden beslispaden

Een refund is een actie van de verkoper op een geslaagde betaling. Bij Stripe kun je een betaling volledig of gedeeltelijk terugbetalen, ook in meerdere refunds zolang het totaal niet boven de oorspronkelijke charge uitkomt. De refund gebruikt beschikbare Stripe-balance en kan daardoor pending worden. De Stripe-refunddocumentatie is gecontroleerd op 2 oktober 2026.

Sla per refund op:

• refund-ID, payment- of charge-ID en invoice-ID;
• aangevraagd bedrag en geslaagd bedrag;
• reden, medewerker en idempotentiesleutel;
• aangevraagde, pending-, succeeded- en failed-datum;
• creditnota-ID, btw-regel en oorspronkelijke factuur;
• payout of settlement waarin de terugbetaling werkelijk is opgenomen.

Een chargeback ontstaat doordat de kaarthouder de betaling bij de kaartuitgever betwist. Stripe beschrijft dat de betaling en één of meer dispute-fees direct uit de Stripe-balance kunnen worden gehaald, waarna je bewijs kunt indienen of de dispute accepteren. Een chargeback heeft dus een reden, bewijsdeadline en risico-eigenaar. De Stripe-uitleg over disputes en chargebacks is op dezelfde datum gecontroleerd. Mollie meldt via zijn Chargebacks API wanneer een chargeback binnenkomt en maakt het mogelijk de details en opvolging op te halen.

Bouw een blokkade tegen dubbel compenseren. Staat voor dezelfde charge een refund op pending en komt er een chargeback binnen, dan stopt de automatische refundroute. De queue kiest daarna één eigenaar die bepaalt of de refund wordt geannuleerd, doorloopt of op een andere manier wordt gecorrigeerd. Een klant kan niet ongemerkt zowel een refund als een chargeback krijgen.

Voor een creditnota bewaar je een ondubbelzinnige verwijzing naar de oorspronkelijke factuur, het gecorrigeerde bedrag en de btw-context. De Belastingdienst laat in de uitleg over kortingen zien dat een creditfactuur nodig kan zijn om de btw-correctie te verwerken. Die uitleg is gecontroleerd op 2 oktober 2026. Laat je accountant bepalen hoe een refund, chargeback en creditnota in jouw aangifte en grootboek landen.

Controlepunt: iedere refund en chargeback heeft één parent payment, één eigenaar en één geldstatus. requested of created is nooit hetzelfde als succeeded, settled of boekhoudkundig vrijgegeven.

6. Maak de uitzonderingsqueue een besluitlijst

Gebruik per uitzondering een vast dossier. Dit zijn de minimale velden:

Sorteer eerst op risico en daarna op ouderdom. Een chargeback met een naderende bewijsdeadline hoort boven een afrondingsverschil van € 0,01. Een onbekende payoutregel kan de periode blokkeren, ook als het bedrag klein is. De queue mag openstaande posten bevatten bij het sluiten, maar nooit posten zonder eigenaar, reden of geaccepteerd rest-risico.

Gebruik awaiting_release als aparte status. in behandeling zegt niet of de finance-eigenaar het bedrag heeft geaccepteerd. Een menselijke vrijgave slaat actor, tijdstip, oude status, nieuwe status, bewijsversie, beslissing en reden op. Een correctie is een nieuw event, geen overschreven regel.

Controlepunt: je kunt op de sluitingsdag een lijst exporteren met alle open uitzonderingen, hun waarde, eigenaar, deadline en expliciete beslissing om de periode wel of niet te blokkeren.

7. Draai de sluitingscontroles

Een close-run hoort minstens deze controles op te leveren:

1. Bronvolledigheid: verwachtte bankafschriften, payoutrapporten, settlements, refundfeeds en chargebackfeeds zijn aanwezig.
2. Importvolledigheid: iedere bronregel heeft één genormaliseerde regel en één bronverwijzing.
3. Dubbele invoer: hashes, provider-ID's en domeinsleutels zijn uniek per bron en periode.
4. Payoutsluiting: de som van charges, refunds, chargebacks, fees en correcties sluit per payout op het nettopayoutbedrag.
5. Bankdekking: bankpayouts sluiten tegen de bankregels en de clearingrekening.
6. Periodekwaliteit: late gebeurtenissen hebben de afgesproken route gevolgd en zijn niet stil in een gesloten maand geplaatst.
7. Queuekwaliteit: iedere open uitzondering heeft eigenaar, deadline, bewijs en een geaccepteerd besluit.
8. Btw- en boekingsdekking: creditnota's, fees en omzetregels hebben de juiste bron en fiscale mapping volgens het beleid van de administratie.

Bereken daarna een close-KPI die je kunt testen. Een bruikbare basis is:

close-dekking = regels met bron, periode, eigenaar en eindstatus / verwachte regels

Stel als harde technische eis 100% close-dekking in. Laat de periode alleen vrijgeven als onverklaarde_waarde = € 0, ontbrekende bronbestanden nul zijn en iedere geaccepteerde uitzondering een naam, reden en deadline heeft. Een bekende chargeback mag dus open blijven als de risk owner hem expliciet heeft vrijgegeven als rest-risico. Een onbekende payout mag dat niet.

Meet ook close-latency: de tijd tussen de afgesproken cut-off en menselijke periodevrijgave. Kies bijvoorbeeld maximaal twee werkdagen als interne doelwaarde. Dat is een bedrijfsafspraak, geen universele norm. Een dashboard toont pas groen als de bronversie, de reconciliatie-uitkomst en de naam van de vrijgever zijn opgeslagen.

8. Laat een mens de periode sluiten en maak heropening expliciet

De vrijgever ziet een samenvatting met banktotalen, payouttotalen, clearingrekening, refund- en chargebackwaarde, open uitzonderingen, late events en de bronversies. Laat de persoon vier beslissingen nemen:

• Vrijgeven: alle harde controles sluiten en rest-risico's zijn expliciet geaccepteerd.
• Vrijgeven met uitzonderingen: alleen toegestaan voor redencodes die het beleid toestaat, met naam, bedrag en deadline.
• Blokkeren: een bron, payout of geldbedrag is onverklaard.
• Heropenen: nieuw bewijs verandert een eerder besluit.

Een heropening maakt een nieuw close-event met reden en timestamp. Verwijder de vorige vrijgave niet. Zo blijft zichtbaar wie de maand op welk moment heeft gesloten en waarom hij later weer open moest.

Welke valkuilen breken je maandafsluiting?

Je boekt de payout als omzet

Een payout is cash die de PSP naar de bank stuurt. Hij kan verkopen uit meerdere dagen, fees, refunds en chargebacks bevatten. Mitigatie: boek de economische transactie op haar eigen bronperiode, laat de payout via clearing lopen en sluit pas op componentniveau.

Je gebruikt de bankboekdatum voor alles

De bank kan een payout op 2 oktober boeken terwijl Stripe hem aan 30 september koppelt. Mitigatie: bewaar payoutdatum, bankboekdatum en onderliggende chargeperiode apart. Laat de periodekeuze uit beleid komen, niet uit de laatst binnengekomen feed.

Je maakt één grote PSP-regel

Een bedrag van € 23.850 kan bestaan uit charges, refunds, fees en correcties. Met één regel verlies je het bewijs en kun je een chargeback niet aan een oorspronkelijke betaling koppelen. Mitigatie: maak de payout de ouder en iedere component een kindregel met een eigen ID.

Je behandelt refund en chargeback als hetzelfde

Een refund is een actie van de verkoper. Een chargeback is een formele betwisting door de kaarthouder die geld en bewijsdeadlines kan activeren. Mitigatie: aparte statussen, aparte eigenaren en een blokkade tegen dubbele compensatie.

Je sluit op pending

Een aangevraagde refund, aangeleverde chargeback of nog niet beschikbare payout is nog geen afgeronde geldbeweging. Mitigatie: gebruik statussen als requested, pending, succeeded, settled, accepted en rejected afzonderlijk.

Je overschrijft een bronexport met een nieuw rapport

Een rapport kan later extra transacties tonen of een andere rapportperiode gebruiken. Mitigatie: bewaar iedere bronversie met hash en exportdatum en markeer welke versie voor de close is gebruikt.

Je gebruikt een brede tolerantie om de queue leeg te maken

Een verschil van € 4,99 kan een fee, afronding, verkeerde valuta of verkeerde periode zijn. Mitigatie: maak redencodes en bedragen specifiek. Een uitzondering die begrijpelijk is, is nuttig. Een lege queue zonder bewijs is verdacht.

Je laat de queue na de close verdwijnen

Een open chargeback of onbekende payout is na de maandafsluiting nog steeds een financieel dossier. Mitigatie: archiveer de kaart met beslissing, bewijs, eigenaar en heropeningsregel. Verwijder geen broninformatie omdat het dashboard groen is.

Je vertrouwt op een technisch groen vinkje

Een geslaagde webhook of bestandsoverdracht bewijst ontvangst, niet juiste periode, juiste boeking of menselijke vrijgave. Mitigatie: meet bronvolledigheid, sleutelset, payoutsluiting, clearingstand en vrijgave apart.

Beslis-kader: wanneer is kant-en-klaar genoeg?

Kies de route op de zwaarste uitzondering. Vijfhonderd identieke kaartbetalingen zijn eenvoudiger dan twintig transacties met meerdere entiteiten, valuta, deelrefunds en chargebacks. De keuze draait om vier criteria:

• Bronnen: één bank, één PSP en één boekhouding passen sneller in een standaardroute dan meerdere PSP's of een eigen orderplatform.
• Periodecomplexiteit: alleen payoutdatum gebruiken is eenvoudig, maar ongeschikt zodra economische, settlement- en bankperiode uit elkaar lopen.
• Risico: bij refunds, chargebacks, btw-correcties en grote bedragen moet een mens kunnen vrijgeven en later reconstrueren.
• Beheer: n8n of Make kan een route orkestreren, maar iemand moet sleutels, retries, bronversies, rechten en de uitzonderingsqueue beheren.

Gebruik deze drie uitkomsten:

• Kant-en-klaar boekhoudpakket met PSP-clearingrekening: één entiteit, één PSP, standaardrapporten, weinig uitzonderingen en een finance-eigenaar die dagelijks kan vrijgeven.
• Orkestratielaag met duurzame queue: meerdere bronnen, stabiele periode- en matchregels, een technische beheerder en behoefte aan eigen logs, retries en meldingen.
• Maatwerk period-close-pipeline: meerdere PSP's, entiteiten of valuta, afwijkende cut-offregels, chargebackdossiers, verplichte bronversies of menselijke vrijgave als vast onderdeel van de normale route.

Een kant-en-klaar pakket is niet verkeerd. Het is verkeerd zodra het alleen de happy path laat zien en je refunds, fees, late payouts en chargebacks naar een spreadsheet verplaatst. Een orkestratielaag is evenmin automatisch maatwerk. Zij past als de regels stabiel zijn en je een echte opslag voor bron, queue en auditspoor bouwt.

Hoeveel entiteiten en PSP's moeten in dezelfde maandafsluiting samenkomen?

Eén entiteit en één PSPMeerdere entiteiten, PSP's of valuta

Uitgewerkt voorbeeld: september sluiten met Stripe en CAMT.053

Dit is een fictief rekenvoorbeeld voor een webshop met Shopify, Stripe, Moneybird en één zakelijke bankrekening. De bedragen zijn oefendata om de periodekeuzes te laten zien. De dagelijkse CAMT.053-feed is al gecontroleerd op aanwezigheid, saldo, telling en dubbele invoer. De vraag hier is wat de financieel verantwoordelijke op 30 september wel en niet vrijgeeft.

De bronstanden op de cut-off

De periode is september 2026. De lokale cut-off is 30 september 23:59:59 Europe/Amsterdam. Stripe levert voor de geselecteerde payoutperiode de volgende genormaliseerde bedragen:

De septemberactiviteit sluit vóór de chargeback: € 26.500,00 - € 400,00 - € 750,00 = € 25.350,00. Daarvan staat € 23.850,00 op de bank en € 1.500,00 nog bij Stripe. De clearingrekening is dus niet fout omdat hij op 30 september nog € 1.500,00 bevat. Hij is fout als niemand kan aantonen waarom dat bedrag daar staat.

Wat gebeurt er op 30 september?

De workflow maakt voor iedere charge een koppeling naar Shopify order-ID, Moneybird-factuur en Stripe payment-ID. De succeeded refunds krijgen een refund-ID en creditnota-link. Het payoutrapport en de CAMT.053-bankregel krijgen één payoutdossier. De € 1.500,00 wordt niet als ontbrekende bankontvangst geboekt. De regel blijft awaiting_settlement met payout-ID, verwachte datum 1 oktober en eigenaar Finance.

Een refund die op 30 september is aangevraagd maar nog pending staat, blijft in een aparte queue. Hij wordt niet als geslaagde uitgaande cash geboekt en ook niet vergeten. De medewerker ziet het oorspronkelijke payment-ID, de refundreden, het aangevraagde bedrag en de laatste providerstatus. Zodra de refund succeeded wordt, ontstaat de geldcorrectie in de periode die het beleid voorschrijft.

De maand is nog niet vrijgegeven als één chargebackregel van € 120,00 al in de Stripe-dashboardweergave staat maar niet in de snapshot zit. De close-run markeert dan source_changed_after_snapshot. De medewerker maakt een nieuwe bronversie of documenteert dat het event na de cut-off is ontstaan. Het event gaat naar oktober en verwijst terug naar de septembercharge.

Wat gebeurt er op 1 en 2 oktober?

Op 1 oktober komt de CAMT.053-bankregel van € 1.500,00 binnen. De workflow matcht de bankregel met de payout-ID, haalt het itemized payoutrapport op en verlaagt de Stripe-clearing van € 1.500,00 naar nul. De bankperiode is oktober. De onderliggende charges blijven in september. Er wordt dus geen extra omzet geboekt.

Ook op 1 oktober ontstaat de chargeback van € 120,00. Het systeem maakt een dispute-dossier met payment-ID, charge-ID, oorspronkelijke factuur, reden, evidence deadline en risk owner. De € 15,00 dispute-fee krijgt een aparte regel. De workflow boekt deze gebeurtenis niet stil in september en trekt hem niet af van de al gesloten payout. De accountant kan een andere correctieperiode voorschrijven, maar die keuze staat dan in de policy en in het auditspoor.

Op 2 oktober verandert een eerder aangevraagde refund naar succeeded. De workflow controleert eerst of dezelfde payment al een chargeback heeft. Zo ja, dan blijft het bedrag geblokkeerd voor automatische verwerking. Zo nee, dan maakt hij de creditnota af, koppelt de succeeded refund aan een latere settlementregel en sluit de queuekaart pas na menselijke controle.

De vrijgavebeslissing

De finance-eigenaar ziet op het close-scherm:

• alle bankafschriften aanwezig en de dagelijkse CAMT.053-run gesloten;
• € 25.350,00 septemberactiviteit verklaard;
• € 23.850,00 op de bank gematcht;
• € 1.500,00 in clearing met payout-ID en eigenaar;
• € 400,00 succeeded refunds aan oorspronkelijke facturen gekoppeld;
• geen refund zonder parent payment;
• geen chargeback zonder eigenaar en deadline;
• bronversie en exporttijd van Stripe opgeslagen;
• onverklaarde waarde € 0,00.

De periode kan worden vrijgegeven met één geaccepteerde open post: de payout van € 1.500,00 staat nog in clearing, maar heeft een bekende bron, verwachte settlementdatum en eigenaar. De chargeback en dispute-fee horen bij oktober. De vrijgever slaat naam, tijdstip, gebruikte bronversies en de beslissing op.

De testbare close-KPI is hier 100% close-dekking: iedere verwachte regel heeft bron, periode, eigenaar en eindstatus. De KPI blijft 100% wanneer een bekende late payout nog openstaat. Hij valt onder 100% zodra dezelfde payout zonder ID, bronversie of eigenaar in een algemene tussenrekening verdwijnt.

Vergelijkingstabel: welke route past bij je close-keten?

Prijzen en limieten zijn gecontroleerd op 2 oktober 2026. Moneybird toont deze bedragen bij jaarlijkse betaling. n8n rekent workflowuitvoeringen, niet afzonderlijke stappen. De productprijs is nooit de prijs van de boekhoudkundige inrichting, het testen en het beheer.

Kies kant-en-klaar als je variatie echt klein is. Kies een orkestratielaag als de regels vaststaan, maar je bronnen en opvolging los zitten. Kies maatwerk zodra de uitzonderingen bepalen hoe de maand wordt gesloten.

Een maandafsluiting is pas betrouwbaar wanneer een late payout, een pending refund en een chargeback elk op hun eigen spoor blijven staan. De bank moet sluiten, de clearing mag tijdelijk openstaan, en het bewijs moet verklaren waarom. Pas daarna is een groen eindscherm een besluit waard.