Meerdere leveranciers Ordersplitsing en tracking Retouren en margeregels

Dropshipping-webshop laten maken

Een webshop bouwen is niet het moeilijke deel. Het moeilijke deel is meerdere leveranciers tegelijk betrouwbaar houden: voorraad die uit verschillende bronnen komt en verschillend veroudert, orders die uiteenvallen in meerdere zendingen, retouren die nooit langs uw magazijn gaan en marges die per leverancier verschillen. Appfront bouwt de logica die dat sluitend maakt.

Wanneer u op deze pagina zit

Deze pagina gaat over webshops die verkopen wat een ander verzendt, en vooral over de situatie met meer dan één leverancier. Uw catalogus is dan een samenvoeging van bronnen die u niet beheert: de een levert 's nachts een CSV- of XML-bestand op een SFTP-server, de ander een API, een derde een spreadsheet.

Zit u daar niet in, dan is een andere pagina nuttiger. Houdt u zelf voorraad of werkt u met één leverancier, kijk dan naar een webshop laten maken. Draait u al op WordPress, dan is een WooCommerce-webshop vaak de snelste route. Verkoopt u aan zakelijke afnemers met eigen prijsafspraken en staffels, dan hoort dat thuis in een B2B e-commerceportaal.

Het onderscheid is niet cosmetisch. Bij een gewone webshop is voorraad een getal dat u bijhoudt; bij dropshipping is het een schatting van de werkelijkheid bij een derde, met een houdbaarheid die per leverancier verschilt.

Bronnen samenvoegen tot één catalogus

Feeds, API's en losse bestanden worden vertaald naar één intern productmodel, gematcht op GTIN, zodat dezelfde SKU bij twee leveranciers één artikel blijft.

Orders splitsen en routeren

Eén bestelling wordt opgeknipt in inkooporders per leverancier, elk met eigen bevestiging, zending en levertijd, terwijl de klant één order ziet.

Retour- en creditstroom sluitend

Van herroepingsmelding tot beoordeling, terugbetaling en creditnota, met per retour vastgelegd waar de kosten landen.

Vier plekken waar het in de praktijk misgaat

Deze vier worden pas zichtbaar bij volume, en laten zich niet oplossen met een instelling in het beheerscherm.

Het gat tussen een nachtfeed en een realtime API

Leverancier A en B voeren dezelfde SKU. A stuurt om 03:00 een bestand met voorraadstanden, B heeft een API die u realtime kunt bevragen. Om 15:00 verkoopt A zijn laatste stuk aan iemand anders. Uw winkel weet dat pas de volgende nacht en toont ondertussen een artikel als leverbaar dat het niet meer is. Bestelt een klant in dat gat, dan volgt oversell: annuleren, terugbetalen, uitleggen, en met enige kans een slechte review.

Vaker synchroniseren verplaatst het gat alleen. Wat wel werkt: per bron vastleggen hoe vers de data is, de buffer daarop afstemmen, en de voorkeursleverancier per orderregel kiezen op actualiteit in plaats van op inkoopprijs.

Eén order, drie zendingen, drie verwachtingen

Een klant bestelt drie artikelen en krijgt drie pakketten, van drie leveranciers, met drie trackingcodes en drie levertijden. De meeste platforms sturen daar drie losse verzendmails over. De klant leest de eerste, ziet één artikel aankomen en concludeert dat de rest kwijt is. Dat levert wismo-vragen op, de meldingen van klanten die willen weten waar hun bestelling blijft.

Het verschil zit in de communicatie, niet in de logistiek: een orderbevestiging die meerdere levermomenten noemt, een trackingpagina met de status per regel, en een systeem dat een uitblijvende zending opmerkt voordat de klant belt.

Retouren die nooit langs uw magazijn gaan

Het pijnlijkste deel, omdat het drie vragen tegelijk oproept die vaak pas bij de eerste retour worden gesteld. Stuurt de klant terug naar u of naar de leverancier? Wie beoordeelt of het product is zoals het hoort, en dus of er sprake is van waardevermindering? En wie crediteert wie: u betaalt de consument terug, maar krijgt u een creditnota, en wanneer?

Zonder een systeem dat elke retour aan een inkooporder, leverancier en creditregel koppelt, loopt uw administratie stil scheef: u betaalt consumenten terug voor goederen waarvoor u nooit gecrediteerd bent.

Marges die per leverancier en per regio verschillen

Inkoopprijzen wijzigen, soms met elke feed. Leverancier A rekent verzendkosten per zending, B per artikel en C hanteert een toeslag voor de Waddeneilanden. Voert u één opslagpercentage over de hele catalogus, dan verkoopt u een deel van uw assortiment onder de kostprijs zodra de inkoopprijs stijgt, en dat ziet u niet, want de order kwam gewoon binnen.

