Shopify-retouren verwerken: van inspectie naar refund, creditnota en btw

Je hebt een retour aangevraagd gekregen, het pakket ligt inmiddels op de inspectietafel en iemand vraagt: mag de refund nu de deur uit? In Shopify is dat één handeling. In je bedrijf is het een keten van voorraad, geld, btw en bewijs. Als je die volgorde omdraait, kan één verkeerd vinkje tegelijk je voorraad en je administratie vervuilen.

De veilige route is daarom niet: retour ontvangen, refund klikken, klaar. Je beslist per orderregel wat er fysiek is teruggekomen, wat opnieuw verkoopbaar is, welk bedrag en welke btw terug moeten, en wie de financiële actie vrijgeeft. De gewone route waarin een betaalde Shopify-bestelling automatisch als factuur in Moneybird belandt stopt bij een retour dus niet, maar krijgt er een gecontroleerde correctieketen naast.

Een controleerbare Shopify-retourketen koppelt een retouraanvraag aan de juiste orderregel, registreert ontvangst en conditie, neemt een expliciet voorraadbesluit en voert pas na vrijgave de refund en creditnota uit. De keten bewaart daarbij de Shopify-ID’s, betaal-ID’s, btw-regels en beslissingen, zodat een deelretour of dubbele webhook geen tweede geldactie kan veroorzaken.

Wat je nodig hebt voordat je koppelt

Je hebt geen ingewikkelde architectuur nodig om één retour netjes te verwerken. Je hebt wel duidelijke bronhouders nodig. Shopify bezit de order, de orderregels en de oorspronkelijke betaalcontext. Het magazijn of je retourteam bezit de inspectie. Moneybird of Exact Online bezit de boeking. De koppeling mag die verantwoordelijkheden niet door elkaar halen. Leg de concrete API-kanten vast voor Shopify, Moneybird en Mollie, inclusief de sleutels waarmee je later terugzoekt.

Leg dit klaar:

• Een Shopify-shop met een vaste API-keuze. Gebruik de GraphQL Admin API en leg de ondersteunde versie vast in je applicatie. De actuele Shopify-voorbeelden die ik op 23 september 2026 heb gecontroleerd gebruiken 2026-07. Gebruik een app met de scopes die je echt nodig hebt: voor returnCreate en returnProcess write_returns of write_marketplace_returns, voor het lezen van Return en ReturnLineItem read_returns of read_marketplace_returns, en voor refundCreate de gedocumenteerde orders, marketplace_orders of buyer_membership_orders access scope. Voor orders ouder dan zestig dagen is daarnaast read_all_orders nodig naast read_orders of write_orders. De scope-tabel van Shopify heb ik op 23 september 2026 gecontroleerd.
• Een retourbron. Dat kan de Shopify Customer Account-flow zijn, een helpdesk, een formulier of een magazijnproces. De Customer Account API van Shopify ondersteunt klant-geauthenticeerde accounts waarmee kopers hun orders en accountgegevens beheren; de actuele referentie voor versie 2026-07 heb ik op 23 september 2026 gecontroleerd. Gebruik die flow als klantinterface, maar houd je eigen goedkeuring en retourrecord leidend. Iedere aanvraag krijgt een eigen retour-ID en verwijst naar de Shopify-order en de betrokken line item-ID’s.
• Een inspectieregister. Bewaar per regel SKU, variant, retouraantal, ontvangen aantal, conditie, foto of notitie, inspecteur, inspectietijd en locatie. Gebruik geen vrije tekst als enige bewijs voor een voorraadbesluit.
• Een boekhoudpakket. Moneybird of Exact Online is de bron voor creditnota en boekingsstatus, maar controleer de beschikbare route in jouw administratie en API-versie. De actuele Moneybird Sales invoices API beschrijft het dupliceren naar een creditfactuur en het registreren van een betaling; die documentatie heb ik op 23 september 2026 gecontroleerd. De officiële Exact-documentatie die ik die dag heb gecontroleerd beschrijft creditnota’s op basis van een factuur en het opnemen van geselecteerde regels, maar vermeldt product update 390 van 26 september 2022. Verifieer daarom voor Exact Online altijd de actuele tenant- en API-capability voordat je bouwt. Richt vooraf verkooprekeningen, btw-codes, creditnota’s, tussenrekeningen voor betaalproviders en betaalstatussen in. De keuze dat de webshop de orderregels en btw levert en de betaalprovider alleen aflettert voorkomt dat twee systemen dezelfde verkoop gaan factureren.
• Een eigenaar per veld. De Shopify-order is de bron voor oorspronkelijke prijs, korting, tax lines en betaaltransactie. De inspectie is de bron voor ontvangen hoeveelheid en conditie. De boekhouding is de bron voor creditfactuur en boekingsstatus. Dat is één bronhouder per veld met een vast herstelpad, niet één systeem dat alles tegelijk moet bezitten.
• Een uitzonderingsqueue. Daarin komen ontbrekende orderreferenties, een afwijkend aantal, onherkenbare SKU’s, een beschadigd product, meerdere kandidaten, een dubbele webhook en iedere refund die boven je mandaat uitkomt.
• Een betaalprovider met refundstatus. Bij Mollie heb je minimaal payment-ID, refund-ID, bedrag met currency en value, en status nodig. De actuele Mollie-refundreferentie gebruikt paymentId in het pad en een bedragobject; de webhookreferentie toont daarnaast onder meer description, metadata en createdAt. Beide pagina’s heb ik op 23 september 2026 gecontroleerd. Bij Shopify Payments of een andere PSP bewaar je de transaction-ID waarop de refund betrekking heeft.
• Een testadministratie. Gebruik een testshop of een afgebakende administratie. Neem een volledige retour, een deelretour, een beschadigd artikel, een ontbrekende referentie en twee identieke webhookleveringen op in je testset.

