Winst per product op Amazon FBA berekenen: de nettomarge per SKU die echt klopt

De winst per product op Amazon FBA staat of valt met de kwaliteit van je COGS-invoer, niet met de formule. De formule is bekend en simpel. Het cijfer dat eruit rolt is alleen zo betrouwbaar als de kostprijs die je erin stopt, en daar gaat het bij vrijwel elke verkoper die ik spreek mis.

Kort antwoord. Bereken winst per product op Amazon FBA als: verkoopprijs minus referral fee (8-15%), FBA fulfillment fee, opslag per unit, PPC per verkoop, retourimpact en je landed cost (COGS plus inbound, prep, douane). Wat overblijft is je nettomarge per SKU. De berekening is zo accuraat als je COGS-invoer.

De formule die telt voor een gevestigde verkoper

Je kent de happy-path-versie al. Voor een schalende seller schrijf ik hem zo:

Nettowinst per SKU = verkoopprijs − referral fee − fulfillment fee − opslag per unit − PPC per verkoop − retourimpact − landed cost.

De referral fee zit voor de meeste categorieën rond 15%, electronics rond 8%, kleding hoger. De fulfillment fee hangt aan size tier en gewicht. Tot zover dekt elke calculator dit, inclusief de FBA-calculator van Helium 10. Het probleem zit niet in deze regels. Het zit in de twee onderaan: retourimpact en landed cost.

Landed cost is waar het cijfer wint of verliest

COGS is niet je inkoopprijs. Landed cost is COGS plus inbound freight, prep, douane en invoerrechten, eventueel tooling uitgesmeerd over je units, en een buffer. Wie alleen de factuurprijs van de leverancier invoert, telt structureel een te hoge marge. Bij een container met sterk wisselende vrachtkosten of een product met dure prep verschuift je echte marge per SKU zomaar 5 tot 8 procentpunt. Dat is het verschil tussen een SKU die je opschaalt en eentje die je geld kost terwijl je dashboard groen staat.

Tools als Sellerboard berekenen de nettowinst keurig zodra de COGS erin staat. Sellerboard zelf benoemt dat landed cost meer is dan inkoop alleen. Maar de tool weet niet wat jouw landed cost is. Die moet ergens vandaan komen, per batch, per leverancier, per inbound shipment. Dat is precies de invoer die bij de meeste verkopers handmatig, verouderd of geschat is.

Retourimpact en opslag: de stille marge-eters

Retouren verlagen je effectieve verkoopprijs en je krijgt lang niet altijd alle fees terug. Een SKU met 12% retouren en beschadigde retourvoorraad draagt een heel andere marge dan dezelfde SKU op papier. Opslag hoort per unit toegerekend, niet als maandelijkse hoop. Langzame lopers met een lage IPI vreten opslag en die kost moet op de SKU landen waar hij hoort, anders subsidieer je je verliezers met je winnaars zonder het te zien.

Waarom een standaardtool hier stopt

Sellerboard en Helium 10 dekken het gelukspad uitstekend: een seller, Amazon, schone COGS. Mijn klanten zitten daar voorbij. Ze verkopen ook op bol en een eigen webshop, kopen in batches met wisselende landed cost, en hun kostprijs leeft in een ander systeem dan hun marge-tool. De vraag is niet "welke tool", de vraag is: klopt de marge per product over alle kanalen samen, gevoed door COGS die actueel is?

Daar bouw ik aan. Eerst doorlicht ik het proces: welke stappen in jouw COGS-keten zijn gegroeid handwerk dat slimmer of weg kan. Vaak blijkt een halve dag spreadsheet-werk per maand een koppeling te zijn die niemand ooit heeft gelegd. Daarna bouw ik de oplossing die jouw uitzonderingen wel pakt: een landed-cost-feed per batch de marge-tool in, of een eigen dashboard dat Amazon, bol en webshop op SKU-niveau naast elkaar zet. De berekening moet gebeuren. Ik zorg dat hij klopt waar de standaardtool jouw situatie niet dekt.