Preisberechnung für Produktbündel: klare Rabatte und genaue Bestände

Warum Bündel die Preis‑ und Bestandsführung kaputt machen, wenn man es improvisiert

Für Käufer wirken Bündel einfach: „dies zusammen kaufen und sparen“. Intern berühren sie aber Preisgestaltung, Steuern, Aktionen, COGS und Bestand gleichzeitig. Ohne klare Regeln entsteht ein Checkout, der zwar richtig aussieht, während sich die Berichte schleichend von der Realität entfernen.

Zwei Dinge gehen meist zuerst schief: der Rabatt ist unklar und die Bestände werden unzuverlässig. Ein Kunde sieht vielleicht einen Bündelpreis, dann noch zusätzliche Gutscheine, „Vergleichspreis“-Angaben oder Einzelartikelrabatte, die so kombiniert werden, dass die Ersparnis schwer nachzuvollziehen ist. Intern sind sich Systeme oft uneinig, ob das Bündel als ein Artikel oder als mehrere Artikel verkauft wurde.

Die beiden wichtigsten Risiken sind:

• Unklare Rabatte: Kunden wissen nicht, was sie gespart haben; der Support bekommt mehr „Wurde ich richtig berechnet?“-Tickets, und die Finanzabteilung kann Einnahmen nicht einfach erklären.
• Falsche Bestände: Du verkaufst ein Kit, aber nur die Kit‑SKU wird vermindert, nicht die Komponenten, sodass Teile überverkauft werden oder Kapital in überhöhten Beständen festhängt.

Ein Bündel kann auch auf dem Papier profitabel aussehen und dennoch Verluste verursachen. Das passiert, wenn Umsatz auf Bündel‑Ebene erfasst wird, Kosten aber auf Komponentenebene (oder gar nicht) nachverfolgt werden. Du siehst in einem Dashboard vielleicht eine gesunde „Bündel‑Bruttomarge“, während die Kosten eines teuren Bestandteils ignoriert, doppelt rabattiert oder häufiger erstattet werden als erwartet.

„Genau“ sollte vier praktische Dinge bedeuten:

1. Der Checkout hält das Versprechen ein: Der Kunde sieht Bündelpreis und Ersparnis einheitlich.

2. Verkaufsberichte sind erklärbar: Du kannst beantworten: „Wie viele Einheiten jedes Artikels haben wir tatsächlich bewegt?“ und „Wie viel Rabatt haben wir gewährt?“

3. Der Bestand bleibt ehrlich: Wenn ein Bündel verschickt wird, werden die richtigen Mengen jeder Komponente abgebucht, selbst wenn das Lager aus verschiedenen Fächern pickt.

4. Rückgaben verfälschen die Daten nicht: Wenn ein Kunde ein Teil eines Kits zurückgibt, weiß das System, wie Umsatz, Rabatt und Bestand anzupassen sind, ohne zu raten.

Mit klarer Preisberechnung für Bündel und einer einzigen Inventarregel werden die restlichen Entscheidungen für Bündel viel einfacher.

Häufige Bündel‑ und Kit‑Typen (und was sie implizieren)

Bevor du irgend eine Preisrechnung für Produktbündel machst, benenne den Bündeltyp. Der Typ bestimmt, was Kunden sehen, wie du Marge misst und wie sich der Bestand bewegen soll.

Ein reines Bündel heißt: „diese Artikel müssen zusammen gekauft werden“. Denk an „Kameragehäuse + Objektiv + Tasche“ als ein Angebot. Das benötigt meist einen klaren Bündelpreis, eine nachvollziehbare Rabattdarstellung (gegenüber dem Einzelkauf) und konsistente Bestandsabzüge für dieselben Komponenten.

Ein Mix‑and‑Match‑Set ist: „Wähle 3 aus dieser Gruppe“. Preisgestaltung und Bestand werden komplizierter, weil die Komponenten variieren. Hier brauchst du oft Regeln wie „gleicher Preis egal welche Auswahl“ (einfach, aber die Margen schwanken) oder „Preis hängt von den gewählten Artikeln ab“ (klarere Margen, mehr Komplexität).

Kits, Multipacks und Sortimente klingen ähnlich, verhalten sich aber unterschiedlich:

• Ein Kit ist ein kuratiertes Set verschiedener SKUs, das eine Aufgabe löst (Starter‑Kit, Reparatur‑Kit). Kunden erwarten Anleitung und einen spürbaren Rabatt.
• Ein Multipack ist mehrere gleiche SKUs (6er‑Pack Socken). Die Bestandsrechnung ist einfach: es ist nur Menge.
• Ein Sortiment ist eine gemischte Packung, deren genaue Mischung fest oder variabel sein kann (Snack‑Box). Variable Sortimente brauchen zusätzliche Regeln für Ersatz.

Ein Bündel sollte seine eigene SKU bekommen, wenn du stabile Berichte und Abläufe brauchst. Gründe dafür:

• Du willst einen eigenen Barcode/Label fürs Picking.
• Du schaltest Werbung oder verkaufst über Marktplätze, die eine einzelne SKU verlangen.
• Du brauchst saubere Verkaufsberichte pro Bündel (nicht nur pro Komponente).
• Du planst, den Bündelpreis oft zu ändern, ohne die Komponentenpreise anzufassen.

Vermeide Bündel, wenn das „Bündel“ eigentlich nur ein temporärer Rabatt ist. Können die Artikel separat gekauft werden und ändert sich das Set wöchentlich, dann hält ein Promo‑Rabatt an der Kasse dein Katalog sauberer und reduziert Inventarüberraschungen.

Preisrechnung, die Rabatte klar hält

Kunden rechnen selten selbst nach. Sie vergleichen den heutigen Bündelpreis mit dem, was sie denken, die Artikel einzeln kosten würden. Deine Aufgabe ist, diesen Vergleich einfach und konsistent zu machen, damit der Rabatt echt wirkt und deine Preisregeln stabil bleiben.

Beginne damit, für jedes Bündel zwei Preise zu definieren:

• Listenpreis (Referenz): Summe der aktuellen, öffentlichen Preise der enthaltenen Artikel (mit den spezifischen Varianten im Bündel).
• Bündelpreis (zu zahlender Betrag): der tatsächliche Verkaufspreis der Bündel‑SKU.

Berechne den Rabatt dann auf eine einheitliche Weise und halte dich daran:

Rabattbetrag = Listenpreis - Bündelpreis

Rabatt in % = Rabattbetrag / Listenpreis

Das ist die einfachste Form der Preisrechnung für Produktbündel und entspricht dem, was die meisten Käufer erwarten.

Rundung ist ein Punkt, an dem Vertrauen verloren geht. Wenn dein Warenkorb $79.99 zeigt und „20% Rabatt“, werden Kunden das nachrechnen. Wähle Regeln, die ungeschickte Cent‑Differenzen vermeiden.

Praktische Regeln:

• Runde den Bündelpreis nach deinem üblichen Einzelhandelsschema (z. B. auf .99 endend).
• Berechne den Rabatt in % aus nicht gerundeten Werten und zeige ihn dann abgerundet als ganze Prozentzahl an.
• Wenn du „Spare $X“ anzeigst, runde die Ersparnis auf den nächsten Cent ab.
• Zeige niemals einen Rabatt an, wenn er unter einer kleinen Schwelle liegt (z. B. unter 1%).

Bündel mit Optionen brauchen noch eine Entscheidung: Preisst du vom günstigsten möglichen Konfigurationspreis aus oder vom vom Käufer tatsächlich gewählten Preis? Bei „Wähle 1 von 3“ berechne den Listenpreis anhand der gewählten Variante, nicht eines Mittels, damit die angezeigte Ersparnis ehrlich bleibt.

Entscheide außerdem, was passiert, wenn Komponentenpreise später steigen oder fallen. Der sauberste Ansatz ist, den Bündelpreis als eigene Entscheidung zu behandeln: Belasse ihn fix, bis du ihn bewusst anpasst, und berechne den angezeigten „Vergleichspreis“ aus den aktuellen Komponentenpreisen. Wenn das die Ersparnis zu stark schwanken lässt, setze einen Review‑Trigger (z. B. wenn sich der Rabatt um mehr als 5 Prozentpunkte ändert), damit du vor der Wahrnehmung durch Kunden anpassen kannst.

Margenrechnung: Gewinn messbar machen