De belangrijkste ontwerpkeuze is per regel, niet per order. Een order met drie regels kan één retour bevatten waarvan één artikel opnieuw verkoopbaar is, één artikel naar reparatie gaat en één artikel ontbreekt. Een status op orderniveau kan die drie uitkomsten niet veilig dragen.

0/7

• Shopify-order-ID en line item-ID worden per retourregel opgeslagen
• Oorspronkelijke prijs, korting, btw-regel en betaaltransactie zijn beschikbaar
• Inspectie registreert ontvangen aantal, conditie, locatie en medewerker
• Voorraad, financiële boeking en betaling hebben ieder een duidelijke bronhouder
• Een uitzonderingsqueue heeft eigenaar, reden, deadline en bewijsveld
• De testset bevat een deelretour, beschadiging, ontbrekende referentie en dubbele webhook
• Refund en creditnota hebben per retourregel een aparte menselijke vrijgave

Concrete stappen: zo bouw je de retourketen

1. Maak van elke retourregel een eigen dossier

Begin met een intern retourrecord. Neem minimaal deze velden op:

Houd deze ID’s expliciet gescheiden. returnCreate krijgt fulfillmentLineItemId, refundCreate krijgt het oorspronkelijke lineItemId, en retouracties zoals returnProcess krijgen de ID van het aangemaakte ReturnLineItem. Een retouraanvraag is nog geen ontvangst. Een ontvangst is nog geen goedkeuring. Die drie momenten krijgen elk een timestamp en een actor. Daarmee voorkom je dat een supportmedewerker een terugbetaling uitvoert terwijl het magazijn nog niets heeft gezien.

2. Leg aanvraag, goedkeuring en Shopify-return vast

Controleer eerst of de order bestaat, of de fulfillment line item is uitgevoerd en of er nog geen refund op dezelfde hoeveelheid staat. Leg daarna de ID-mapping vast voordat je een mutatie uitvoert:

• returnCreate ontvangt per regel fulfillmentLineItemId, bijvoorbeeld gid://shopify/FulfillmentLineItem/....
• Shopify maakt vervolgens een ReturnLineItem aan. Gebruik diens ID in returnProcess of een andere retouractie die op de aangemaakte return werkt.
• refundCreate ontvangt in refundLineItems[].lineItemId de oorspronkelijke gid://shopify/LineItem/..., niet de fulfillment-ID en niet de ReturnLineItem-ID.

Shopify’s returnCreate maakt een retour aan vanuit een bestaande order met minstens één uitgevoerde en nog niet terugbetaalde regel. De mutatie gaat uit van een al goedgekeurde aanvraag en zet de retour in de status OPEN, zo staat in de documentatie voor returnCreate die ik op 23 september 2026 heb gecontroleerd.

Voor deze flow zijn de exacte scopes write_returns of write_marketplace_returns voor returnCreate en returnProcess, read_returns of read_marketplace_returns voor Return en ReturnLineItem, en orders, marketplace_orders of buyer_membership_orders voor refundCreate. De Shopify-scopebeschrijving heb ik op 23 september 2026 gecontroleerd. Gebruik returnCreate dus pas nadat jouw eigen goedkeuringsregel is gepasseerd, of gebruik de aparte aanvraag- en goedkeuringsmutaties als de beslissing buiten Shopify plaatsvindt.

Bewaar naast de Shopify-return je eigen beslissing. Bijvoorbeeld approved, declined of needs_review, met reden en medewerker. Een verzoek wegens verkeerde maat kan automatisch worden voorbereid, maar niet financieel worden vrijgegeven. Een verzoek zonder ordernummer, buiten de termijn of met een vermoedelijk misbruikpatroon gaat naar de queue.

De wettelijke bedenktijd is geen technische Shopify-status. Voor consumentenkoop duurt die in Nederland in veel gevallen tot en met veertien dagen na levering. De verkoper mag bij ontbinding wachten met terugbetalen tot het product terug is of de consument bewijs van terugzending heeft geleverd. Die termijn en dat wachtmoment staan in de actuele uitleg van ACM ConsuWijzer, gecontroleerd op 23 september 2026. Leg je beleidsregel vast en laat uitzonderingen door een mens beoordelen.

3. Registreer ontvangst en inspecteer fysiek

Scan bij ontvangst de retour-ID of het pakketlabel. Zoek daarna de verwachte line items op. Tel het pakket, controleer SKU en variant, en leg afwijkingen vast voordat er voorraad wordt aangepast.

Gebruik minstens deze inspectie-uitkomsten:

• A-grade: compleet, verkoopbaar en direct terug naar dezelfde voorraadlocatie.
• B-grade: verkoopbaar na controle, schoonmaak of herverpakking. Zet het artikel tijdelijk apart en laat de voorraad pas na die handeling stijgen.
• Schade of gebruikssporen: naar reparatie, outlet of afschrijving. Geen automatische restock.
• Ontbreekt: ontvangen aantal is lager dan aangevraagd. De financiële beslissing blijft geblokkeerd voor het ontbrekende deel.
• Verkeerde regel: het product hoort bij een andere order. Zet het in de uitzonderingsqueue en wijzig de oorspronkelijke order niet stilletjes.

Laat de inspectiestatus per regel lopen: received, inspected, restock_pending, quarantine of missing. Gebruik received nooit als synoniem voor verkoopbaar. Dat ene onderscheid voorkomt dat beschadigde retouren direct weer als beschikbare voorraad op Shopify verschijnen. Beslismatrix inspectie en financiële uitkomst

De matrix maakt het financiële onderscheid expliciet: een afschrijving zegt wat er met je voorraadwaarde gebeurt, niet wat de klant automatisch terugkrijgt. De refundbeslissing bepaalt het creditbedrag; de creditnota bepaalt vervolgens de btw-correctie over dat bedrag.

4. Neem het voorraadbesluit vóór de refund