Prijsbepaling is daarom een eigen stuk logica: regels per leverancier, productgroep en verzendregio, met een minimummarge die een artikel uit de verkoop haalt in plaats van het met verlies te verkopen.

Van leveranciersfeed tot creditnota

In de kern is dit een keten van vier bewerkingen, elk met eigen faalgedrag. Daar zit het verschil tussen een winkel die stil scheefloopt en een winkel die zichzelf corrigeert.

1
Importeren en normaliseren

Per leverancier een eigen vertaallaag naar één intern model, gematcht op GTIN, met controles die een halve of lege feed tegenhouden.

2
Beschikbaarheid bepalen

Per artikel bepalen wat verkoopbaar is: buffers per bron, een levertijdbelofte per leverancier en een minimummarge als ondergrens.

3
Splitsen en bestellen

De order valt uiteen in inkooporders per leverancier, via API, EDI of feed. Blijft een bevestiging uit, dan wordt dat een taak.

4
Terugkoppelen en afletteren

Verzendberichten, trackingcodes, retouren en creditnota's landen op de oorspronkelijke orderregel, zodat verkoop, inkoop en boekhouding aansluiten.

U blijft de verkoper, wie er ook verzendt

Dat is het uitgangspunt waar het ontwerp op rust. Voor de consument bent u de wederpartij, ook als het pakket komt uit een magazijn dat u nooit zag. De conformiteitseis van artikel 7:17 BW en de wettelijke garantie liggen bij u, en bij een consumentenkoop levert u onverwijld en in elk geval binnen dertig dagen. Het herroepingsrecht van veertien dagen na ontvangst geldt onverkort; de consument is alleen aansprakelijk voor waardevermindering als hij verder ging dan nodig om de aard, de kenmerken en de werking van het product vast te stellen.

De ACM heeft voor dropshipping een aparte checklist en houdt daar toezicht op. Twee punten raken direct uw software: u moet vóór de koop vermelden wat de plaats of het land van verzending is en dat een derde rechtstreeks aan de koper levert, en een in Nederland gevestigde webshop moet een Nederlands retouradres tonen. Herkomst en retourbestemming moeten dus per orderregel bekend zijn.

Komt een product van buiten de EU, dan speelt de algemene productveiligheidsverordening, Verordening (EU) 2023/988, sinds 13 december 2024 van toepassing, die een verantwoordelijke marktdeelnemer in de EU vereist. Ontbreekt die, dan komt de rol al snel bij u. Fiscaal is de vrijstelling voor kleine zendingen per 1 juli 2021 vervallen; onder de drempelwaarde geldt de invoerregeling (IOSS).

  • Land van verzending per orderregel vastgelegd
  • Retouradres en retourkosten per leverancier
  • Levertijdbelofte per bron, niet winkelbreed
  • Herroeping en waardevermindering als eigen proces
  • Btw- en invoerlogica los van de prijsregels
CSV-, XML- en JSON-feeds SFTP-import met validatie REST- en GraphQL-API's EDI: ORDERS, ORDRSP, DESADV PRICAT en INVRPT GTIN-matching Webhooks en wachtrijen PostNL, DHL en DPD Sendcloud en MyParcel Mollie en Adyen Exact Online
Nog niet zeker over een groot traject?

Test je idee eerst — werkend prototype in 1 dag

Met OneDayBuild maken we je idee in één dag tastbaar voor €950, zodat je weet of verdere ontwikkeling de investering waard is. Besluit je door te gaan met de volledige bouw? Dan verrekenen we de kosten volledig.

Bekijk OneDayBuild →

Wanneer maatwerk hier niet het antwoord is

Heeft u één leverancier, een assortiment dat u overziet en verzendtarieven die niet per regio verschillen, dan bent u met een bestaand platform en de dropship-koppeling van die leverancier goedkoper en sneller klaar dan met maatwerk. Dat geldt voor een flink deel van de dropshipping-webshops, en het is geen tussenoplossing maar de juiste keuze. Wij zeggen dat liever in het eerste gesprek dan halverwege een traject.

Maatwerk begint pas te lonen bij meerdere leveranciers die deels hetzelfde assortiment voeren, bij margeregels die per leverancier of regio verschillen, of bij een leverancier zonder kant-en-klare koppeling. Ook vastlopen op de roadmap van een app-leverancier is een reëel moment om de logica in eigen hand te nemen.

