Staffelpreise in SaaS abrechnen ohne Excel
Ein Kunde überschreitet am 28. des Monats die Grenze von 100 Seats. Der Preis sinkt rückwirkend für alle Seats, die Rechnung soll aber erst am Monatsende entstehen, und parallel gilt Reverse Charge. Wer Staffelpreise in SaaS abrechnen will, braucht dafür mehr als eine Preisstaffel im Frontend. Entscheidend ist eine Billing-Logik, die Preisregel, Mengenstand, Steuer, Zahlungsstatus und Erlösdaten nachvollziehbar zusammenführt.
Staffelpreise wirken im Produktkatalog einfach. Operativ treffen sie jedoch auf Upgrades, Downgrades, zeitanteilige Abrechnung, Korrekturen, mehrere Währungen und länderspezifische Rechnungsanforderungen. Wenn diese Fälle erst beim Rechnungslauf oder im Monatsabschluss interpretiert werden, entsteht genau die manuelle Arbeit, die ein SaaS-Billing-System vermeiden soll.
Staffelpreise in SaaS abrechnen beginnt mit der Preissemantik
Der Begriff Staffelpreis beschreibt mindestens zwei unterschiedliche Modelle. Sie dürfen nicht mit derselben Berechnung behandelt werden.
Bei einer volumenbasierten Staffel bestimmt die erreichte Menge den Preis für alle Einheiten. Kostet ein Produkt bis 100 Seats 10 Euro pro Seat und ab 101 Seats 8 Euro, zahlt ein Kunde mit 120 Seats 960 Euro. Der Grenzübertritt verändert also auch den Preis der ersten 100 Seats.
Bei einer gestaffelten oder graduellen Preislogik wird jede Mengenstufe separat bewertet. Für die ersten 100 Seats fallen 10 Euro an, für die folgenden 20 Seats 8 Euro. Die Rechnung beträgt dann 1.160 Euro. Das ist kein Detail der Darstellung, sondern eine andere wirtschaftliche Vereinbarung.
Bei nutzungsbasierten Produkten kommt eine dritte Dimension hinzu: die Messperiode. Eine API-Anfrage kann bei Eingang gezählt werden, aber erst am Ende des Kalendermonats, eines individuellen Vertragsmonats oder nach Ablauf eines Freikontingents abrechenbar sein. Der Produktkatalog muss daher explizit definieren, ob Mengen kumuliert, zurückgesetzt, über mehrere Zähler aggregiert oder pro Workspace getrennt bewertet werden.
Die Regel sollte maschinenlesbar sein: Metrik, Aggregationsfenster, Staffelgrenzen, Berechnungsmethode, Währung, Abrechnungsintervall, steuerliche Produktklassifikation und Wirksamkeitsdatum. Freitext in CRM-Notizen ist keine Preislogik.
Ein Beispiel mit Seats und Usage
Ein Anbieter berechnet 49 Euro Plattformgrundgebühr, 12 Euro pro aktivem Seat bis einschließlich 50 Seats und 9 Euro ab dem 51. Seat. Zusätzlich sind 100.000 API-Calls enthalten. Darüber hinaus gelten graduelle Staffeln: 0,004 Euro für die nächsten 400.000 Calls und 0,0025 Euro für jede weitere Anfrage.
Für 70 aktive Seats und 650.000 API-Calls ergibt sich die Monatsposition aus drei getrennten Berechnungen: Grundgebühr, Seat-Komponente und Usage-Komponente. Die 550.000 Mehranfragen werden nicht pauschal mit dem Preis der letzten Staffel bewertet. Sie werden entlang der definierten Grenzen aufgeteilt. Genau diese Einzelwerte müssen auf Invoice Line, Steuerbasis, Revenue Schedule und Buchhaltungskonto konsistent bleiben.
Usage-Events sind Belege für die Preisberechnung
Bei Seat-Modellen genügt häufig ein tagesgenauer Mengen-Snapshot. Bei Usage-based SaaS ist das Event-Modell zentral. Jedes abrechnungsrelevante Event braucht eine stabile externe Ereignis-ID, einen Kunden- oder Account-Bezug, eine Metrik, eine Menge, einen Zeitpunkt und idealerweise Dimensionen wie Region, Feature, Workspace oder Umgebung.
Doppelt übertragene Events sind ein häufiger Fehler. Deshalb muss die Ingestion idempotent sein: Ein erneutes Senden derselben Event-ID darf die abgerechnete Menge nicht erhöhen. Ebenso problematisch sind verspätete Events. Wenn eine Anfrage vom 31. Januar erst am 2. Februar eintrifft, muss die Policy klar sein: Wird sie der Januarperiode zugeordnet und per Nachberechnung korrigiert, oder bewusst im Februar abgerechnet?
Beide Varianten können sinnvoll sein. Für transaktionsnahe API-Produkte ist eine periodengerechte Zuordnung oft wirtschaftlich zutreffender. Für hochvolumige Telemetrie kann ein klarer Cut-off den Betrieb vereinfachen. Entscheidend ist, dass Product, Finance und Engineering dieselbe Regel implementieren und der Audit Trail die Entscheidung sichtbar macht.
Eine belastbare Abrechnung speichert nicht nur das Endergebnis von 650.000 Calls. Sie bewahrt die verwendete Tarifversion, den Mengenstand je Staffel, die Quelldaten und den Berechnungszeitpunkt. Damit lassen sich Kundenrückfragen beantworten, Gutschriften korrekt erzeugen und historische Rechnungen reproduzieren, obwohl sich der aktuelle Produktkatalog längst geändert hat.
Preisänderungen brauchen Versionen, keine Sonderlogik
Preisänderungen ohne Deploy sind nur dann kontrollierbar, wenn Preispläne versioniert und zeitlich wirksam sind. Ein neuer Preis darf nicht stillschweigend bereits laufende Perioden überschreiben. Sonst lässt sich später weder erklären, warum eine Rechnung entstanden ist, noch eine korrekte Umsatzabgrenzung erstellen.
Für Bestandskunden gibt es typischerweise drei Strategien: Grandfathering mit unverändertem Altpreis, Migration zu einem Stichtag oder eine individuelle Vertragskondition. Diese Entscheidung gehört an den Subscription- oder Contract-Kontext, nicht als Ausnahme in den Anwendungscode.
Auch Mid-Cycle-Änderungen müssen ausdrücklich modelliert werden. Wird ein Kunde am 16. eines 30-Tage-Monats von 40 auf 60 Seats hochgestuft, kann die zusätzliche Seat-Menge zeitanteilig berechnet werden. Bei einer volumenbasierten Staffel stellt sich zusätzlich die Frage, ob der neue Preis rückwirkend für die gesamte Periode greift oder erst ab dem Änderungszeitpunkt. Beides ist möglich, aber die Vertragssprache und die Billing-Engine müssen übereinstimmen.
Eine saubere Architektur trennt dabei Katalogpreis, kundenindividuelle Kondition und bereits fakturierte Berechnung. Nachträgliche Änderungen erfolgen über Credit Note, Nachbelastung oder eine definierte Adjustment-Position - nicht durch das Umschreiben einer gebuchten Rechnung.
Rechnung, Steuer und Zahlung sind Teil derselben Kette
Für europäische B2B-SaaS reicht es nicht, Netto-Beträge richtig zu staffeln. Die Rechnung muss den steuerlichen Kontext zum Leistungszeitpunkt korrekt abbilden. Bei grenzüberschreitenden B2B-Leistungen innerhalb der EU können eine validierte USt-IdNr., Reverse Charge und die korrekte Rechnungsformulierung erforderlich sein. Bei anderen Konstellationen greifen lokale Umsatzsteuer, EU VAT OSS oder abweichende Leistungsortregeln.
Die Steuerentscheidung darf daher nicht erst nach der Preisberechnung als pauschaler Prozentsatz ergänzt werden. Sie benötigt Kundensitz, Steuerstatus, USt-IdNr.-Prüfung, Produktklassifikation, Leistungszeitraum und Rechnungsdatum. Bei wiederkehrenden Leistungen ist besonders relevant, ob der Leistungszeitraum auf der Rechnung nachvollziehbar ausgewiesen wird.
Für öffentliche Auftraggeber und regulierte Beschaffungsprozesse kommen Formatvorgaben hinzu. Eine PDF-Rechnung allein genügt nicht immer. XRechnung und ZUGFeRD nach EN 16931 verlangen strukturierte Felder, die mit den berechneten Positionen, Steuerkategorien und Zahlungsdaten übereinstimmen müssen. Eine Staffelberechnung, die nur als unprüfbare Gesamtsumme in der Rechnung auftaucht, schafft unnötige Rückfragen.
Nach dem Invoice Finalization folgt der Einzug. Bei SEPA Direct Debit gehören Mandatsreferenz, Fälligkeitsdatum, Pre-Notification und Rücklastschriften in denselben operativen Prozess. Ein fehlgeschlagener Einzug darf nicht zu einer inhaltlich veränderten Rechnung führen. Er löst einen Forderungsstatus, Dunning-Regeln und gegebenenfalls SEPA-R-Transaction-Routing aus.
Monatsabschluss ohne Excel erfordert Ledger-fähige Daten
Die größte Schwachstelle vieler Billing-Stacks ist nicht die erste Rechnung, sondern der Abschluss. Billing erzeugt eine PDF, Payments verwaltet Transaktionen, Finance exportiert Summen und versucht anschließend, Differenzen zwischen Gutschriften, Steuern, Zahlungseingängen und Umsatzrealisierung zu erklären.
Bei Staffelpreisen müssen Ledger-Daten auf Positionsebene entstehen. Jede Rechnungslinie benötigt nachvollziehbare Netto- und Steuerbeträge, ein Erlöskonto, einen Leistungszeitraum, Vertragsbezug und Referenzen auf eventuelle Korrekturen. Für IFRS 15 oder ASC 606 ist zusätzlich zu unterscheiden, ob eine Leistung sofort erfüllt ist oder über die Zeit realisiert wird. Eine monatlich im Voraus abgerechnete Plattformgebühr und nachträglich fakturierte API-Nutzung können unterschiedliche Revenue-Schedules haben.
Der Export nach DATEV sollte keine nachgelagerte Datenbereinigung sein. Er ist das Ergebnis eines durchgängigen Modells: Preisregel erzeugt Position, Position erzeugt Steuer- und Ledger-Information, Zahlung gleicht die Forderung aus, Korrektur referenziert den Ursprungsbeleg. So bleiben Debitoren, Umsatzsteuer und Erlöse abstimmbar.
Kontier setzt diese Kette über einen versionierten Produktkatalog, Usage-Events, Steuerlogik, Rechnungsformate, SEPA und Ledger-Daten in einer europäischen Billing-Infrastruktur um. Der operative Gewinn liegt nicht nur in automatisierten Rechnungen, sondern in einer Abrechnung, deren Zahlen auch nach Preisänderung, Rücklastschrift oder Audit erklärbar bleiben.
Der sinnvolle nächste Schritt ist kein weiterer Preisrechner im Frontend. Prüfen Sie stattdessen an einem realen Kundenkonto, ob jede abgerechnete Staffelposition bis zu Tarifversion, Mengenquelle, Steuerentscheidung, Zahlung und Erlöskonto zurückverfolgt werden kann. Wenn diese Kette steht, wird Wachstum nicht zum manuellen Abstimmungsprojekt.