De inspectie levert een beslissing op, geen losse notitie. Maak per regel een voorraadmutatie met oude stand, nieuwe stand, locatie, reden en medewerker. Bij een A-grade retour is de mutatie bijvoorbeeld plus één op SKU JAS-BLAUW-M in locatie AMS-01. Bij schade is de mutatie nul naar verkoopbare voorraad en plus één naar quarantaine.

De actuele Shopify-documentatie voor API-versie 2026-07 maakt onderscheid tussen de retouractie en de refund. returnProcess bevestigt de hoeveelheden op ReturnLineItem en legt een disposition vast, zoals restocken of afvoeren. Als je daarnaast refundCreate aanroept, gebruik je in refundLineItems[].lineItemId de oorspronkelijke LineItem-ID. Deze return- en dispositionbeschrijving en de refundCreate-referentie heb ik op 23 september 2026 gecontroleerd. Geef de restockbeslissing pas mee nadat je eigen inspectie klaar is. Laat een standaardinstelling nooit bepalen dat ieder retourartikel verkoopbaar is.

Bij meerdere magazijnen is locatie onderdeel van de beslissing. Een artikel dat terugkomt in Rotterdam maar in Shopify aan een fulfilmentlocatie in Amsterdam was gekoppeld, moet niet automatisch de verkeerde voorraad verhogen. Sla daarom de inspectielocatie en de doel-locatie op, en maak een aparte overdracht als die niet gelijk zijn.

5. Bereken de financiële uitkomst per regel

Kopieer de oorspronkelijke financiële feiten uit de order. Bereken een deelrefund niet door de huidige productprijs opnieuw op te halen. Prijzen, kortingen, bundels en btw-instellingen kunnen intussen veranderd zijn.

Bewaar per te crediteren regel:

• oorspronkelijke bruto regelbedrag;
• toegepaste korting en eventuele bundelverdeling;
• netto bedrag en btw-bedrag uit de oorspronkelijke tax line;
• valuta en afronding;
• aandeel van verzendkosten als je beleid dat toestaat;
• refundbedrag, creditbedrag en reden;
• verwijzing naar de oorspronkelijke factuur.

Een retour van één artikel uit een order van drie artikelen is dus geen creditnota voor de hele order. De creditnota bevat de geretourneerde hoeveelheid en dezelfde btw-logica als de oorspronkelijke verkoop. Een schadegeval of afschrijving verandert dat niet automatisch: zonder goedgekeurde refund is er geen creditnota en geen btw-correctie, terwijl een gedeeltelijke of volledige refund juist alleen voor het goedgekeurde bedrag wordt gecrediteerd. De Belastingdienst legt uit dat btw die je na een prijsvermindering, annulering of ontbinding niet meer ontvangt, in de aangifte kan worden teruggevraagd. De btw-correctie volgt dus de werkelijk verleende vermindering, gecontroleerd op 23 september 2026.

Maak het onderscheid tussen drie bedragen zichtbaar: wat de klant terugkrijgt, wat je creditnota corrigeert en wat er uiteindelijk via de PSP op de rekening beweegt. Bij een refund in een andere valuta of met een gewijzigde wisselkoers kunnen die bedragen afwijken. Dat is een uitzondering, geen afrondingsverschil dat je moet verbergen.

6. Laat een mens de onomkeerbare acties vrijgeven

Automatiseer de voorbereiding, niet de vrijgave. Menselijke goedkeuring is verplicht per retourregel voor de voorraadactie, de refund en de creditnota. Geef de medewerker een scherm of queue-item met orderregel, ontvangen aantal, conditie, voorgesteld restock, refundbedrag, btw, originele factuur, betaal-ID en eventuele afwijking.

Een eenvoudige A-grade-retour mag automatisch worden gematcht en voorgerekend, maar blijft pending totdat een bevoegde medewerker die specifieke orderregel vrijgeeft. Er is dus geen automatische A-grade-uitzondering op de menselijke controle.

Laat altijd handmatig beoordelen:

• iedere retourregel, ook als orderregel, ontvangen aantal, conditie en bedrag exact lijken te kloppen;
• een ontbrekende of dubbele orderreferentie;
• een ontvangen aantal dat afwijkt van het aangevraagde aantal;
• een beschadigd of gebruikt artikel;
• een refund boven een ingestelde waarde;
• een afwijkend btw-land, OSS-regel of verlegde btw;
• een tweede retour op dezelfde line item;
• een verzoek om store credit in plaats van geld terug;
• een creditnota zonder koppeling aan de oorspronkelijke factuur.

De vrijgave is een financieel besluit. Bewaar per orderregel wie vrijgaf, wanneer, met welk bedrag en op basis van welk inspectiebewijs. Een groen vinkje zonder die context helpt niet bij een controle of een incident.

7. Voer de refund idempotent uit

Maak vóór de geldactie twee verschillende sleutels. De interne actiessleutel is jouw duurzame domeinsleutel, bijvoorbeeld RET-2026-00481-L1-REFUND-1; die koppel je aan de vrijgave, creditnota, PSP-actie en herstelstatus. De Shopify-idempotency key is de sleutel van precies één refundCreate-mutatie, bij voorkeur een nieuwe UUID. Bewaar beide voordat je de API aanroept. De ene sleutel vervangt de andere niet.

In API-versie 2026-07 is de @idempotent-directive voor refundCreate verplicht. De GraphQL-mutatie heeft dus de vorm refundCreate(input: $input) @idempotent(key: "7f4c2a1e-2c8e-4f0b-9e6a-1c7d2a4b6e80"); gebruik in productie een eigen UUID en hergebruik precies die Shopify-sleutel bij een retry van dezelfde mutation en variabelen. Shopify’s refundCreate-referentie toont dit verplichte patroon voor 2026-07 en de idempotency-uitleg beschrijft waarom dezelfde sleutel retries veilig maakt. Beide pagina’s heb ik op 23 september 2026 gecontroleerd.

Gebruik in $input.refundLineItems[].lineItemId de oorspronkelijke Shopify LineItem-ID. Gebruik niet de fulfillmentLineItemId en niet de ReturnLineItem-ID. Kies je voor Shopify’s retourverwerking, dan gebruikt returnProcess juist de ReturnLineItem-ID; dat is een andere stap en een andere identifier.

Als de aanvraag time-out geeft, zoek je eerst op de interne actiessleutel, de opgeslagen Shopify-idempotency key en de Shopify-refund-ID voordat je opnieuw schrijft. Een retry met een nieuwe Shopify-key kan ondanks dezelfde interne actiessleutel alsnog een tweede refund veroorzaken.

Shopify adviseert voor webhookverwerking een persistente delivery-ID te gebruiken. De actuele documentatie zegt ook dat je de HMAC over de onbewerkte request body moet controleren, binnen vijf seconden met 200 OK moet antwoorden en dubbele leveringen idempotent moet afhandelen. Gebruik X-Shopify-Webhook-Id voor deduplicatie en X-Shopify-Event-Id om leveringen van dezelfde merchantactie te correleren, gecontroleerd op 23 september 2026.

Roep daarna de refundactie aan met alleen de vrijgegeven regels en aantallen. Shopify ondersteunt in de gecontroleerde 2026-07-referentie volledige en gedeeltelijke refunds, terugbetaling van verzendkosten, duties en extra fees, verschillende refundmethoden en store credit als dat is ingeschakeld. Controleer na de mutatie het antwoord en sla de Shopify-refund-ID plus transaction-ID op. Een geslaagde API-respons betekent dat de refund is aangemaakt, niet dat het geld al op de rekening van de klant staat. De capabilitylijst van refundCreate heb ik op 23 september 2026 gecontroleerd.