Ein Bündelrabatt ist nur dann „gut“, wenn du den Gewinn weiterhin sehen kannst. Fang damit an, COGS (Cost of Goods Sold) auf Komponentenebene festzulegen. Jeder Artikel im Kit braucht einen aktuellen Stückkostenwert (was du bezahlst), plus Bündel‑spezifische Kosten wie zusätzliche Verpackung.

Die Bündel‑COGS sind simpel: addiere die Komponenten‑COGS multipliziert mit den Mengen im Bündel, und addiere Verpackung und Handling.

Bundle COGS = Σ (component unit COGS × component quantity) + packaging + handling
Gross margin $ = bundle price - Bundle COGS - shipping subsidies
Gross margin % = Gross margin $ / bundle price

Beispiel: Ein „Starter Kit“ wird für $99 verkauft.

• Komponente A kostet $28, Komponente B $12, Komponente C $8.
• Das Kit enthält je 1 Stück.
• Zusätzliche Box und Einleger kosten $3.
• Du bezahlst als Aktion $6 Versandzuschuss.

Bundle COGS = 28 + 12 + 8 + 3 = $51

Gross margin $ = 99 - 51 - 6 = $42

Gross margin % = 42 / 99 = 42.4%

Das ist der Kern der Preisrechnung für Produktbündel: Der Rabatt wirkt für den Käufer klar, und die Marge bleibt für dich sichtbar.

Für Berichte musst du Umsätze möglicherweise wieder auf Komponenten verteilen (für Kategorieumsatz, Provisionen oder Steuerberichte). Ein üblicher Ansatz ist die proportionale Zuordnung basierend auf dem Einzelpreisanteil: Wenn A 50% des Gesamtwerts ausmacht, erhält es 50% des Bündelumsatzes. Halte die Zuordnungsregel konstant, damit Monatsvergleiche stabil bleiben.

Setze vor Veröffentlichung Guardrails, die schlechte Bündel verhindern:

• Mindest‑Bruttomarge in % für jedes Bündel (z. B. 35%)
• Mindest‑Bruttomarge in $ pro Bestellung (schützt bei günstigen Kits)
• Versandzuschuss‑Limit pro Bestellung (Versand kann Margen aufzehren)
• Verpackungs‑ und Pick‑Zeit in COGS einbeziehen für Kits, die länger zusammenzustellen sind

Diese scheinbar kleinen Kosten wachsen schnell. Wenn ein Kit spezielle Verpackung braucht, behandle das als echte COGS, nicht als Rundungsfehler.

Bestandsabzugsmodelle, die genau bleiben

Wenn Preisgestaltung das Versprechen ist, ist Inventar die Wahrheit. In dem Moment, in dem ein Bündel verkauft wird, muss dein Bestandssystem schnell beantworten: Welche physischen Artikel haben gerade das Lager verlassen?

Modell A: Komponentenbestand beim Verkauf abziehen

Du führst nur Komponenten auf Lager. Wenn das Bündel verkauft wird, ziehst du die benötigten Mengen jeder Komponente ab (z. B. 1 Flasche + 2 Filter). Das ist die sauberste Option, wenn das „Bündel“ hauptsächlich ein Preiskonzept ist.

Es funktioniert am besten, wenn Picker das Kit während der Erfüllung zusammenstellen. Es hält die Preis‑/Kostenrechnung ehrlich, weil du sehen kannst, ob der Rabatt durch geringere Versandkosten, höhere Conversion oder einfach geringere Marge „bezahlt“ wird.

Modell B vs Modell C: Kit‑SKU‑Bestand oder virtuelle Reservierung

Modell B behandelt das Kit als echtes gelagertes Produkt mit eigenem On‑Hand‑Wert. Du stellst Kits im Voraus zusammen und ziehst pro Verkauf 1 Kit ab. Du brauchst einen Build‑Schritt, der beim Zusammenstellen die Komponenten verbraucht, sonst sind die Komponentenbestände falsch.

Modell C behält eine virtuelle Bündel‑SKU fürs Verkaufen und Reporting, reserviert aber Komponenten zum Bestellzeitpunkt (nicht Versandzeitpunkt). Reservierung verhindert Überverkäufe bei knappen Beständen oder verzögerter Zahlungsfreigabe.

Eine einfache Auswahlhilfe:

• Brauchst du sehr schnelles Picking und konsistente Verpackung? Modell B.
• Brauchst du die genaueste Komponentenverfügbarkeit? Modell A.
• Brauchst du starken Schutz gegen Überverkauf bei Backorders oder langen Zahlungsfenstern? Modell C.
• Brauchst du saubere Berichte pro Bündel‑SKU ohne die Komponentenwahrheit zu verlieren? Modell C.
• Brauchst du minimale Änderungen im Lager und flexible Tauschoptionen? Modell A.

Mehrere Lagerstandorte fügen eine Regel hinzu: Ziehe dort ab, wo die Artikel tatsächlich verschickt werden. Bei Modell A oder C sollte die Komponentenauswahl lager‑spezifisch erfolgen (Lager 1 hat vielleicht das Ladegerät, Lager 2 nicht). Bei Modell B musst du Kit‑Bestände pro Lager verfolgen und Transfers oder Montageaufträge nutzen, um Kits zu verschieben.

Ein kurzes Beispiel: Du verkaufst ein „Starter Kit“ mit 1 Becher und 1 Deckel. Hat Lager A Becher, aber keine Deckel, kann Modell A nur verkaufen, wenn die Bestellung an ein Lager mit beiden Artikeln geleitet wird oder wenn du Split‑Ship akzeptierst (mit zusätzlichen Versandkosten). Modell B vermeidet diese Verwirrung, indem komplette Kits dort gelagert werden, wo sie verschickt werden können.

Schritt‑für‑Schritt: Ein Bündel im Katalog und Bestandsystem modellieren

Ein Bündel verhält sich nur dann gut, wenn Katalog und Inventar darin übereinstimmen, was verkauft wird: ein neuer Artikel oder ein Set bestehender Artikel. Entscheide zuerst, was getrackt, bepreist und retourniert werden soll.

Ein einfacher Modellierungsablauf

Verwende diesen Ablauf, um ein Bündel einzurichten (und dieselben Regeln für weitere wiederzuverwenden):

1. Entscheide, ob das Bündel eine eigene SKU bekommt. Nutze eine Bündel‑SKU für separate Berichte, ein eigenes Barcode‑Label, besondere Bilder oder eine abweichende Rückgabepolitik. Überspringe die Bündel‑SKU, wenn es nur ein Checkout‑Convenience ist und du nur die Komponentenverkäufe sehen willst.
2. Definiere ein Stücklisten‑BOM. Liste jede Komponente und Menge (auch „langweilige“ Dinge wie Kabel, Einleger oder Batterien). Diese BOM ist die Quelle der Wahrheit für Bestandsabzüge.
3. Lege Preis‑ und Rabatt‑Anzeige‑Regeln fest. Wähle eine Methode und bleibe dabei: entweder (a) zeige den Bündelpreis mit einem klaren „Du sparst X“ gegenüber der Summe der Komponenten, oder (b) verteile den Rabatt auf die Komponenten für sauberere Margenreports. Hier sollte die Preisrechnung für Produktbündel explizit dokumentiert werden.
4. Wähle den Abzugszeitpunkt. Ziehe bei Bestellaufgabe ab, wenn du schnell erfüllst und Überverkäufe vermeiden willst. Ziehe bei Versand ab, wenn du Backorders akzeptierst oder oft Bestellungen änderst. Bei „reserviertem Bestand“ reservierst du bei Bestellung und ziehst beim Versand ab.
5. Teste Randfälle vor dem Launch. Probiere niedrigen Bestand einer Komponente, Teillieferungen, Ersatzartikel und die Rückgabe nur eines Teils des Kits.

Szenario zur Validierung: Du verkaufst ein „Starter Kit“ mit 1 Becher und 2 Kaffeepackungen. Sind Becher aus und Kaffeepackungen nicht, sollte dein Storefront das Bündel blockieren oder klar als nachbestellt markieren, und dein System darf niemals 2 Kaffeepackungen abziehen, ohne auch den Becher zu reservieren.

Wenn du benutzerdefinierte Workflows baust, kann ein Tool wie Koder.ai helfen, die Bündelregeln (SKU, BOM, Abzugszeitpunkt) einmal zu definieren und dann Katalog‑ und Bestandslogik konsistent über Web‑ und Backend‑Systeme zu erzeugen.

Erfüllung, Ersatz und Rückgaben ohne verwirrende Mathematik