Wees eerlijk over de last die erbij hoort: elke koppeling die u zelf laat bouwen wordt uw onderhoud. De verstandigste volgorde is daarom vaak de tussenvorm: houd uw bestaande webshop of WooCommerce-winkel, en laat alleen de voorraad-, order- en retourlogica erachter op maat bouwen.

  • Eén leverancier, standaard tarieven: bestaand platform
  • Overlappend assortiment bij twee of meer leveranciers: maatwerk
  • Marge- of verzendregels per leverancier of regio: maatwerk
  • Leverancier zonder kant-en-klare koppeling: maatwerk
  • Retouren die met de boekhouding moeten sluiten: maatwerk
  • Zakelijke afnemers met eigen condities: B2B-portaal

Veelgestelde vragen over een dropshipping-webshop

De vragen die we het vaakst krijgen vlak voordat iemand kiest.

Voert u één leverancier, een overzichtelijk assortiment en standaard verzendtarieven, dan bent u met een bestaand platform plus de koppeling van die leverancier sneller en goedkoper klaar dan met maatwerk. Voor een flink deel van de dropshipping-webshops is dat de juiste keuze. Maatwerk wordt pas logisch bij meerdere leveranciers met overlappend assortiment, afwijkende margeregels, of een leverancier zonder kant-en-klare koppeling. Vaak is de tussenvorm het verstandigst: alleen de logica achter uw platform op maat.

U. Voor de consument bent u de verkoper, ongeacht wie het pakket verstuurt. De conformiteitseis van artikel 7:17 BW en de wettelijke garantie liggen bij u, en bij een consumentenkoop levert u onverwijld en in elk geval binnen dertig dagen. Dat u schade later op uw leverancier kunt verhalen, verandert niets aan uw positie richting de klant. Uw systeem moet u dus vroeg waarschuwen: een uitblijvende orderbevestiging is een signaal om de klant te informeren.

Volledig uitsluiten kan niemand: tussen uw laatste voorraadupdate en het moment van bestellen zit altijd tijd. Wat wel kan, is per bron vastleggen hoe actueel die is en de buffer daarop afstemmen. Een leverancier die eenmaal per nacht een bestand stuurt krijgt een ruimere marge dan een leverancier met een realtime API. Wat overblijft vangt u op met een duidelijk bericht en een alternatief, niet met een stille annulering.

Dat vraagt een expliciete keuze vooraf. Juridisch is het helder: de consument heeft veertien dagen bedenktijd na ontvangst, meldt de herroeping bij u en krijgt van u terugbetaald. Is uw webshop in Nederland gevestigd, dan moet u volgens de ACM een Nederlands retouradres vermelden. Operationeel zijn er twee routes: alles komt eerst bij u binnen, of de klant stuurt rechtstreeks naar de leverancier die de ontvangst terugmeldt. De eerste geeft zicht op de waardevermindering, bij de tweede staat of valt alles met die terugmelding.

Feedwijzigingen zijn de belangrijkste terugkerende beheerlast van een dropshipping-webshop. Daarom krijgt elke leverancier een eigen vertaallaag naar één intern model: verandert er iets aan zijn kant, dan raakt dat die ene vertaling en niet uw hele catalogus. Op de import zitten controles, zodat een halve of lege feed wordt geblokkeerd in plaats van doorgevoerd. De opgeleverde code, repository en documentatie zijn van u, zodat een andere partij het beheer kan overnemen.

Ja. De algemene productveiligheidsverordening, Verordening (EU) 2023/988, is sinds 13 december 2024 van toepassing en vereist dat er voor elk product een verantwoordelijke marktdeelnemer in de EU is. Zit de fabrikant buiten de EU en is er geen gemachtigde of importeur, dan komt die rol al snel bij u te liggen. Fiscaal is de vrijstelling voor kleine zendingen per 1 juli 2021 vervallen; onder de drempelwaarde kunt u de invoerregeling (IOSS) gebruiken.

Gerelateerde diensten

Past dropshipping niet op uw situatie, dan sluit een van deze pagina's beter aan.

Webshop laten maken

Voor wie zelf voorraad houdt of met één leverancier werkt: assortiment, checkout en betalingen.

WooCommerce-webshop laten maken

Voor wie op WordPress zit of daarheen wil, met ruimte om er later eigen orderlogica achter te zetten.

B2B e-commerceportaal laten maken

Voor zakelijke afnemers met klantspecifieke prijzen, staffels en goedkeuringsstappen.

Uw leveranciers op een rij zetten?

Vertel ons met hoeveel leveranciers u werkt, hoe zij voorraad en prijzen aanleveren en waar het nu wringt: oversell, opgeknipte orders, retouren of marges. In een eerste gesprek maken we samen de afweging of u hier maatwerk voor nodig heeft.

Edit Content