Gebruik je Mollie als betaalprovider, dan is de refundstatus asynchroon. De huidige Mollie-API maakt een refund aan op /v2/payments/{paymentId}/refunds met een verplicht bedragobject en kan een lagere waarde dan de oorspronkelijke betaling terugstorten. De webhookpayload bevat onder meer id, amount.currency, amount.value, paymentId, status en createdAt. Mollie kent refund.queued, refund.pending, refund.processing, refund.refunded, refund.failed en refund.canceled. De create-refund-referentie en de webhookreferentie heb ik op 23 september 2026 gecontroleerd. Verwerk die webhookstatussen als aparte levenscyclus en markeer de refund pas als financieel afgerond bij refund.refunded.

8. Maak de creditnota en koppel de betaling

Boek de financiële correctie tegen de oorspronkelijke factuur. In Moneybird kun je via de actuele API een verkoopfactuur dupliceren naar een creditfactuur en een betaling registreren of een creditfactuur vereffenen. Gebruik de originele factuur als anker en laat de creditfactuur alleen de vrijgegeven regels bevatten, gecontroleerd op 23 september 2026. Werk je met Exact Online, controleer dan de actuele endpoint- en tenantmogelijkheden. De officiële Exact-documentatie beschrijft het maken van een creditnota op basis van een factuur en het meenemen van geselecteerde regels; die pagina noemt product update 390 van 26 september 2022 en heb ik op 23 september 2026 opnieuw geraadpleegd. Zie de Exact-uitleg over creditnota’s op basis van facturen.

Voor een deelretour betekent dat praktisch:

1. zoek de verkoopfactuur via de opgeslagen Shopify-orderreferentie;
2. maak een creditfactuur met alleen de vrijgegeven SKU en hoeveelheid;
3. neem de oorspronkelijke btw-code en grootboekrekening over;
4. sla het creditfactuurnummer op in het retourrecord;
5. stuur of boek de creditnota volgens je administratieve afspraak;
6. koppel de uitgaande refund aan de creditnota of tussenrekening.

Laat de boekhouder vooraf bepalen of een betaalde factuur en creditnota tegen elkaar worden vereffend en daarna een uitgaande betaling krijgen, of dat jouw betaalprovider rechtstreeks op een refund-tussenrekening wordt afgeletterd. De connector voert die afspraak uit. Hij verzint haar niet tijdens een storing.

9. Reconcileer voorraad, geld en btw

Een retour is pas klaar wanneer drie controles dezelfde regel terugvinden:

• Voorraad: de inspectie-uitkomst, magazijnmutatie en Shopify-voorraad hebben dezelfde SKU, locatie en hoeveelheid.
• Geld: Shopify-refund, Mollie-refund of Shopify Payments-transactie en bank- of uitbetalingsregel hebben dezelfde refund-ID, valuta en bedrag.
• Boekhouding: de creditnota bevat dezelfde regels, netto bedragen en btw als de vrijgegeven beslissing.

Plan naast webhooks een periodieke controle. Shopify waarschuwt dat mislukte webhookleveringen tot acht keer in vier uur opnieuw worden aangeboden en daarna kunnen worden verwijderd. Een herstelrun moet daarom gemiste orders, returns en refunds opnieuw uit de bron ophalen, gecontroleerd op 23 september 2026.

Maak de uitkomst zichtbaar als only_source, only_target, same of different. Een retour die in Shopify en Moneybird staat maar geen overeenkomende Mollie-refund heeft, is geen fout die je oplost door nogmaals alles te sturen. Zet precies die betaalactie in de queue en behoud de rest van het bewijs.

Valkuilen die je retourproces duur maken

Refund bij aanvraag in plaats van na ontvangst

Een retourlabel of goedgekeurde aanvraag bewijst niet dat het artikel terug is. Mitigatie: reserveer de financiële beslissing, maar maak de refund pas uitvoerbaar na ontvangst of het bewijs dat je beleid toestaat.

Eén orderstatus voor drie fysieke uitkomsten

Returned zegt niet of een artikel verkoopbaar, beschadigd of ontbrekend is. Mitigatie: modelleer status en conditie per line item en houd voorraadlocatie apart bij.

De actuele productprijs gebruiken

