Provisionsberechnungen im MLM: so modellieren, dass sie ein Audit überstehen

Multi-Level-Marketing-Provisionen sind eine eigene Disziplin. Verkäufer A wirbt B an, B macht 50 000 CZK/Monat Umsatz. A bekommt Provision auf B's Volumen — wie viel, hängt davon ab, in welcher Stufe A ist, welche Qualifikation A in diesem Monat hatte, ob A den Bonus-Schwellwert erreichte und ob A's Override-Bonus auf Verkäufer C und D (beide unter B) freigeschaltet wurde.

Für JUST haben wir ein System ersetzt, das diese Berechnungen 15 Jahre lang durchführte. Regel Nr. 1 bei der Replikation: das neue System muss dieselbe Zahl liefern, wenn man beide Systeme parallel auf denselben Daten laufen lässt. Regel Nr. 2: in 3 Jahren müssen Sie erklären können, warum ein Verkäufer 3 240 CZK statt 3 470 CZK bekommen hat.

So haben wir es strukturiert.

1. Provisionsregeln als Daten, nicht als Code

Der Entwickler-Instinkt: „Ich schreibe calculateCommission(seller, month) mit If/Else auf Stufen.“ Funktioniert 6 Monate. Dann kommt Business mit einem neuen Bonus, und Sie ändern die Funktion. Dann eine weitere Änderung. Nach 3 Jahren haben Sie 6 Versionen der Funktion und können keine nach dem Monat trennen, in dem sie galten.

Richtig: Regeln als Zeilen in einer DB-Tabelle mit validFrom / validTo. Schema:

CommissionRule {
  id: UUID
  name: 'Tier 2 Base Commission'
  validFrom: Date
  validTo: Date | null
  condition: JSON   // wann gilt
  calculation: JSON // was berechnet wird
  priority: Integer
}

Für Monat 2023-05 werden Regeln geladen, bei denen validFrom <= '2023-05-01' AND (validTo IS NULL OR validTo > '2023-05-31'). Eine Business-Logik-Änderung = eine neue Zeile, kein Code-Edit. Historische Perioden werden mit den damals gültigen Regeln neu berechnet.

2. Berechnungsergebnisse sind immutable

Sobald eine Provision berechnet und an den Verkäufer ausgezahlt wurde, wird sie nicht mehr überschrieben. Auch wenn ein Bug in den Regeln gefunden wird. Statt Überschreiben wird eine Korrektur gebucht.

Schema:

CommissionOutcome {
  id: UUID
  sellerId
  month: '2023-05'
  amount: 3240
  ruleSnapshot: JSON  // alle verwendeten Regeln, als Kopie
  inputSnapshot: JSON // Umsätze, Netzwerkstruktur bei Berechnung
  calculatedAt: DateTime
  status: 'final' | 'corrected' | 'superseded'
}

CommissionCorrection {
  id: UUID
  originalOutcomeId
  correctionAmount: 230  // +/-
  reason: string
  approvedBy: UserId
  approvedAt: DateTime
}

Auszahlung an Verkäufer = Original + alle Korrekturen. Das Finanzsystem hat einen immutablen Audit-Trail. Wenn 2026 ein Prüfer fragt, „warum war diese 2023-05-Provision 3 240 CZK?“, können Sie es replizieren — der Snapshot von Regeln und Inputs ist für immer da.

3. Test-Szenarien als Business-Engineering-Vertrag

Business sagt: „Verkäuferin Jana hat Volumen 80 000, unter ihr B mit 60 000, unter B ist C mit 40 000, Jana bekommt 3 % Override auf B und 1,5 % auf C. Berechnen.“ Wir rechnen, bekommen eine Zahl, Business bestätigt „korrekt“. Das muss als Test-Case gespeichert werden.

Für JUST haben wir ein Szenario-File gesammelt — ~50 reale und hypothetische Fälle. Jede Regel im System hat mindestens 2-3 Szenarien, die sie testen. Wenn jemand die Logik ändert, führt CI alle Szenarien aus und zeigt, welche Ergebnisse sich geändert haben. Unerwartet geändert → Bug.

Das Legacy-System hatte nichts davon. Nach 15 Jahren wusste niemand genau, wie etwas berechnet wurde — es musste rückkonstruiert werden. Einer der ersten Deliverables unserer Implementierung war, Szenario-Erwartungen vom Business-Analysten zu bekommen und damit die tatsächlichen Regeln festzunageln.

4. Dual-Run vor dem Cutover

Vor dem Legacy-→-New-Cutover haben wir 3 Monate beide Systeme parallel auf denselben Daten laufen lassen. Ergebnisse wurden monatlich verglichen. Differenz > 0,01 % war ein Alert.

Wir stießen auf 7 Regeln, bei denen das neue System anders rechnete. 5× war Legacy richtig und wir hatten einen Bug. 2× war Legacy falsch und Business hatte es nie bemerkt (~15 000 CZK über 3 Monate unterzahlt). Gemeldet, Verkäufer bekamen Korrekturen, Business würdigte es.

Dual-Run ist kein Luxus. Für kritische Finanzsysteme ist es das Minimum, um ohne Überraschungen zu launchen.

5. Neuberechnung ab Tag eins möglich

Die Fähigkeit, einen beliebigen historischen Monat neu zu berechnen, ist tragend. Gründe:

• Audit findet Bug in Regeln von 2022 — Sie müssen die gesamte Historie neu berechnen
• Rechtsstreit mit einem Verkäufer — Sie müssen das Berechnungsdetail vorlegen
• Business will einen neuen Bonus rückwirkend anwenden — Neuberechnung mit einer retroaktiven Regel

Mit immutablen Regeln in der DB + Input-Snapshots pro Berechnung ist Neuberechnung deterministisch. Haben Sie die Logik im Code und ändern sie routinemäßig, ist Neuberechnung nach 3 Jahren unmöglich.

Verallgemeinerung

MLM ist nicht der einzige Use Case. Dasselbe Muster gilt für:

• Loyalty-Programme mit wechselnden Regeln
• Payroll- / Vergütungssysteme
• Pricing-Engines, bei denen Kunden historisch verhandelte Konditionen haben
• Fintech-Fee-Berechnungen mit regulatorischen Änderungen

Gemeinsamer Nenner: Regel heute ≠ Regel in einem Jahr, und Sie müssen beide verteidigen können. Nicht im Code. In den Daten, mit immutabler Historie und Tests als Vertrag zwischen Business und Engineering.