Baue einen Provisionsrechner mit Manager-Freigabe: Regeln nach Produkt und Rolle definieren, Auszahlungen pro Zeitraum berechnen, Ergebnisse genehmigen und für die Payroll exportieren.
Ein Vertriebsprovisionsrechner klingt einfach, bis die erste Ausnahme auftaucht. Jemand verkauft zwei Produkte mit unterschiedlichen Sätzen, ein Manager genehmigt einen einmaligen Bonus, und die Finanzabteilung braucht vor der Lohnabrechnung gesperrte Zahlen. In einer Tabelle führt das schnell zu zusätzlichen Tabs, versteckten Formeln und der bekannten Frage: „Welche Version ist korrekt?“
Tabellenkalkulationen scheitern, weil Provisionsregeln nicht nur Mathematik sind. Sie sind Policy. Sobald du Regeln nach Produkt und Rolle definierst, verzweigt sich die Logik schnell: Produkt A zahlt einen Satz an einen SDR und einen anderen an einen AE, Services werden vielleicht bei vereinnahmten Zahlungen gezahlt, und Verlängerungen können bestimmte Regionen ausschließen. Eine kleine Änderung kann Dutzende Zellen beeinflussen, und es ist schwer nachzuweisen, was sich wann geändert hat.
Der schlechteste Zeitpunkt, das zu entdecken, ist direkt vor der Lohnabrechnung. Zahlen ändern sich kurzfristig (ein Geschäft verschiebt sich in einen anderen Zeitraum, eine Rückerstattung taucht auf, eine Ausnahme wird genehmigt) und plötzlich editierst du Formeln in letzter Minute ohne klaren Verlauf. So entstehen Streitigkeiten, und warum „finale“ Exporte immer wieder neu verschickt werden.
Die fehlende Komponente ist eine Freigabe. Das bedeutet, die Auszahlung für einen Zeitraum wird geprüft und genehmigt, bevor sie das Provisions-Tool verlässt. Normalerweise bestätigt der Vertrieb Leistung und Ausnahmen, und Finanzen bestätigen die Regeln und Totale, die tatsächlich zahlbar sind.
Ein solider Workflow liefert vier Dinge: genaue Auszahlungen mit klaren Cut-offs, eine einzige Quelle der Wahrheit für Deals und Regeln, einen einfachen Freigabeschritt der Zahlen einfriert, und eine Auditspur, die zeigt, wer was und wann genehmigt hat.
Ein Provisionsrechner bleibt nur dann vertrauenswürdig, wenn alle zwei Dinge akzeptieren: was hineingeht und was herauskommt. Die meisten Streitigkeiten entstehen, wenn Eingaben unklar sind oder wenn jemand eine Regel ändert, ohne eine Spur zu hinterlassen.
Eingaben kommen typischerweise von Sales Ops oder Finanzen sowie aus einer Deal-Quelle (CRM oder Tabellenexport). Der Schlüssel ist Konsistenz: dieselben Felder, in jedem Zeitraum, damit Berechnungen nicht von persönlicher Interpretation abhängen.
Wesentliche Eingaben sind Deals (Betrag, Abschluss-/Verdienst-Datum, Stage, Owner), Produkte/Pläne (was verkauft wurde und spezielle Flags), Personen und Rollen (inklusive Wechsel während des Zeitraums), Quoten/Accelerators und Zeitregeln (Auszahlungszeitraum, Stichtage, Rückforderungsfristen).
Ausgaben sollten einfach zu prüfen, einfach zu genehmigen und einfach an die Payroll zu übergeben sein. Denke in zwei Ebenen: Positionszeilen (was jede Person erhält und warum) und Zusammenfassungen (Totals für Manager und Finanzen).
Ein sauberes Ausgabepaket beinhaltet:
Das Genehmigungs-Tor schützt die Zahlen. Vor der Freigabe sollten Mappings und Eingaben editierbar sein (Produkt-Tags, Rollenwechsel, Deal-Splits) und bei Ausnahmen Kommentare erforderlich sein. Nach der Freigabe sperre Auszahlungen und verlange einen formellen Anpassungsdatensatz statt stiller Bearbeitungen.
Nachvollziehbarkeit ist nicht verhandelbar. Jede Änderung sollte dokumentieren, wer sie vorgenommen hat, wann und welche alten und neuen Werte betroffen waren.
Ein Provisionsrechner funktioniert nur, wenn alle die Regeln lesen und zum selben Ergebnis kommen. Beginne damit, Regeln in einfacher Sprache zu formulieren und sie dann in strukturierte Felder zu überführen. Wenn eine Regel ein Meeting braucht, um erklärt zu werden, verursacht sie später Streit.
Definiere zuerst die Rollen basierend auf dem, was Menschen tatsächlich im Deal tun. Ein Vertriebsmitarbeiter kann sourcen und closen, ein Account Manager erneuern oder ausbauen, ein Sales Engineer kann Demos unterstützen und eine Manager-Rolle kann Overrides haben oder einen kleinen Split für Coaching und Review halten. Halte die Liste kurz und konsistent.
Gruppiere dann Produkte so, wie du sie verkaufst. Wenn du für ein margenstarkes Add-on anders bezahlst als für einen Kernplan, trenne sie. Wenn Preise regional variieren und das die Provision beeinflusst, spiegle das in den Gruppen. Ziel ist, weniger Einzelfallregeln zu haben, ohne Genauigkeit zu verlieren.
Wähle anschließend die passenden Satztypen für deinen Vergütungsplan: Prozent vom Umsatz, Festbeträge für fixe Services, gestaffelte Sätze für größere Deals und Split-Regeln für geteilte Credits.
Das sind die Entscheidungen, die meist wichtig sind:
Beispiel: zahle 8 % an den Vertriebsmitarbeiter auf Core Subscription, 3 % an den Account Manager bei Verlängerungen und eine $200 Fixprämie an den Sales Engineer für Implementation Services. Wenn ein Kunde in zwei Raten zahlt, wähle eine Policy (Auszahlung bei Vereinnahmung oder erst bei vollständiger Zahlung) und wende sie konsistent an.
Der schnellste Weg, Streit zu erzeugen, ist, Provisionen auf einem Zeitstrahl zu berechnen und sie auf einem anderen auszuzahlen. Bevor du den Rechner baust, fixiere zwei Dinge: den Auszahlungszeitraum (wofür du zahlst) und die Stichtagsregel (was in diesen Zeitraum fällt).
Wähle ein Periodenmodell, das zum Geschäft passt. Monatlich ist am einfachsten zu verstehen und zu prüfen. Quartalsweise reduziert den Verwaltungsaufwand, verzögert aber Feedback und kann Probleme verbergen, bis sie teuer sind. Benutzerdefinierte Bereiche eignen sich für Piloten, Spiffs oder saisonale Teams.
Definiere als Nächstes das Verdienst-Datum: das eine Ereignis, das entscheidet, wann ein Geschäft provisionsberechtigt ist. Gängige Optionen sind Abschlussdatum (closed-won), Versanddatum oder Rechnungszahlungsdatum. Wähle eine Hauptregel und behandle Ausnahmen als explizite, dokumentierte Ausnahmen.
Schreibe Stichtagsregeln so, dass sie schwer misszuverstehen sind. Zum Beispiel:
Plane Prorata-Regeln frühzeitig. Wenn jemand mitten im Monat beginnt, die Rolle wechselt oder das Gebiet wechselt, entscheide, ob du nach Tagen in der Rolle teilst, nach wirksamem Datum in der Opportunity oder nach Besitz zum Verdienstzeitpunkt. Was immer du wählst, mache es konsistent und sichtbar in den Auszahlungsdetails.
Entscheide schließlich, wie Korrekturen erscheinen. Kleine Korrekturen funktionieren meist am besten als Anpassungszeile im nächsten Zeitraum. Große Fehler können eine Neuausweisung erfordern, das sollte aber selten und klar gekennzeichnet sein.
Ein Provisionsrechner bleibt einfach zu betreiben, wenn das Datenmodell langweilig und vorhersehbar ist. Trenne, was passiert ist (Sales-Aktivität) von der Art, wie du zahlst (Regeln), und speichere das Ergebnis (Auszahlungen), damit du es später auditieren kannst.
Beginne mit den Kern-„was ist passiert“-Tabellen:
Füge dann die Ebene „wie gezahlt wird“ mit Rules hinzu. Jede Regel sollte klar beantworten:
Um Regeln übersichtlich zu halten, mache Prioritäten explizit. Speichere eine numerische priority und wende immer das Matching mit der höchsten Priorität zuerst an. Zum Beispiel schlägt eine produktspezifische Regel eine „alle Produkte“-Regel, und eine benutzerspezifische Ausnahme schlägt eine allgemeine Rollenregel.
Regeln ändern sich über die Zeit – versioniere sie. Nutze Wirksamkeits-Start/End-Daten und erfasse, wer die Regel aktualisiert hat und wann. Wenn jemand fragt „Warum war der März anders?“, kannst du auf die aktive Regel verweisen.
Füge abschließend eine Exceptions-Tabelle für manuelle Overrides hinzu. Speichere die Deal-Zeile, den Override-Betrag oder Satz, wer ihn eingegeben hat, und einen verpflichtenden Grund. Das macht einmalige Korrekturen sichtbar statt sie in einer Tabellenzelle zu verstecken.
Ein guter Provisionsrechner ist vorhersehbar: dieselben Eingaben liefern dieselben Auszahlungen. Am einfachsten erreichst du das, indem du jeden Auszahlungsdurchlauf wie einen Snapshot behandelst, den du später erneut abspielen kannst.
Beginne damit, das Auszahlungsfenster zu wählen (z. B. 1.–31. März) und die Deal-Menge zu sperren. Praktisch bedeutet das: Jeder Deal, jede Rechnung oder Deal-Zeile, die qualifiziert, wird in den Lauf aufgenommen – selbst wenn das CRM morgen Änderungen erfährt.
Ein praktikabler Ablauf, der auch bei wachsenden Regeln lesbar bleibt:
Beispiel: Ein Deal hat zwei Positionen, Software und Onboarding. Der AE ist für beides berechtigt. Onboarding zahlt eine feste Prämie, während Software prozentual vergütet wird. Jede Position wird separat berechnet und anschließend für den AE aufsummiert.
Die Ausgabe sollte ein Draft-Auszahlungsreport sein, bereit zur Prüfung und Freigabe, wobei jede Zahl auf eine spezifische Deal-Zeile und Regel zurückführbar ist.
Ein Provisionsrechner ist nur die halbe Arbeit. Die andere Hälfte ist ein sauberer Freigabeschritt, damit Auszahlungen vertrauenswürdig, reproduzierbar und später einfach erklärbar sind.
Behandle jeden Provisionslauf wie ein Dokument, das durch klare Status läuft, und mache den Status überall sichtbar. Verhindere außerdem den Export vor der Freigabe. Eine einfache Statusmenge funktioniert gut: Draft (in Arbeit), Submitted (bereit zur Prüfung), Approved (freigegeben), Rejected (muss korrigiert werden) und Exported (an Payroll gesendet).
Bestimme die Verantwortlichkeiten im Voraus. Oft erstellt Sales Ops und submitet, ein Sales-Manager genehmigt Deals und Splits, und Finanzen genehmigen die finalen Zahlen vor dem Export. Wenn du nur einen Entscheider willst, wähle die Person, die „ja“ sagen und auch Streitfälle bearbeiten kann.
Ein Prüfbildschirm sollte Fragen schnell beantworten. Zeige Totale oben und ermögliche Drill-Down:
Wenn ein Lauf abgelehnt wird, verlange einen Kommentar mit Begründung. Beim Ablehnen entsperre nur das, was bearbeitet werden muss (z. B. Deal-Mapping oder Regelwahl) und halte alles andere schreibgeschützt, damit der Umfang kontrolliert bleibt.
Freigaben sollten eine verlässliche Spur hinterlassen: wer genehmigt hat, wann und was genau (Periode, Totale und die enthaltene Deal-Menge). Wenn sich ein Deal nach der Freigabe ändert, sollte der Lauf entweder wieder auf Draft zurückgehen oder deutlich als „erneute Freigabe erforderlich" markiert werden.
Ein kleines Team möchte einen Provisionsrechner, der vorhersehbar wirkt. Sie haben zwei Reps (Alex und Priya) und eine Managerin (Dana). Sie verkaufen zwei Produkte mit unterschiedlichen Sätzen: Produkt Alpha zahlt 10 % und Produkt Beta 6 %.
Ein Deal enthält einen Split: der Rep hält die Kundenbeziehung und ein Sales Engineer hilft beim Abschluss. Ihre Regel ist einfach: 70 % der Provision gehen an den Rep und 30 % an den Sales Engineer.
So läuft der April ab:
Draft-Berechnung für April (vor Anwendung der Rückerstattung): Deal 1 Provision ist $20.000 x 10 % = $2.000. Alex erhält $1.400 und Priya $600. Deal 2 Provision ist $15.000 x 6 % = $900, vollständig an Priya.
Die Rückerstattung erzeugt nun eine Anpassung. Die Rückerstattung betrifft $5.000 von Produkt Alpha, also ist die Anpassung $5.000 x 10 % = $500. Wenn deine Policy Anpassungen im nächsten Auszahlungszeitraum anwendet, bleibt April geschlossen und Mai beginnt mit -$500, aufgeteilt 70/30 (-$350 für Alex, -$150 für Priya). Das vermeidet Neuabwicklung der Payroll.
Monatsend-Flow:
Die meisten Provisionsstreitigkeiten drehen sich nicht um Mathematik. Sie entstehen, wenn zwei Personen unterschiedliche Definitionen desselben Geschäfts verwenden.
Ein häufiger Auslöser ist das Mischen von gebuchtem Umsatz (signed) mit bezahltem Umsatz (collected), ohne es überall zu kennzeichnen. Wenn ein Bildschirm gebuchte Umsätze zeigt und der Export bezahlte Umsätze, fühlen sich Reps überrumpelt. Wähle eines als Standard und mache das andere zu einem expliziten Feld mit klarem Namen.
Ein weiteres Problem sind stille Edits nach der Freigabe. Wenn ein Manager einen Zeitraum freigibt und später jemand ein Abschlussdatum, Produkt oder den Betrag ändert, können sich Auszahlungen ohne ersichtlichen Grund ändern. Sperre genehmigte Datensätze und behandle Änderungen als Anpassungen mit datiertem Verlauf.
Regeln führen auch zu Streit, wenn sie sich überschneiden. Wenn „Produkt A zahlt 8 %“ und „Enterprise-Deals zahlen 10 %“ beide zutreffen, brauchst du eine klare Prioritätsregel (oder eine Stacking-Regel), damit dasselbe Geschäft nicht je nach Bericht anders zahlt.
Probleme, die oft beim Auszahlungstermin auftauchen:
Beispiel: Ein Rep verkauft in EUR, Payroll zahlt in USD, und es kommt nächsten Monat zu einer Stornierung. Wenn du den ursprünglichen FX-Kurs mit dem Deal speicherst und die Stornierung als negative Anpassung im nächsten Zeitraum erfasst, sieht das Team genau, warum sich die Zahl geändert hat.
Der letzte Schritt ist der Bereich, in dem die meisten Provisionskopfschmerzen beginnen. Bevor du etwas an Payroll sendest, mache einen kurzen Sanity-Check, damit du die richtigen Leute für die richtigen Deals im richtigen Zeitraum bezahlst.
Prüfe zuerst das Auszahlungsfenster. Stelle sicher, dass Start- und Enddatum des Zeitraums dem entsprechen, was das Unternehmen erwartet, und dass deine Stichtagsregel klar ist. „Closed-won bis 23:59 Uhr am letzten Tag des Monats" ist nicht dasselbe wie „Rechnung innerhalb des Monats bezahlt".
Nutze diese kurze Checkliste vor dem Export:
Wenn du einen Ausreißer findest, behandle ihn wie eine kurze Untersuchung. Öffne den Deal-Datensatz, bestätige die angewendete Regel und verifiziere Eingaben (Betrag, Produkt, Rolle, Stage, Datum). Ein einfacher "Hold for review"-Status hilft, fragliche Items bis zur Korrektur und Freigabe aus dem Export zu halten.
Beginne klein, damit du etwas veröffentlichst, das Menschen tatsächlich nutzen. Eine gute minimale Version ist eine Produktgruppe, zwei Rollen (Rep und Manager) und ein Periodentyp (monatlich). Das reicht, um die Mathematik, Stichtagsregeln und den Freigabeschritt zu beweisen, ohne in Edge-Cases zu versinken.
Bestimme als Nächstes, wo die Rohdaten herkommen und wie du ihnen vertraust. Viele Teams importieren aus CRM oder Billing-Systemen und füllen Lücken mit einer Tabelle. Was auch immer du wählst, baue Validierung in den Prozess ein. Blockiere beispielsweise das Einreichen eines Zeitraums, wenn ein Deal keinen Owner, kein Produkt-Tag oder kein Abschlussdatum hat.
Ein leichtgewichtiges Manager-Dashboard erleichtert die Einführung. Konzentriere es auf Entscheidungen:
Wenn du schwere Entwicklung vermeiden willst, kann AppMaster (appmaster.io) ein praktikabler Weg sein, dies als internes Tool zu bauen: Modelliere die Tabellen, implementiere den Auszahlungs- und Freigabe-Flow und generiere nach der Freigabe einen Export. Halte es anfangs einfach und erweitere behutsam, wenn das Team weitere Produktgruppen, Sonderfälle oder Periodentypen verlangt.
Was ist das beste "earned date" für Provisionen?Beginne mit einer einzigen, klaren Regel, die entscheidet, wann ein Geschäft provisionsberechtigt ist (z. B. Abschlussdatum oder Rechnung bezahlt). Halte diese Regel konsistent in allen Berichten und Exporten. Behandle Ausnahmen als explizite Anpassungen mit Notiz, sodass die Historie nicht umgeschrieben wird.
Wie verhindern wir, dass Zahlen kurz vor der Gehaltsabrechnung noch ändern?Sperre den Zeitraum vor dem Export. Eine einfache Methode ist ein kurzer Korrekturzeitraum (z. B. 1–2 Werktage), um fehlende Felder zu ergänzen, und danach die Eingaben einfrieren. Alle späteren Änderungen müssen als datierte Anpassungszeilen im nächsten Zeitraum erfasst werden.
Wie sollten wir Provisionsregeln nach Produkt und Rolle definieren?Halte Regeln lesbar und strukturiert: Rolle + Produkt (oder Produktgruppe) + Berechnungsmethode (Prozent, Fixbetrag, gestaffelt). Wenn sich eine Regel nicht in einem Satz erklären lässt, sollte sie in kleinere Regeln geteilt werden.
Was passiert, wenn zwei Provisionsregeln auf dasselbe Geschäft zutreffen?Lege eine klare Prioritätsreihenfolge fest, sodass pro Deal-Zeile nur eine Regel gewinnt. Übliche Defaults: benutzerspezifische Overrides schlagen Rollenregeln, produktspezifische Regeln schlagen "alle Produkte", neuere Wirksamkeitsdaten schlagen ältere.
Sollen Provisionen auf Deals oder auf Deal-Zeilen berechnet werden?Berechne auf Zeilenebene und fasse dann für die Person zusammen. Das verhindert Verwirrung, wenn ein Geschäft Positionen mit unterschiedlichen Sätzen enthält (z. B. Prozent für Software plus ein fixer Service-Bonus) und vereinfacht Audits.
Gebuchte Umsätze vs. bezahlte Umsätze: Welche sollten wir für Provisionen verwenden?Entscheide eine Policy und kennzeichne sie überall. Auf gebuchte Umsätze zu zahlen ist einfacher und schneller; auf eingegangene Zahlungen zu zahlen reduziert Risiken bei Rückerstattungen oder Nichtzahlung. Welche Policy auch immer gewählt wird: Rückbuchungen sollten klar als Anpassungszeilen behandelt werden.
Wie sollten wir mit Rückerstattungen, Stornierungen und Chargebacks umgehen?Behandle Rückerstattungen als negative Anpassungen statt historische genehmigte Auszahlungen zu editieren. Die saubere Standardvorgehensweise ist, den genehmigten Monat geschlossen zu lassen und die Rückbuchung im nächsten Auszahlungszeitraum mit Referenz auf die ursprüngliche Deal-Zeile zu erfassen.
Wie sieht ein guter Manager-Freigabe-Workflow aus?Nutze eine kleine Menge an Status und setze sie durch: Draft für Berechnung, Submitted zur Prüfung, Approved zum Sperren der Zahlen und Exported wenn die Datei an Payroll geht. Export aus Draft oder Submitted sollte nicht erlaubt sein; dokumentiere wer wann genehmigt hat.
Was sollten Manager und Finanzen während der Provisionsprüfung sehen?Zeige zuerst Summen, dann Drilldowns zur Deal-Zeile, zur angewendeten Regel und zu etwaigen Splits oder Caps. Reviewer brauchen außerdem eine Ansicht mit Ausnahmen (fehlende Produktzuordnung, fehlender Owner, negative Auszahlungen) und ein klares Änderungsprotokoll seit dem letzten Lauf.
Können wir das als einfaches internes Tool ohne viel Programmierung bauen?Ja, wenn du den Umfang klein hältst: ein Periodentyp (monatlich), wenige Produktgruppen und eine kurze Rollenliste. Mit AppMaster kannst du Tabellen modellieren, den Auszahlungs- und Freigabeprozess implementieren und nach der Freigabe einen Payroll-Export erzeugen, ohne großen Entwicklungsaufwand.
21. Jan. 2026
8 Min
20. Jan. 20268 Min
20. Jan. 20268 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