Een prijswijziging of korting maakt een nieuwe berekening onjuist. Mitigatie: neem bedragen, tax lines en kortingsverdeling uit de oorspronkelijke order en bewaar afrondingen.

De hele factuur crediteren bij een deelretour

Dit blaast omzet, btw en klanttegoed op. Mitigatie: map returnLineItem naar het oorspronkelijke line item en crediteer alleen de vrijgegeven hoeveelheid.

Restocken vóór inspectie

Een beschadigd product verschijnt dan opnieuw als verkoopbaar. Mitigatie: gebruik eerst quarantaine of restock_pending en verhoog verkoopbare voorraad pas na het voorraadbesluit.

Dubbele webhook als tweede refund behandelen

Shopify kan opnieuw leveren na een time-out. Mollie stuurt meerdere statusovergangen voor dezelfde refund. Mitigatie: dedupliceer op delivery-ID, refund-ID en jouw eigen actiessleutel. Een statusupdate is geen nieuwe financiële opdracht.

Een aangevraagde refund als ontvangen geld tellen

Een refund kan nog in queued, pending of processing staan. Mitigatie: houd refund_requested, refund_confirmed en reconciled apart.

Een ontbrekende referentie stilletjes raden

Een bedrag of e-mailadres kan bij meerdere orders passen. Mitigatie: werk met Shopify-order-ID en line item-ID. Ontbreekt die sleutel, dan volgt een uitzonderingsbesluit met bewijs.

Alleen het hoofdpad testen

Een test met één volledige retour zegt weinig over productie. Mitigatie: voer bewust een deelretour, twee retouren op één order, ontbrekende SKU, beschadiging, dubbele webhook en een late betaalstatus uit.

Beslis-kader: app, orkestratielaag of maatwerk?

Kies op de zwaarste regel in je proces, niet op het maandvolume. Een kleine shop met deelretouren, meerdere btw-landen en verplichte menselijke vrijgave heeft een complexere koppeling nodig dan een grotere shop met alleen volledige retouren binnen Nederland.

Een kant-en-klare Shopify-app past als één app de retouren, refunds, klanten, btw-mapping en jouw boekhoudpakket goed afdekt. Je verkoopt vooral standaardproducten, gebruikt één administratie en accepteert dat je uitzonderingen handmatig buiten de app afhandelt. Controleer vooral of deelretouren, refunds, Shopify Payments en de synchronisatiefrequentie in jouw plan zitten. Een app kan prima zijn. Alleen de naam automatisch is geen bewijs dat jouw financiële route klopt.

Make als dunne orkestratielaag past als je met bestaande modules een webhook wilt ontvangen, een queue of tabel wilt bijwerken en een taak naar een medewerker wilt sturen. Houd de domeinlogica dan klein. Laat Make geen eigen voorraadwaarheid of financiële beslissing worden. Bewaar sleutels en beslissingen in een duurzame datastore, niet alleen in een scenario-run.

n8n of maatwerk API-integratie past als je self-hosted wilt werken, meerdere systemen moet verbinden of per orderregel een eigen beslis- en herstelpad nodig hebt. n8n kan de orkestratie leveren. De onderdelen die geld en voorraad raken hebben nog steeds idempotentie, logging, reconciliatie en vrijgave nodig. Een visuele flow vervangt die afspraken niet.

Mijn grens is helder: zodra de route moet weten welke regel is teruggekomen, welke korting daarop zat, welke btw is geheven, welke voorraadstatus de inspecteur koos en of de betaalprovider het geld werkelijk heeft teruggestuurd, is een generieke actie-keten vaak te dun. Dan bouw je een klein transactiesysteem, ook als het er in Make of n8n uitziet als een schema.

Zijn je retouren meestal volledig, binnen één land, met standaard btw en zonder inspectiebesluit per regel?

Ja, meestal standaardNee, er zijn uitzonderingen

Uitgewerkt voorbeeld: een deelretour met inspectie

