Waarom retourstromen in de groothandel anders zijn
Een verkooporder heeft één richting: product verlaat het magazijn, factuur gaat de deur uit. Een retouropdracht draait dat proces om, maar de onderliggende datavragen zijn veel complexer. Welke klant stuurt terug? Op basis van welke originele order? Is het artikel nog verkoopbaar, aan te hechten aan een andere partij, of gaat het retour naar de leverancier? Moet de creditnota het volledige orderbedrag dekken of een gedeelte? Standaard ERP-pakketten zijn ontworpen rondom de uitstroom. De retourmodule is er vaak later bij gebouwd, als een workaround op de bestaande orderstructuur. Dat merk je direct in de operatie.
Knelpunt 1: de retourorder staat procesmatig op zijn kop
In de normale orderflow is de volgorde helder: order bevestigen, picken, pakken, verzenden, factureren. Bij een retour is de volgorde afhankelijk van wie er initiatief neemt, wat de reden is en wat er met het artikel moet gebeuren. Een klant meldt een retour via de buitendienst, per e-mail, of via een webshop. Iemand moet dat omzetten naar een retourorder in het systeem, een retourautorisatie aanmaken en de chauffeur informeren voor het ophalen. In de praktijk loopt dit via losse stappen in het ERP, aangevuld met een Excel of een notitie in de orderregel. Het systeem dwingt geen volgorde af, bewaakt geen statussen en geeft geen signaal als een retourautorisatie lang openstaat. De medewerker houdt het bij in zijn hoofd, totdat er iets misgaat.
Knelpunt 2: creditnota's worden handmatig aangemaakt en bevatten fouten
Een creditnota bij een retour klinkt simpel: zet de factuur terug. Maar in de groothandel is dat zelden zo. De klant retourneert een deel van een order, mogelijk met een andere hoeveelheid dan besteld. Er zijn staffelprijzen van toepassing die niet meer gelden bij een kleinere afname. Er is BTW-correctie nodig. En de inkoopprijs op het moment van retour wijkt soms af van de inkoopprijs op het moment van levering. Veel pakketten bieden geen automatische koppeling tussen de retourorder en de originele factuurregels. De administratief medewerker opent de originele factuur, kopieert de bedragen en maakt handmatig een creditnota aan. Dat levert fouten op, kost tijd en is bij grotere volumes niet schaalbaar. Bovendien wordt de creditnota pas aangemaakt als het artikel al terug in het magazijn ligt, waardoor de klant soms weken wacht op zijn geld.
Knelpunt 3: voorraadbeheer weet niet wat het met het retourartikel moet
Een artikel komt terug het magazijn in. Gaat het terug in de vrije voorraad? Moet het geïnspecteerd worden voor het opnieuw verkocht kan worden? Is de houdbaarheid nog in orde? Moet het retour naar de leverancier? Standaard WMS- en voorraadbeheermodules kennen doorgaans twee statussen: beschikbaar of gereserveerd. Een retourstatus, quarantainestatus of een kwaliteitsbeoordeling is een maatwerkveld of ontbreekt volledig. Het gevolg: het artikel wordt direct teruggeboekt op de beschikbare voorraad, ook als het nog beoordeeld moet worden. Een verkoper ziet het als beschikbaar en verkoopt het door, terwijl de magazijnmedewerker het artikel apart heeft gezet voor inspectie. De fout komt pas aan het licht bij de volgende pick, als de klant belt over een artikel in slechte staat.
Waarom standaardpakketten hier slecht in zijn
De drie knelpunten hierboven zijn geen uitzonderingen. Ze zijn structureel, omdat standaardpakketten voor de groothandel zijn ontworpen rond het verkoop- en leveringsproces. De retourmodule is een aanvulling, geen kern. Dat heeft gevolgen voor de configuratiemogelijkheden, de integratie met de financiële module en de statusbewaking. Aanpassingen via maatwerkvelden of extra modules zijn mogelijk, maar elke update van het pakket kan die aanpassingen breken. Bovendien zijn de werkstromen in het pakket star: ze gaan ervan uit dat retourprocessen verlopen zoals de leverancier ze heeft bedacht, niet zoals jouw groothandel ze uitvoert. Voor bedrijven met weinig retouren is dat te dragen. Voor groothandels met een hoog retourvolume, seizoenspieken of specifieke kwaliteitseisen, zoals in food, bouw of technische handelsbedrijven, is het een structureel knelpunt.
Wanneer is maatwerk of een gerichte module de enige haalbare route?
Maatwerk of een gerichte retourmodule wordt de juiste keuze op het moment dat drie dingen samenkomen: het retourvolume is hoog genoeg om schaalvoordeel te halen uit automatisering, de retourredenen zijn divers genoeg om verschillende werkstromen te vereisen, en de ERP-integratie is te complex om met een standaardkoppeling op te lossen. In dat geval bouw je een module die de retourstatus bewaakt van aanmelding tot creditnota, de kwaliteitsbeoordeling als verplichte stap inbouwt voor herplaatsing op voorraad, en de creditnotaberekening direct koppelt aan de originele factuurregels inclusief de geldende staffelprijzen. Je kunt dit als AI Worker bouwen op het bestaande systeem, als er een bruikbare basis ligt. Als het onderliggende ERP te rigide is om de retourdata goed vast te leggen, is het soms slimmer om het kernsysteem opnieuw te bouwen met de retourlogica als onderdeel van de kernarchitectuur, in plaats van er steeds omheen te werken. De afweging is altijd: hoeveel kost het handmatige werk nu, en hoe lang wil je dat nog betalen?