Verbrauchsabrechnung und Preisgestaltung: Technik vs. Finanzen

Einleitung

Nutzungsabhängige und hybride Preisgestaltung ist selten statisch. Wenn die Preisbildungslogik fest programmiert ist, wird jede Anpassung einer Preisstufe oder eines Guthabens zu einem Support-Ticket. Das ist zeitaufwendig für die Finanzabteilung und frustrierend für Entwickler. Wer sollte also für die Nutzungserfassung und die darauf aufbauende Preisgestaltung verantwortlich sein? Lassen Sie uns das klären.

Warum Preisänderungen mittlerweile häufig vorkommen

Die Preisgestaltung ist keine Entscheidung mehr, die man einmal trifft und dann vergisst. Der „SaaS & AI Pricing Report“ der Beratungsfirma hy und OMR Reviews, der sich auf Daten von Growth Unhinged stützt, besagt, dass drei von vier US-Softwareunternehmen ihre Preise im vergangenen Jahr geändert haben. Das ist eine Menge Bewegung.

Auch die Modelle verschieben sich. In der Umfrage von hy unter 180 Softwareunternehmen nutzen bereits 37 % nutzungsbasierte Modelle, und 59 % kombinieren mehr als eine Preiskennzahl, wie beispielsweise die Abrechnung pro Nutzer neben dem API-Volumen. Gutschriften hinzufügen, Experimente durchführen, Pakete optimieren – so werden Änderungen eher zur Norm als zur Ausnahme.

Wie die Preisgestaltung letztendlich in die Hände der Entwickler gelangt

Meist geschieht dies eher zufällig. Zu Beginn programmiert ein Entwickler eine Metrik fest ein: API-Aufrufe zählen, einen Tarif anwenden, die Gesamtsumme auf die Rechnung setzen. Es funktioniert, also hinterfragt es niemand.

Dann entwickelt sich die Preisgestaltung weiter. Eine neue Stufe, ein kostenloses Kontingent oder ein anderer Überziehungssatz bedeuten, dass jemand ein Ticket einreicht, auf einen Sprint-Platz wartet und hofft, dass das Release die Rechnungsstellung nicht beeinträchtigt. Die Vorlaufzeit verlängert sich, und jedes Release birgt ein gewisses Risiko. Die Finanzabteilung landet schließlich in einer Warteschlange, über die sie keine Kontrolle hat.

Hybride Modelle verschlimmern dies noch. Je mehr Komponenten ein Preis umfasst, desto mehr Stellen im Code kann sich eine Änderung verstecken.

Die Kosten einer von der Technik gesteuerten Preisgestaltung

Die Kosten sind real, auch ohne eine Tabelle, die sie belegt.

• Langsame Einführungen: Eine Preisidee kann wochenlang hinter der Produktentwicklung zurückbleiben.
• Fehler: Im Code verborgene Logik ist für die Finanzabteilung schwer nachzuvollziehen, sodass Fehler häufig erst auf Rechnungen zutage treten.
• Blinde Flecken der Finanzabteilung: Wenn die Finanzabteilung nicht nachvollziehen kann, wie eine Zahl berechnet wurde, dauert die Klärung von Streitfällen länger.
• Opportunitätskosten: Entwickler pflegen den Abrechnungscode, anstatt am Produkt zu arbeiten.

Meine Einschätzung lautet: Wenn eine Preisänderung eine Code-Bereitstellung erfordert, richtet sich Ihre Preisgestaltung nach dem Tempo Ihres Release-Kalenders und nicht nach dem Tempo Ihres Marktes

Was die Finanzabteilung und was die Technikabteilung verantworten sollte

Die Zuständigkeit ist kein Entweder-oder. Man sollte sie nach der Art der Entscheidung aufteilen.

Die Technik ist verantwortlich für die Ereigniserfassung, Datenpipelines und die Genauigkeit der Nutzungsdaten an der Quelle.

Die Finanzabteilung und das Produktteam sind für Metrikdefinitionen, Preisniveaus, Paketangebote und Gutschriftenzuständig.

Hier ist ein einfacher Test: Wenn es bei der Änderung darum geht, was erfasst wird, fällt sie in den Zuständigkeitsbereich der Technik. Wenn es darum geht, wie die erfasste Nutzung in Geld umgewandelt wird, fällt sie in den Zuständigkeitsbereich der Finanzabteilung und des Produktteams. Die Entscheidung, dass ein Tarif beispielsweise 1.500 statt 1.000 API-Aufrufe umfasst, ist eine Preisentscheidung. Die Sicherstellung, dass jeder Aufruf genau einmal protokolliert wird, ist eine technische Aufgabe.

Governance bei Preisänderungen

Die Übergabe der Kontrolle ohne Leitplanken führt zu Chaos. Dies sind allgemeine Best Practices, die nicht an ein bestimmtes Tool gebunden sind:

• Genehmigungen: Bevor eine Änderung live geschaltet wird, ist eine namentliche Freigabe durch die Finanzabteilung und das Produktteam erforderlich.
• Tests: Überprüfen Sie vor der Inbetriebnahme die Auswirkungen anhand realer Nutzungsdaten.
• Versionierung: Verwalten Sie jede Preiskonfiguration in verschiedenen Versionen, damit Sie diese vergleichen oder ein Rollback durchführen können.
• Gültigkeitsdaten: Legen Sie fest, ab wann eine Änderung gilt und wie bereits während des Zyklus erfasste Nutzungsdaten behandelt werden.
• Prüfpfad: Erfassen Sie, wer was wann geändert hat.

