Usage-Based-Billing-Software bewerten: eine Matrix mit sieben Tests
Zwei Anbieter für nutzungsbasierte Abrechnung, zwei gute Demos, zwei ähnliche Preise. Nach drei Wochen Evaluierung hat Ihr Team eine Tabelle mit 60 Zeilen, und in fast jeder steht bei beiden „ja“. Die Entscheidung fällt dann nach Sympathie oder nach Listenpreis, und die Unterschiede zeigen sich erst im dritten Monat nach dem Go-live, wenn ein Kunde eine Rechnung über 48.120 API-Calls anzweifelt.
Dieser Beitrag ist eine Bewertungsmatrix für Usage-Based-Billing-Software: sieben gewichtete Kriterien, jeweils mit einem Test, den der Anbieter vorführen muss, und einer Skala von 0 bis 3. Die allgemeinen Anforderungen an Abrechnungssoftware für den EU-Markt, von SEPA bis DATEV, stehen in unserer Anforderungsliste für Abrechnungssoftware. Hier geht es um das, was bei Usage-Billing anders ist: Events, Korrekturen, Preislogik und Nachvollziehbarkeit.
Bewerten Sie mit Ihren eigenen Daten
Bevor Sie Anbieter vergleichen, exportieren Sie eine Woche echter Usage-Events aus Ihrem Produkt, anonymisiert, mit allen Unschärfen: doppelte Events nach Retries, Events mit Zeitstempel aus der Vorwoche, Events von Testkonten. Dazu kommen drei echte Verträge, darunter der komplizierteste, den Sales je abgeschlossen hat.
Jeder Anbieter bekommt dieselben Daten und dieselben Verträge. Bewertet wird, was im Testkonto passiert, nicht was auf Folien steht. Ein Anbieter, der keine Testumgebung für diesen Zweck bereitstellt, hat damit schon eine Frage beantwortet.
Die Matrix: sieben Kriterien, gewichtet
Die Gewichte unten passen für ein typisches B2B-SaaS mit API- oder Volumenpreisen und Kunden in mehreren EU-Ländern. Verschieben Sie sie für Ihr Geschäft, aber legen Sie sie fest, bevor Sie die erste Demo sehen.
| Kriterium | Gewicht | Test im Testkonto |
|---|---|---|
| Event-Annahme und Idempotenz | 20 | Dieselbe Event-Woche zweimal senden. Ändert sich die Rechnung? |
| Korrekturen und späte Events | 15 | Event mit Zeitstempel im bereits abgerechneten Vormonat senden |
| Preismodelle | 15 | Ihren kompliziertesten Vertrag ohne Sonderentwicklung abbilden lassen |
| Nachvollziehbarkeit der Rechnungszeile | 15 | Von einer Rechnungszeile auf die einzelnen Events zurückgehen |
| EU-Steuern und E-Rechnung | 15 | Usage-Rechnung an einen B2B-Kunden in einem anderen EU-Land als XRechnung erzeugen |
| Kundensicht und Limits | 10 | Verbrauch im Kundenportal sehen, Warnung bei 80 % des Kontingents auslösen |
| Export und Datenzugriff | 10 | Rohdaten und abgerechnete Mengen für einen Monat exportieren |
Bewertung je Kriterium: 0 = nicht vorhanden, 1 = nur mit Eigenentwicklung oder manuellem Schritt, 2 = vorhanden mit Einschränkung, 3 = vorhanden und im Test bestanden.
Was hinter jedem Kriterium steckt
Event-Annahme und Idempotenz: Jedes Event braucht einen eindeutigen Schlüssel, und die Software muss ein zweites Event mit demselben Schlüssel verwerfen, ohne Fehler und ohne doppelte Menge. Das Muster beschreibt der IETF-Entwurf zum Idempotency-Key-Header. Fragen Sie auch nach dem Durchsatz und was bei Überlast passiert: Werden Events gepuffert oder abgelehnt? Wie Sie Idempotenz auf Ihrer Seite umsetzen, steht im Beitrag zu idempotent verarbeiteten Usage-Events.
Korrekturen und späte Events: Ein Event vom 30. April, das am 3. Mai ankommt, nachdem die Aprilrechnung festgeschrieben ist. Gute Software hat dafür eine feste Regel, etwa Nachberechnung auf der Mairechnung mit Verweis auf den Leistungszeitraum April. Schlechte Software ändert die festgeschriebene Rechnung oder verliert das Event. Beides ist ein K.-o.-Kriterium.
Preismodelle: Freikontingente, Staffeln, Volumenpreise, Mindestabnahmen, Prepaid-Credits und eine Grundgebühr pro Seat. Entscheidend ist der Unterschied zwischen Staffel- und Volumenpreis. Bei 12.000 Calls mit einer Grenze bei 10.000 berechnet die Staffel die ersten 10.000 zum ersten Preis und 2.000 zum zweiten, der Volumenpreis alle 12.000 zum zweiten. Lassen Sie den Anbieter beide Varianten mit denselben Zahlen vorrechnen.
Nachvollziehbarkeit der Rechnungszeile: Ein Kunde zweifelt „48.120 API-Calls“ an. Ihr Support muss in Minuten zeigen können, welche Events dahinterstehen, welche als Duplikat verworfen wurden und welche Korrektur eingeflossen ist. Für die Aufbewahrung in Deutschland gilt: Rechnungen acht Jahre, und die Herleitung der Menge sollte so lange rekonstruierbar sein.
EU-Steuern und E-Rechnung: Usage-Rechnungen sind Rechnungen. Für einen Kunden in Frankreich mit gültiger USt-IdNr. braucht die Rechnung den Reverse-Charge-Hinweis, für deutsche Firmenkunden ab 2028 eine E-Rechnung. Prüfen Sie das Ergebnis mit dem KoSIT-Validator, nicht mit dem Auge. Und fragen Sie, ob die Steuer pro Rechnungszeile oder pro Rechnung ermittelt wird, wenn ein Vertrag Leistungen mit unterschiedlicher steuerlicher Einordnung enthält.
Kundensicht und Limits: Nutzungsbasierte Preise erzeugen Rechnungen, die Kunden nicht vorhergesehen haben. Ein Portal mit aktuellem Verbrauch und Warnungen vor dem Überschreiten eines Kontingents spart Support-Tickets und Gutschriften.
Export und Datenzugriff: Sie brauchen Rohdaten und abgerechnete Mengen in Ihrem Data Warehouse, sonst gibt es zwei Wahrheiten über Umsatz und Nutzung. Prüfen Sie, ob der Export vollständig ist oder nur Aggregate liefert.
Ein Rechenbeispiel mit zwei Anbietern
Erfundene Ergebnisse für zwei Anbieter nach dem Test mit Ihren Daten:
| Kriterium | Gewicht | Anbieter A | Anbieter B |
|---|---|---|---|
| Event-Annahme und Idempotenz | 20 | 3 | 3 |
| Korrekturen und späte Events | 15 | 1 | 3 |
| Preismodelle | 15 | 3 | 2 |
| Nachvollziehbarkeit der Rechnungszeile | 15 | 2 | 3 |
| EU-Steuern und E-Rechnung | 15 | 1 | 3 |
| Kundensicht und Limits | 10 | 3 | 1 |
| Export und Datenzugriff | 10 | 2 | 2 |
| Summe (Gewicht × Punkte, max. 300) | 215 | 255 |
Anbieter A hatte die eindrucksvollere Demo: flexible Preismodelle und ein schönes Kundenportal. Anbieter B gewinnt trotzdem deutlich, weil er bei späten Events und EU-Steuern besteht. A ist in beiden Punkten auf Eigenentwicklung angewiesen. Diese Lücken kosten jeden Monat Arbeit, während ein schwächeres Portal sich nachbauen lässt.
Legen Sie außerdem K.-o.-Kriterien fest, die unabhängig von der Summe gelten. Eine 0 bei Idempotenz oder bei Korrekturen sollte einen Anbieter ausschließen, egal wie hoch die Summe ist.
Wann ein einfacheres Werkzeug reicht
Nicht jedes Unternehmen mit einer Verbrauchskomponente braucht ein spezialisiertes System. Ein Abrechnungstool mit einfachen Mengenpositionen reicht oft, wenn diese drei Bedingungen gelten:
- Es gibt eine einzige Verbrauchsgröße, monatlich aggregiert, mit linearem Preis.
- Die Menge stammt aus einem Report, den Ihr Team vor dem Rechnungslauf prüft.
- Korrekturen kommen so selten vor, dass eine manuelle Gutschrift vertretbar ist.
Sobald Sie mehrere Meter, Staffeln, Prepaid-Credits oder Echtzeitlimits brauchen, oder sobald Kunden ihre Abrechnung regelmäßig anzweifeln, reicht das nicht mehr.
Die Reihenfolge der Evaluierung
- Gewichte und K.-o.-Kriterien schriftlich festlegen.
- Eine Woche echter Events und drei Verträge vorbereiten.
- Jeden Anbieter die sieben Tests im Testkonto vorführen lassen, mit Finance und Engineering im Raum.
- Punkte direkt nach jeder Sitzung vergeben, nicht am Ende.
- Mit dem Gewinner einen vollständigen Monat im Testkonto abrechnen und mit Ihrer bisherigen Abrechnung vergleichen.
Kontier bündelt Usage Metering, Staffelpreise, Subscription Billing und EU-Steuerlogik in einem System; die Details stehen auf der Seite zur nutzungsbasierten Abrechnung.
Kein Steuer- oder Rechtsrat. Dieser Beitrag beschreibt die Rechtslage und Praxis allgemein. Für Ihren Einzelfall fragen Sie Ihre Steuerberatung. Stand: