Vind ontbrekende creditnota’s en refundboekingen door drie bewijzen per retour naast elkaar te zetten: de bevestigde terugbetaling bij de betaalprovider, het WooCommerce-refundrecord en de gekoppelde AFAS-credit of financiële boeking. Geen van die bewijzen vervangt de andere. Maak per ontbrekende schakel een aparte reden en vervolgactie.
Eén woord “refund” verbergt drie handelingen
Geld terugsturen, een refund in de webshop registreren en de financiële correctie in het ERP verwerken kunnen op verschillende momenten en door verschillende systemen gebeuren. Sommige betaalmethoden ondersteunen geen automatische API-refund en vragen handmatig handelen. Ook een creditnota kan later beschikbaar komen dan het geld. Een generieke groene retourstatus zegt daarom weinig over de financiële volledigheid.
Bewaar onveranderlijke bedragen en identiteiten uit het goedgekeurde refundmoment. Daarmee voorkom je dat een latere wijziging aan de order de historische correctie herberekent. Koppel ieder bewijs exact aan werkruimte, order en retour. Bedrag en klantnaam alleen zijn onvoldoende wanneer meerdere gedeeltelijke refunds bestaan.
Maandafsluitingscheck per retour
| Paymentprovider | WooCommerce | AFAS | Interpretatie |
|---|---|---|---|
| Bevestigd | Geregistreerd | Credit gekoppeld | Technisch volledig volgens beleid |
| Bevestigd | Geregistreerd | Ontbreekt | Onderzoek financiële vervolgstap |
| Bevestigd | Ontbreekt | Credit gekoppeld | Webshopregistratie herstellen zonder geld opnieuw te sturen |
| Handmatig nodig | Voorbereid | Voorbereid | Taak blijft open tot extern bewijs |
| Onzeker | Niet uitvoeren | Niet uitvoeren | Eerst provideruitkomst verifiëren |
Dit schema is procescontrole, geen financieel of juridisch advies. Laat bepalen welke documenten, momenten en termijnen in jouw situatie gelden. Een workflow in Connect kan de technische bewijsstukken en statussen samenbrengen.
Fictief voorbeeld: geld terug, webshoprecord ontbreekt
Fictief voorbeeld: klant van sportwinkel Stapvast ontvangt een gedeeltelijke terugbetaling van 65 euro. Mollie bevestigt de refund en AFAS bevat de gekoppelde credit. De WooCommerce-registratie liep tijdens een storing vast. Een naïeve “refund opnieuw” zou nogmaals 65 euro kunnen versturen.
De controle ziet dat de geldbeweging al bevestigd is en maakt alleen een taak voor de ontbrekende webshopregistratie. De herstelstap krijgt expliciet de opdracht om WooCommerce bij te werken zonder betaling of voorraad opnieuw te beïnvloeden. In een tweede fictief geval ondersteunt de betaalmethode geen API-refund; de taak blijft “handmatige terugbetaling nodig” totdat een bevoegde medewerker het externe bewijs vastlegt. Zo stuurt iedere ontbrekende schakel naar een andere, begrensde actie.
Bewijs en eigenaarschap
- Gebruik een aparte identiteit voor iedere gedeeltelijke refund.
- Leg vast welk systeem werkelijk geld verplaatst en welk systeem alleen registreert.
- Maak een onzekere provideruitkomst zichtbaar vóór enige herhaalpoging.
- Vergelijk refundbedrag met de vastgelegde snapshot, niet met een later gewijzigde order.
- Geef ontbrekende credit, webshopregistratie en handmatige payment elk een eigenaar.
- Laat een afrondingsactie controleren dat alle volgens beleid vereiste bewijzen bestaan.
In Desk kan de retour de juiste financiële vervolgtaak tonen zonder dat klantenservice tussen dashboards hoeft te vergelijken. Meer over technische order- en AFAS-identiteit staat bij de WooCommerce-AFAS-koppeling.
Plan controles rond vertraging, maar maak vertraging niet tot excuus. Leg per schakel vast hoe snel bewijs normaal beschikbaar is en vanaf welk moment aandacht ontstaat. Een creditnota die na tien minuten nog ontbreekt kan normaal zijn; dezelfde toestand na een goedgekeurde grens verdient een eigenaar. Laat die grens door administratie en procesbeheer vaststellen en toon haar naast het signaal. Een algemene nachtelijke batch mag een klantgerichte handmatige terugbetaling niet onzichtbaar houden.
Test ook correctie zonder geldbeweging. Maak een fictieve refund die bij de provider al bevestigd is en bewijs dat herstel van het WooCommerce-record geen tweede paymentaanroep doet. Test vervolgens een AFAS-credit die bij de eerste schrijfopdracht een time-out gaf: de herstelroute moet eerst op vaste identiteit zoeken. Voeg tenslotte twee gedeeltelijke refunds met hetzelfde bedrag toe. Zij moeten door eigen refund-ID’s afzonderlijk blijven. Deze scenario’s maken duidelijk of de implementatie op identiteiten en statussen rust of alleen op bedragen die toevallig aansluiten.
Neem bij iedere afsluiting een vierogencontrole op voor handmatige geldbewegingen. Degene die het bewijs toevoegt hoeft niet dezelfde persoon te zijn die de uitzondering definitief sluit. Welke functiescheiding passend is, bepaalt je eigen financieel beleid.
Bewaar beide beslismomenten afzonderlijk in het auditspoor.
Wil je ontbrekende refundschakels vinden zonder geld dubbel te bewegen? Ontwerp met Yindle een bewijsgerichte controle.