Neem een fictieve Nederlandse kledingwebshop met Shopify, Mollie en Moneybird. De order bevat twee regels:

De klant vraagt de jas terug. Het retourrecord krijgt RET-2026-00481 en verwijst naar de Shopify-order en de line item-ID van JAS-BLAUW-M. De aanvraag wordt goedgekeurd. Shopify krijgt een open return, maar er wordt nog geen refund gemaakt.

Bij ontvangst scant het magazijn de retour-ID. De jas is compleet, heeft geen gebruikssporen en wordt op locatie AMS-01 gelegd. De inspecteur registreert ontvangen aantal 1, conditie A-grade en restock plus 1. De sokkenregel blijft volledig buiten het retourdossier.

De financiële calculator neemt de oorspronkelijke bedragen over. De refund en creditnota zijn 79,00 euro bruto. Bij 21% btw is dat afgerond 65,29 euro netto en 13,71 euro btw. De order blijft gedeeltelijk geleverd, dus de connector crediteert niet de sokken en verandert de oorspronkelijke verzendregel alleen als de retourpolicy dat expliciet voorschrijft.

De medewerker ziet nu één vrijgavekaart:

De connector schrijft de eigen actiessleutel eerst weg en voert daarna de Shopify-refund uit. Een time-out volgt. Bij de retry vindt de connector dezelfde sleutel terug en vraagt hij de bestaande refundstatus op in plaats van een tweede refund te sturen. Mollie meldt achtereenvolgens refund.queued, refund.processing en refund.refunded. Alleen de laatste status sluit het betaaldeel af.

Moneybird krijgt daarna de creditfactuur voor 79,00 euro met dezelfde btw-code als de oorspronkelijke jasregel. Het creditfactuurnummer wordt teruggeschreven naar het retourrecord. De financiële inrichting bepaalt vervolgens hoe de creditnota tegen de oorspronkelijke factuur wordt vereffend en hoe de uitgaande Mollie-refund op de tussenrekening komt.

De dagelijkse controle ziet uiteindelijk vier gelijke sleutels: retour-ID, line item-ID, refund-ID en creditfactuurnummer. De verkoopbare voorraad is met één jas gestegen, de refund is bevestigd, de creditnota corrigeert precies 79,00 euro en de btw-correctie is 13,71 euro. De sokken zijn nergens geraakt. Dat is het gewenste eindbeeld van een deelretour.

Vergelijkingstabel: wat kost de koppelroute?

De publieke toolprijzen hieronder zijn gecontroleerd op 23 september 2026. Het zijn abonnementskosten, geen complete implementatiekosten. Shopify, Moneybird, Mollie, btw-advies, hosting en beheer kunnen er nog bovenop komen.

De Shopify App Store vermeldt voor Moneybird Bookkeeping vanaf 18 dollar per maand, inclusief een Basic-plan met refunds en synchronisatie per 60 minuten, gecontroleerd op 23 september 2026. Make rekent op de actuele prijspagina één credit per moduleactie en noemt 12 dollar per maand voor Core met 10.000 credits, gecontroleerd op dezelfde datum. n8n vermeldt 20 euro per maand voor Cloud Starter bij jaarlijkse facturatie en 2.500 workflow-executions, eveneens gecontroleerd op 23 september 2026.

Kies de goedkoopste route die jouw uitzonderingen nog eerlijk kan tonen. Zodra een fout niet meer zichtbaar is maar direct een refund, voorraadmutatie of btw-boeking veroorzaakt, is de prijs van de tool niet meer je belangrijkste kostenpost. Dan betaal je voor herstel.

Een retourproces is pas betrouwbaar wanneer product, betaling en administratie dezelfde beslissing vertellen. De inspectie is het moment waarop je die beslissing neemt. Alles daarna moet haar exact uitvoeren, kunnen uitleggen en veilig opnieuw kunnen afspelen. Dat is de grens tussen een knop die meestal werkt en een retourketen waarop je cijfers durven rusten.