payInAdvance = true) und Nachgelagert (payInAdvance = false). Welcher davon richtig ist, hängt davon ab, ob die abzurechnende Menge zum Periodenstart bereits feststeht.
Dieser Artikel richtet sich an Solution Architects und Power‑User, die Preismodelle abbilden. Wenn du nur ein einfaches Abo mit Festpreis konfigurierst, brauchst du nicht weiterzulesen — der Default ist Vorausabrechnung und das ist meistens richtig.
Entscheidungsmatrix
| Konstellation | Abrechnungszeitpunkt | Begründung |
|---|---|---|
| Festpreis pro Periode (z.B. „99 €/Monat”) | Vorausabrechnung | Menge und Preis stehen zum Periodenstart fest |
| Mengenpreis mit fester Anzahl Einheiten (z.B. „10 Lizenzen × 8 €/Monat”) | Vorausabrechnung | Menge ist im Vertrag/Abonnement gesetzt |
| Nutzungsbasiert (BillableMetric, z.B. „pro API‑Call”) | Nachgelagert (erzwungen) | Menge ergibt sich erst aus den Events der Periode |
| Staffelpreis ohne Nutzungsmetrik (z.B. „bis 100 Lizenzen 8 €, ab 101 dann 6 €“) | Vorausabrechnung | Menge bleibt im Abonnement gesetzt |
| Einmalige Setup‑Gebühr | Vorausabrechnung (OneTime) | Wird sofort fällig |
Warum Nutzungsbasiert immer nachgelagert ist
Eine Nutzungsmetrik wie „Tokens”, „API‑Calls” oder „Storage‑GB” aggregiert Ereignisse, die während einer Abrechnungsperiode entstehen. Vor Periodenende kennt das System die Summe nicht. Wäre die Vorausabrechnung erlaubt, müsste der Wert geschätzt werden. Das führt zu zwei Problemen, die in der Praxis immer auftreten:- Schätzfehler: Der Schätzwert weicht von der tatsächlichen Nutzung ab. Die erste Rechnung müsste später korrigiert werden — entweder durch eine Gutschrift oder eine Nachberechnung. Bei vielen Abonnements bedeutet das eine Welle korrigierter Rechnungen mit allem Buchhaltungs‑Overhead.
- Falsche Signale an den Kunden: Eine Rechnung, deren Betrag nicht den tatsächlichen Verbrauch widerspiegelt, untergräbt das Versprechen „du zahlst nur, was du verbrauchst”.
Mischformen sauber modellieren
Drei gängige Anforderungen werden oft fälschlich als „BillableMetric mit Vorausabrechnung” formuliert. Alle drei lassen sich sauber mit zwei Abonnementpositionen abbilden:Mindestabnahme + Mehrverbrauch
Anforderung: „Mindestens 10.000 API‑Calls im Monat sind inklusive und werden monatlich im Voraus berechnet. Was darüber hinausgeht, kostet 0,01 € pro Call und wird am Monatsende abgerechnet.” Modellierung:Position 1 – Grundgebühr (Vorausabrechnung)
- Produkt: „API‑Zugang Standard”
- PricePlan:
flat_fee, Vorausabrechnung, 100 €/Monat - Keine Nutzungsmetrik
Prepaid‑Credits / Volumenpaket
Anforderung: „Der Kunde kauft ein Paket mit 50.000 Tokens für 200 €. Die Tokens werden verbraucht, dann muss er ein neues Paket kaufen.” Modellierung:Position 1 – Token‑Paket (Vorausabrechnung, einmalig)
- Produkt: „Token‑Paket 50k”
- PricePlan:
OneTime, Vorausabrechnung, 200 € fix - Wird beim Kauf abgerechnet
Position 2 – Nutzungs‑Tracking (Nachgelagert, mit Filter)
- Produkt: „Token‑Nutzung” mit Nutzungsmetrik (
SUMauftokens_used) - PricePlan:
per_unit, Nachgelagert, 0 €/Token - Freikontingent entspricht dem gekauften Paket‑Volumen
- Wenn das Paket aufgebraucht ist, wird über einen Filter oder ein Folge‑Produkt nachgeladen
Geschätzte Abrechnung mit True‑Up
Anforderung: „Der Kunde zahlt monatlich 500 € im Voraus auf Basis einer Schätzung. Am Quartalsende wird die tatsächliche Nutzung gegengerechnet.” Modellierung: Diese Variante ist in der Praxis im DACH‑B2B‑SaaS selten und wird in Fynn nicht durch ein Spezial‑Feature unterstützt. Die saubere Abbildung ist:Position 1 – Abschlagszahlung (Vorausabrechnung, monatlich)
- Produkt: „Service Abschlag”
- PricePlan:
flat_fee, Vorausabrechnung, 500 €/Monat
Position 2 – Tatsächliche Nutzung (Nachgelagert, quartalsweise)
- Produkt: „Service Nutzung” mit Nutzungsmetrik
- PricePlan:
per_unit, Nachgelagert, quartalsweise
Was im Hintergrund passiert
Wenn ein Abonnement aktiviert wird, gibt es zwei mögliche Verläufe: Vorausabrechnung (payInAdvance = true):
- Subscription‑Start am 1. Mai
- Sofort wird eine Rechnung für
[1. Mai, 1. Juni)erzeugt - Nächste Abrechnung: 1. Juni für
[1. Juni, 1. Juli), etc.
payInAdvance = false):
- Subscription‑Start am 1. Mai
- Keine Rechnung am 1. Mai
- Während Mai werden Nutzungsereignisse erfasst
- Am 1. Juni: Rechnung für
[1. Mai, 1. Juni)mit der aggregierten Mai‑Nutzung - Nächste Abrechnung: 1. Juli für
[1. Juni, 1. Juli), etc.
Häufige Fragen
Kann ich einen einzelnen Kunden auf Vorausabrechnung umstellen, auch wenn das Produkt nutzungsbasiert ist?
Kann ich einen einzelnen Kunden auf Vorausabrechnung umstellen, auch wenn das Produkt nutzungsbasiert ist?
Nein. Die Regel gilt produktseitig, nicht kundenseitig. Wenn du für einen Kunden ein anderes Abrechnungsmodell brauchst, modellierst du das über eine separate Abonnementposition mit anderem Produkt.
Was passiert, wenn ein Kunde mitten in einer Periode kündigt?
Was passiert, wenn ein Kunde mitten in einer Periode kündigt?
Bei Vorausabrechnung gibt es typischerweise eine anteilige Gutschrift für den ungenutzten Rest. Bei nachgelagerter Abrechnung wird die bis zur Kündigung erfasste Nutzung wie üblich am nächsten Abrechnungstermin in Rechnung gestellt — ohne Sonderbehandlung.
Können in einem Abonnement beide Abrechnungszeitpunkte gleichzeitig vorkommen?
Können in einem Abonnement beide Abrechnungszeitpunkte gleichzeitig vorkommen?
Ja. Jede Abonnementposition entscheidet selbst. Eine Position mit Grundgebühr kann im Voraus laufen, während eine zweite Position mit Nutzungsabrechnung nachgelagert läuft. Die Rechnungen erscheinen einfach zu verschiedenen Zeitpunkten.
Verwandte Themen
Nutzungsmetriken
Wie du Events erfasst und aggregierst.
Verständnis nutzungsbasierter Abrechnung
Wie die Aggregation in der Abrechnung sichtbar wird.