Stellen Sie sich das als Code-Review für die Preisgestaltung vor. Niemand veröffentlicht Code, ohne dass ein zweites Paar Augen ihn überprüft hat, und Preise verdienen dieselbe Sorgfalt.

Voraussetzungen für eine finanzgesteuerte Preisgestaltung

Die Finanzabteilung kann nicht die Verantwortung für etwas übernehmen, dem sie nicht vertrauen kann. Drei Grundlagen stehen an erster Stelle.

Saubere Nutzungsdaten. Doppelte oder fehlende Ereignisse untergraben jeden Preis, den Sie darauf aufsetzen.

Vereinbarte Metrikdefinitionen. Wenn das Produktteam einen „aktiven Nutzer“ auf eine bestimmte Weise definiert und die Finanzabteilung auf eine andere, werden Ihre Rechnungen den Streit für Sie entscheiden – und zwar nicht auf freundliche Weise.

Zuverlässige Quellen. Nutzungsdaten befinden sich in der Regel in einem Data Warehouse, hinter einer API oder in Dateien. Wählen Sie für jede Kennzahl ein einziges Referenzsystem aus und halten Sie sich daran.

Fragen, die Sie sich stellen sollten, bevor Sie die Verantwortung für die Preisgestaltung übertragen

Bringen Sie den CFO, den Produktleiter und den Leiter der Entwicklungsabteilung an einen Tisch und gehen Sie folgende Punkte durch:

1. Welche Preisänderungen haben wir im letzten Jahr vorgenommen, und wie lange hat die Umsetzung jeweils gedauert?
2. Gibt es für jede abrechnungsrelevante Kennzahl eine einheitliche Definition?
3. Kann die Finanzabteilung nachvollziehen, wie aus einer Nutzungszahl eine Rechnungsposition wurde?
4. Wer genehmigt eine Änderung, und wie testen wir sie, bevor sie in Betrieb genommen wird?
5. Wo werden die Nutzungsdaten gespeichert, und wer ist für deren Richtigkeit verantwortlich?

Wenn Sie zwei oder drei dieser Fragen nicht beantworten können, ist das Ihr Ausgangspunkt.

Preisgestaltung ändern, ohne die Nutzungserfassung neu aufzubauen

Hier können Tools helfen. Laut der Seite „Usage Metering“ von Zenskar können Teams abrechnungsrelevante Kennzahlen in einfacher Sprache definieren und die Aggregationslogik von der KI erstellen lassen oder für komplexe Logik benutzerdefiniertes SQL schreiben. Nutzungsdaten können aus Quellen wie Postgres, Athena und MySQL abgerufen, über eine API übertragen oder als CSV-Datei hochgeladen werden. Dieselbe Kennzahl kann produkt-, vertrags- und positionsübergreifend wiederverwendet werden.

Entscheidend für die Eigenverantwortung ist, dass eine nutzungsbasierte Abrechnungssoftware es ermöglichen sollte, Preisstufen, Überschreitungsgebühren und Abrechnungsrhythmus unabhängig von der Nutzung anzupassen. Die Abrechnungslogik kann auch während des Abrechnungszyklus geändert werden, ohne die Datenpipeline zu stören. Eine einzige Metrik kann verschiedene Preismodelle über Verträge hinweg steuern und sorgt so für eine stabile Erfassung, während sich die Preisgestaltung weiterentwickelt.

Fazit

Das sinnvollste Modell ist ein gemeinsames Modell. Die Technik sorgt dafür, dass die Nutzungsdaten korrekt sind und fließen. Die Finanzabteilung und das Produktteam entscheiden im Rahmen klarer Governance-Regeln darüber, welchen Wert diese Daten haben. Welche Preisänderung steht bei Ihnen gerade in der technischen Warteschlange an?

Wichtige Erkenntnisse:

• Fest programmierte Preise machen jede Anpassung an Preisstufen oder Gutschriften zu einem Support-Ticket für die Technik.
• Teilen Sie die Zuständigkeiten nach Entscheidungstyp auf: Die Technik ist für die Erfassung und Richtigkeit der Nutzungsdaten zuständig, während die Finanzabteilung und das Produktteam für die Definition der Kennzahlen, Preisstufen, Paketangebote und Gutschriften verantwortlich sind.
• Richten Sie zunächst Sicherheitsvorkehrungen ein: Genehmigungen, Tests, Versionsverwaltung, Gültigkeitsdaten und einen Prüfpfad.
• Eine finanzgesteuerte Preisgestaltung benötigt saubere Nutzungsdaten, vereinbarte Metrikdefinitionen und ein einziges Referenzsystem pro Metrik.
• Nutzen Sie die fünf Fragen vor der Übergabe, um Ihren Ausgangspunkt zu finden.
• Wählen Sie Tools, die Preisänderungen ermöglichen, ohne dass die Messung neu aufgebaut werden muss.