Bündel werden schmerzhaft, sobald die Realität eintrifft: Ein Artikel fehlt, der Kunde will tauschen oder die Rückgabe ist nur teilweise. Am einfachsten bleibt man, wenn die kundennahe Bestellung einfach bleibt (eine Bündelzeile), während Erfüllung und Bestand auf Komponentenebene verfolgt werden.

Ist eine Komponente nicht vorrätig, entscheide im Vorfeld, ob das Bündel teilweise verschickt werden darf oder warten muss. Erlaube Teilversand, so ziehe nur für das tatsächlich Versendete Bestände ab und halte den Rest reserviert, damit du nicht überverkaufst. Die Bündelzeile bleibt „teilweise erfüllt“, aber dein Bestandsbuch bleibt sauber.

Ersatz ist in Ordnung, solange es kontrolliert erfolgt und nicht willkürlich. Setze Ersatzregeln, die Reporting und Marge erhalten:

• Ersetze nur innerhalb vordefinierter Gruppen (gleiche Größe, Art oder Kostenklasse).
• Dokumentiere geplante Komponente und ausgelieferte Komponente in der Erfüllung.
• Der Preis bleibt der Bündelpreis, es sei denn, ein Aufpreis oder eine Gutschrift wird ausdrücklich genehmigt.
• Kostet der Ersatz mehr, buche die Mehrkosten, damit die Bündel‑Marge korrekt bleibt.

Rückgaben brauchen zwei Pfade: vollständige Kit‑Rückgabe und Rückgabe einzelner Komponenten. Beispiel: Ein „Starter Kit“ wurde für $90 verkauft (reduziert von $100). Es enthält eine Flasche ($40 Listenpreis) und eine Bürste ($60 Listenpreis). Gibt das ganze Kit zurück, buche beide Komponenten zurück und erstatte $90.

Gibt nur die Bürste zurück, erstatte einen anteiligen Anteil des bezahlten Bündelpreises, nicht den Einzelpreis der Bürste. Eine einfache, verteidigungsfähige Methode ist die Proratisierung nach Listenpreis.

• Gewicht berechnen: Bürstenanteil = 60 / (40 + 60) = 60%.
• Rückerstattung = $90 × 60% = $54 (zzgl. anfallender Steuerregeln).
• Nur die Bürste wieder einlagern und nur deren Kosten in der Margenberichterstattung umkehren.

So bleiben Rabatte nachvollziehbar, „kostenlose“ Rückerstattungen werden vermieden und Inventar driftet nicht über die Zeit.

Häufige Fehler und Fallen (und wie man sie vermeidet)

Bündel scheitern meist aus banalen Gründen: Katalogregeln sind unklar und die Mathematik wird doppelt angewandt. Die Lösung ist, eine einzige Quelle der Wahrheit für Preis, Marge und Bestand zu wählen.

Die größte Inventar‑Falle ist, Bestand an zwei Stellen abzuziehen. Hast du eine Bündel‑SKU fürs Verkaufen, entscheide, ob sie virtuell ist (kein eigener Bestand) oder vorverpackt (eigene On‑Hand‑Mengen). Virtuelle Bündel dürfen nur die Komponenten abziehen. Vorgepackte Kits ziehen nur die Kit‑SKU ab, bis du eines öffnest.

Rabatte wirken auch größer, als sie sind, wegen Rundung. Ein Bündelpreis von $49.99 wirkt sauber, aber wenn jede Komponente unterschiedlich gerundet wird, verschiebt sich der implizite Rabatt um ein paar Cents pro Bestellung. Langfristig erzeugt das Support‑Aufwand und unordentliche Berichte. Wähle eine Rundungsregel und wende sie einmalig auf den finalen Bündelpreis an.

Häufige Fallen mit schnellen Gegenmaßnahmen:

• Vergiss „versteckte“ Kosten wie Verpackung, Pick‑/Pack‑Arbeit oder Einleger. Füge eine Handling‑Kostenzeile pro Bündel hinzu, damit die Margenrechnung ehrlich bleibt.
• Mische Varianten (Größe, Farbe, Region) in einem Kit ohne klare Zuordnung. Fordere eine eindeutige Regel: welche Komponenten‑SKU für welche Bündeloption verwendet wird.
• Aktualisiere Komponentenpreise oder -kosten und prüfe das Bündel nie neu. Plane eine Marge‑Überprüfung bei jeder Komponentenänderung.
• Dein POS oder ERP verteilt Umsatz anders auf Komponenten als deine Berichte. Definiere eine Verteilungs­methode (Anteil nach Listenpreis ist üblich) und bleibe dabei.
• Promotionen stapeln sich ungewollt (Bündelrabatt plus Gutschein plus automatischer Staffelrabatt). Lege Stacking‑Regeln im Vorfeld fest.

Implementierst du Logik im Code, schreibe die Regeln auf, bevor du sie umsetzt. In Koder.ai hilft der Planungsmodus, Bündelregeln (Bestandsabzug, Rundung, Rabatt‑Stacking) zu dokumentieren, damit das Verhalten beim Export von Quellcode oder beim Hinzufügen neuer Bündel konsistent bleibt.

Schnelle Checkliste vor dem Launch eines Bündels

Nimm dir vor der Veröffentlichung 10 Minuten, um Regeln auf Konsistenz zu prüfen. Die meisten Probleme zeigen sich später als „warum haben wir Verlust gemacht?“ oder „warum stimmt der Bestand nicht?“ — beides führt meist auf unklare Mathematik zurück.

Beginne mit dem kundenseitigen Preis. Zeigst du „Spare 15%“, stelle sicher, dass diese Zahl auf denselben Referenzpreisen basiert, die überall sonst verwendet werden (deine aktuellen Verkaufspreise, nicht ein alter UVP). Hier wird die Preisrechnung im echten Leben getestet: Die angezeigte Ersparnis sollte mit dem übereinstimmen, was ein Käufer nachprüfen kann.

Prüfe dann die Marge mit den exakten Kosten, die bei jeder Bestellung anfallen. Berücksichtige Pick‑/Pack‑Arbeit, Verpackung, Zahlungsgebühren und zusätzliche Versandkosten durch Gewicht oder mehrere Artikel. Wenn das Bündel deine Zielmarge nur erreicht, wenn alles perfekt läuft, ist es riskant.

Inventar ist die andere Hälfte. Entscheide, ob das Bündel eine eigene SKU ist, wie es Komponenten abzieht und was bei Störfällen wie Stornierungen und Rückgaben passiert. Kannst du die Bestandslogik nicht in einem Satz erklären, wird sie unter Druck versagen.

Eine straffe Vor‑Launch‑Checkliste:

• Rabattnachweis: Die „Du sparst“-Anzeige und der Checkout‑Betrag verwenden dieselben Referenzpreise und Rundungsregeln.
• Margen‑Beleg: Der Bündelgewinn bleibt über deinem Minimum nach Produktkosten, Gebühren, Verpackung und Erfüllungsarbeit.
• Bestandsnachweis: Ein verkaufter Bündel zieht immer dieselben Komponentenmengen ab; Rückgaben/Stornos kehren das korrekt um.
• Niedrigbestand‑Regel: Definiere ein Verhalten (Verkauf blockieren, Backorder erlauben oder definierten Ersatz anbieten) und wende es konsistent an.
• Reporting‑Beleg: Du kannst ohne manuelle Tabellen sagen, wie viele Bündel verkauft wurden, wie viele Komponenten verbraucht wurden und Gewinn pro Bündel.

Automatisierst du mit einem Tool wie Koder.ai, schreibe die Regeln zuerst auf und implementiere sie dann genau, damit die Zahlen beim Skalieren stabil bleiben.

Beispiel: Ein Starter‑Kit mit echten Zahlen

Stell dir ein „Starter Kit“ aus drei Artikeln vor, die du auch einzeln verkaufst. Ziel: Rabatt deutlich machen, Gewinn leicht prüfbar und Bestand immer korrekt.

Das Kit, Preise und Rabatt

Angenommen diese Komponenten mit einfachen Preisen und Stückkosten (COGS):

• Trinkflasche: Listenpreis $20, COGS $8
• Fitnesshandtuch: Listenpreis $12, COGS $4
• Protein‑Shaker: Listenpreis $18, COGS $6

Würden sie einzeln verkauft, zahlt der Kunde $20 + $12 + $18 = $50 (das ist deine „Summe der Teile“).

Setze den Bündelpreis auf $42. Der Rabatt ist $50 - $42 = $8. Rabatt in % = $8 / $50 = 16%.

Das ist die sauberste Präsentation der Preisrechnung für Produktbündel: Zeige die Summe der Teile, dann den Kit‑Preis und die Ersparnis.

COGS und Marge auf dem Bündel

Bundle COGS ist die Summe der Komponenten‑COGS: $8 + $4 + $6 = $18.

Bruttogewinn auf das Kit ist $42 - $18 = $24.

Bruttomarge in % = $24 / $42 = 57.1%.

Diese Kennzahl erlaubt dir, das Bündel mit deinen üblichen Margen zu vergleichen. Liegt dein Ziel bei 60%, ist dieses Kit etwas enger und du musst entscheiden, ob die höhere Conversion das wert ist.

Bestandsauswirkung (5 verkaufte Kits, dann eine Teilrückgabe)

Ausgangsbestand: Flaschen 40, Handtücher 30, Shaker 25.

Verkauf von 5 Kits: Bestände ziehen 5 Einheiten jeder Komponente ab:

Flaschen 40 - 5 = 35, Handtücher 30 - 5 = 25, Shaker 25 - 5 = 20.

Jetzt gibt ein Kunde nur das Handtuch aus einem Kit zurück. Lege 1 Handtuch wieder ins Lager (Handtücher 25 + 1 = 26).

Finanziell: Wähle eine klare Regel — entweder (a) keine Teilrückgaben bei Kits, oder (b) Teilrückgaben werden anteilig aus dem gezahlten Bündelpreis erstattet, nicht zum Einzelpreis. Erstattest du den Einzelpreis des Handtuchs ($12), kannst du aus einem profitablen Kit schnell einen Verlust machen.

Nächste Schritte: Regeln dokumentieren und automatisieren, wo möglich

Bündel bleiben nur profitabel und genau, wenn alle dieselben Regeln befolgen. Bevor du ein Kit kanalübergreifend skalierst, halte eine kurze „Bündel‑Policy“ schriftlich fest, auf die dein Team bei Unklarheiten verweisen kann.

Enthalten sollte die Policy in einfachem Wortlaut drei Dinge: wie du Bündelpreise setzt (und wie Rabatte angezeigt werden), wie Inventar abgezogen wird (Bündel‑SKU, Komponenten oder beides) und wie Rückgaben gehandhabt werden (Rückerstattung auf Bündel‑ oder Komponentenbasis).

Eine gute Policy passt auf eine Seite. Verwende eine kurze Checkliste:

• Preisregel: Welcher Rabatt ist erlaubt und wie wird er angezeigt (Prozent, Festpreis oder „Kaufe X, erhalte Y“).
• Margenregel: Welche Kostenbasis nutzt du und welches Mindest‑Margin akzeptierst du.
• Inventarregel: Was wird bei Bestellaufgabe abgezogen und was passiert bei fehlender Komponente.
• Rückgaberregel: Nur vollständiges Kit vs. Teilrückgaben und Umgang mit geöffneten/fehlenden Teilen.
• Änderungsregel: Wer darf Bundlezusammensetzung, Preise und Ersatzartikel ändern.

Teste die Randfälle mit echten Bestellungen, nicht nur Tabellen. Erstelle einen Testauftrag für jedes erwartete Szenario: Teilrückgabe, Ersatz, Backorder, Bündel mit gemischten Steuerkategorien und Preisänderung mitten im Monat. Speichere Screenshots oder Notizen, um Tests nach Systemupdates zu wiederholen.

Setze eine monatliche Überprüfung, um Margenabweichungen zu erkennen. Komponentenpreise ändern sich leise, und dein „tolles Angebot“ kann ohne Notice zur Verlustquelle werden. Eine 15‑minütige Erinnerung, Top‑Bündel, Komponentenpreise und tatsächliche Margen zu prüfen, reicht meist.

Wenn deine Tools die Regeln nicht sauber abbilden können, baue eine kleine interne App, die genau das macht (Bündel‑Setup, Validierung und Reporting). Mit Koder.ai kannst du deine Bündelregeln im Chat beschreiben und ein Backoffice‑Tool (React + Go + PostgreSQL) generieren, dann sicher mit Snapshots und Rollback iterieren, wenn du die Logik anpassen musst.