Vergleich von klassischem und flexiblem Abrechnungsmodus

Wir empfehlen die Verwendung des flexiblen Abrechnungsmodus, da er ein verbessertes Abrechnungsverhalten und Zugang zu neuen Funktionen bietet. Der Wechsel zum flexiblen Abrechnungsmodus kann jedoch das Verhalten Ihrer Integration verändern. Prüfen Sie die folgenden Unterschiede, um die Auswirkungen auf Ihre Integration nachzuvollziehen und eine fundierte Entscheidung zu treffen.

Anteilsmäßige Verrechnung von Gutschriften

Anteilmäßige Verrechnungen werden ausgestellt, wenn Kund/innen ihre Abonnements herabstufen oder Posten vor dem Ende des Rechnungsstellungszeitraums stornieren. Der flexible Abrechnungsmodus berechnet Kund/innen anteilmäßige Verrechnungen auf der Grundlage des ursprünglich abgebuchten Betrags.

Eine vollständige Übersicht über die Berechnungen der anteilmäßigen Verrechnung finden Sie unter Verrechnungen.

Klassisch	Flexibel
Wenn eine Aktualisierung eines Abonnements zu einer anteilmäßigen Verrechnung führt, werden die anteilmäßigen Verrechnungsbeträge auf der Grundlage des aktuellen Preises, der Steuern, der Menge und der zuletzt in Anspruch genommenen Rabatte für den Posten des Abonnements berechnet.	Wenn eine Aktualisierung eines Abonnements eine anteilmäßige Verrechnung des Guthabens erzeugt, verwenden diese Verrechnungen den ursprünglich abgebuchten Betrag anstelle der aktuellen Werte des Abonnements.

Anwendung von proportionalen Rabatten für anteilmäßige Verrechnungen

We apply discounts proportionally to each subscription item during proration calculations instead of distributing them evenly. This results in more prorations, especially when invoicing on a per-item basis or canceling items with unevenly distributed discounts.

Klassisch	Flexibel
Wir verteilen Rabatte gleichmäßig auf alle Abonnementartikel.	Bei der anteilmäßigen Verrechnung wenden wir Rabatte proportional auf jeden Abonnementartikel an.

Nutzungsbasierte Tarife

Verhindern Sie Posten mit Nullbeträgen, wenn Sie nutzungsbasierte Posten hinzufügen.

Im flexiblen Abrechnungsmodus werden keine Posten mit Nullbeträgen erstellt, wenn Sie einem Abonnement nutzungsbasierte Posten hinzufügen. Wenn die Rechnung infolgedessen leer ist, erstellen wir keine Rechnung.

Zum Beispiel beim Hinzufügen eines monatlichen, nutzungsbasierten Postens bei der Erstellung oder Aktualisierung eines Abonnements:

Klassisch	Flexibel
Auf der Rechnung wird ein Posten 0 USD für den nutzungsbasierten Posten erzeugt. Dies gilt auch, wenn Sie ein Abonnement aktualisieren, ohne einen nutzungsbasierten Posten hinzuzufügen, während Sie `proration_behavior=always_invoice` verwenden.	Ein Posten 0 USD wird der Rechnung für den nutzungsbasierten Posten nicht hinzugefügt. Wenn die resultierende Rechnung keine Posten enthalten würde, erzeugen wir keine Rechnung.

Abrechnung für nutzungsbasierter Posten auf Basis des Preises zum Zeitpunkt der Meldung

Beim flexiblen Abrechnungsmodus wird die Nutzung auf der Grundlage des Preises berechnet, der zum Zeitpunkt der Meldung der Nutzung galt, und nicht auf dem neuesten Preis.

Beispiel:

Zu Beginn beträgt der Preis 0.1 USD pro 100 API-Aufrufe (Preis A)
Nutzung zum 5. Januar: 1.000 API-Aufrufe
Am 15. Januar ändert sich der Preis auf 0.15 USD pro 100 Aufrufe (Preis B)
Nutzung am 20. Januar: 500 API-Aufrufe

Klassisch	Flexibel
Stripe stellt nur die Nutzung in Rechnung, die seit der Umstellung auf den aktuellen Preis gemeldet wurde. 500 API-Aufrufe zu Preis B ( pro 100 Aufrufe) = Gesamtbetrag der Rechnung = .	Stripe stellt die gesamte Nutzung im aktuellen Zeitraum zu dem Preis in Rechnung, der zum Zeitpunkt der Meldung gültig ist. 1000 API-Aufrufe zu Preis A ( pro 100 Aufrufe) = 500 API-Aufrufe zu Preis B ( pro 100 Aufrufe) = Gesamtbetrag der Rechnung = .

Klassisch

Flexibel

Stripe stellt nur die Nutzung in Rechnung, die seit der Umstellung auf den aktuellen Preis gemeldet wurde.

500 API-Aufrufe zu Preis B ( pro 100 Aufrufe) =

Gesamtbetrag der Rechnung = .

Stripe stellt die gesamte Nutzung im aktuellen Zeitraum zu dem Preis in Rechnung, der zum Zeitpunkt der Meldung gültig ist.

1000 API-Aufrufe zu Preis A ( pro 100 Aufrufe) =
500 API-Aufrufe zu Preis B ( pro 100 Aufrufe) =

Gesamtbetrag der Rechnung = .

Abrechnung für nicht abgerechnete Nutzung beim Entfernen nutzungsbasierter Posten

Je nach dem Wert von proration_behavior kann der flexible Abrechnungsmodus beim Entfernen eines nutzungsbasierten Abonnementposten einen Rechnungsposten für nicht abgerechnete Nutzung erzeugen. Dies gilt für Entfernungen über die API oder während Phasenübergängen des Plans, die mitten in der Laufzeit stattfinden. Bei Phasenübergängen, die mit einem Abonnementposten current_period_end zusammenfallen, wird eine Rechnung mit einem Rechnungsposten für den entfernten, nutzungsbasierten Abonnementposten erstellt.

Szenario	Klassisch	Flexibel
Aktualisieren Sie Abonnements oder Pläne über die API	Beim Entfernen eines nutzungsbasierten Abonnementpostens wird kein Rechnungsposten bzw. keine Rechnung für nicht abgerechnete Nutzung erstellt.	Beim Entfernen eines nutzungsbasierten Abonnements wird ein Rechnungsposten für die nicht abgerechnete Nutzung erstellt.
Phasenübergang des Plans	Beim Entfernen eines nutzungsbasierten Abonnementpostens wird eine Rechnung (aber kein Rechnungsposten) für nicht abgerechnete Nutzung erstellt.	Abhängig vom `proration_behavior` der anstehenden Phase: `create_prorations`: Beim Entfernen eines nutzungsbasierten Abonnementpostens wird ein Rechnungsposten für nicht abgerechnete Nutzung erstellt. `always_invoice`: ein Rechnungsposten für nicht abgerechnete Nutzung wird erstellt und sofort in Rechnung gestellt. `none`: es wird kein Rechnungsposten erstellt.

Abrechnungszyklusanker zurücksetzen

Beim flexiblen Abrechnungsmodus wird Ihr Abrechnungszyklusanker nur bei Abonnementaktualisierungen zurückgesetzt, wenn Sie billing_cycle_anchor explizit auf einen anderen Wert als unchanged setzen.

Classic	Höchst flexibel
Der `billing_cycle_anchor` wird automatisch auf das aktuelle Datum zurückgesetzt, wenn ein Abo auf einen anderen Preis mit einem anderen wiederkehrenden Intervall umgestellt wird, von Preisen mit Nullbetrag auf Preise ungleich Null oder wenn cancel_at auf ein Datum vor der nächsten Erneuerung des Abos gesetzt wird.	Der `billing_cycle_anchor` wird nie automatisch zurückgesetzt.

Konsolidierte Rechnungen für die Phasenübergänge der Abonnementpläne mit nutzungsbasierten Posten

Der flexible Abrechnungsmodus erstellt bei jeder Verlängerung eines Abos konsequent eine einzige Rechnung. Diese Änderung beseitigt separate Rechnungen für beseitigte nutzungsbasierte Posten und verbessert die Konsistenz der Abrechnung.

Wenn Ihr Abonnement mit nutzungsbasierten Posten zwischen den Phasen übergeht:

Klassisch	Flexibel
Es werden zwei Rechnungen generiert.	Es wird eine einzige konsolidierte Rechnung erstellt. Diese Rechnung enthält sowohl nutzungsbasierte als auch lizenzierte Posten, wendet Rabatte aus der vorherigen Phase auf die nutzungsbasierte Abrechnung an und verwendet Steuersätze aus der nächsten Phase.

Geplante Kündigung des Abonnements

Der flexible Abrechnungsmodus ermöglicht es, die anteilmäßige Verrechnung für einen verkürzten ersten Rechnungsstellungszeitraum (bei Festlegung von cancel_at bei Erstellung) mithilfe des Parameters proration_behavior zu deaktivieren.

Klassisch	Flexibel
Anteilmäßige Verrechnungen werden auf den ersten Rechnungsstellungszeitraum angewendet.	Anteilmäßige Verrechnungen werden nicht auf den ersten Rechnungsstellungszeitraum angewandt.

Abonnements zurückdatieren

Wenn die Rückdatierung mit der regulären Abrechnung übereinstimmt, erstellt der flexible Abrechnungsmodus separate Rechnungsposten für jeden Rechnungsstellungszeitraum innerhalb des rückdatierten Zeitraums. Außerdem wird der Anker des Abrechnungszyklus automatisch an das backdate_start_date angepasst, wenn er nicht explizit festgelegt wurde. Die Rückdatierung wird nicht unterstützt, wenn die resultierende Rechnung mehr als 250 Posten enthält.

Beispielsweise muss ein Abo aufgrund einer fehlenden Rechnung für die letzten beiden Rechnungsstellungszeiträume rückdatiert werden. Der Kundin/dem Kunden wurden 2 verschiedene rückdatierte Zeiträume in Rechnung gestellt:

Abrechnungszeitraum 1 (1. März bis 31. März):
- Gemeldete Nutzung: 100 GB Speicherplatz belegt.
- Preis: 10 USD pro 10 GB.

Abrechnungszeitraum 2 (1. April bis 30. April):

Gemeldete Nutzung: 150 GB Speicherplatz belegt.
Preis: 10 USD pro 10 GB.

Der Dienstleister entscheidet sich, die Rechnung so rückzudatieren, dass sie beide Abrechnungszeiträume abdeckt: 1. März bis 30. April.

Classic	Höchst flexibel
Zahlungen für den gesamten rückdatierten Zeitraum werden zusammengefasst als Einzelposten berechnet. Zahlungen insgesamt: 250 GB = 25 x 10 USD = 250 USD Dieser Betrag wird als einzelner Posten auf der Rechnung angezeigt.	Rückdatierte Zeiträume werden in mehrere Rechnungsposten entsprechend den Grenzen des Rechnungsstellungszeitraums aufgeteilt. Gesamte Abbuchungen: Abrechnungszeitraum 1 (März): 100 GB = 10 x 10 USD = 100 USD (als separater Posten). Abrechnungszeitraum 2 (April): 150 GB = 15 x 10 USD = 150 USD (als separater Posten).

Testzeiträume

Startdatum für nachfolgende Testversionen aktualisieren

Beim flexiblen Abrechnungsmodus wird das letzte Startdatum der Testversion für Abonnements mit nachfolgenden Testversionen verwendet.

Zum Beispiel, wenn Sie Folgendes haben:

Testzeitraum vom 1. Januar bis 1. Februar
Normaler Abrechnungszeitraum vom 1. Februar bis 1. März
Testzeitraum vom 1. März bis 1. April

Klassisch	Flexibel
Das `subscription.trial_start`-Datum bezieht sich immer auf den ersten Testzeitraum eines Abonnements.	Das `subscription.trial_start`-Datum bezieht sich auf den Beginn der letzten Testphase eines Abonnements.

Ursprüngliches Enddatum der Testversion beibehalten, wenn ein Abonnement gekündigt wird

Beim flexiblen Abrechnungsmodus wird das trial_end-Datum beibehalten, wenn Sie das cancel_at-Datum ändern.

Classic	Höchst flexibel
Wenn Sie `cancel_at` auf ein Datum setzen, das vor dem Datum von `trial_end` liegt, wird `trial_end` automatisch an `cancel_at` angepasst. Wenn Sie jedoch `cancel_at` entfernen oder auf ein späteres Datum als `trial_end` setzen, wird `trial_end` nicht automatisch geändert, selbst wenn `trial_end` ursprünglich ein späteres Datum lautete.	Wenn Sie eine Abonnementkündigung mit `cancel_at` planen, bleibt das `trial_end`-Datum davon unberührt. Dadurch wird sichergestellt, dass Testversionen unabhängig von der Aktualisierung des Kündigungsdatums für die vorgesehene Dauer ausgeführt werden.

Postenbeschreibung für den Testzeitraum standardisieren

Der flexible Abrechnungsmodus verwendet ein einheitliches Beschreibungsformat sowohl für nutzungsbasierte als auch für lizenzierte Posten während der Testzeiträume.

Wenn Sie zum Beispiel ein monatliches Kaffee-Abonnement (lizenziert) und ein Abo für alpaca_ai_tokens (nutzungsbasiert) haben, wird die Beschreibung des Abos wie folgt angezeigt:

Klassisch Flexibel

Klassisch	Flexibel
Lizenzierte Posten verwenden die Vorlage `Trial period for {product name}`, während nutzungsbasierte Posten `{quantity} x {product name} (Free trial)` verwenden. Für lizenzierte Artikel: `Trial period for monthly coffee subscription` Für nutzungsbasierte Posten: `10 x monthly alpaca_ai_tokens (Free trial)`	Für alle Artikeltypen gilt das gleiche Format `Free trial for {quantity} x {product name}`, wodurch die Informationen zum Testzeitraum einheitlicher dargestellt werden. Diese Beschreibungen sind ebenfalls lokal angepasst. Für lizenzierte Artikel: `Free trial for 1 x monthly coffee subscription` Für nutzungsbasierte Posten: `Free trial for 10 x monthly alpaca_ai_tokens subscription`

Lizenzierte Posten verwenden die Vorlage Trial period for {product name}, während nutzungsbasierte Posten {quantity} x {product name} (Free trial) verwenden.

Für lizenzierte Artikel:
- Trial period for monthly coffee subscription
Für nutzungsbasierte Posten:
- 10 x monthly alpaca_ai_tokens (Free trial)

Für alle Artikeltypen gilt das gleiche Format Free trial for {quantity} x {product name}, wodurch die Informationen zum Testzeitraum einheitlicher dargestellt werden. Diese Beschreibungen sind ebenfalls lokal angepasst.

Für lizenzierte Artikel:
- Free trial for 1 x monthly coffee subscription
Für nutzungsbasierte Posten:
- Free trial for 10 x monthly alpaca_ai_tokens subscription

Erneute Abrechnung für Testposten

Der flexible Abrechnungsmodus generiert nur Einzelposten für Änderungen, die während eines Testzeitraums vorgenommen werden. Bestehende Posten ohne Änderungen werden nicht erneut abgerechnet.

Wenn Sie beispielsweise eine Aktualisierung vornehmen, um einem Testabonnement mit price_a einen weiteren Testposten price_b hinzuzufügen:

Classic	Höchst flexibel
Änderungen während eines Testzeitraums führen entweder zu keiner Rechnung oder zu einer Rechnung, die den gesamten Status des Abonnements wiedergibt.	Änderungen während eines Testzeitraums führen durchweg zu Posten, die mit Änderungen außerhalb eines Testzeitraums vergleichbar sind. Wenn zum Beispiel ein neuer Preis zu einem Abo hinzugefügt wird, wird auch ein Posten für diesen Preis hinzugefügt.

Ausstehende Rechnungsposten

Ausstehende Rechnungsposten durchgängig einbeziehen

Der flexible Abrechnungsmodus umfasst alle verfügbaren ausstehenden Rechnungsposten in Rechnungen, die durch das Zurücksetzen des Abrechnungszyklusankers generiert wurden, wobei proration_behavior = always_invoice.

Klassisch	Flexibel
Rechnungen, die aufgrund des Zurücksetzens des „billing cycle anchor“ erstellt werden, enthalten nur ausstehende Posten, wenn das `proration behavior` nicht auf `always_invoice` gesetzt ist.	Ausstehende Rechnungsposten sind immer in allen Rechnungen enthalten, die ein Abonnement generiert.

Gemischte Intervalle im selben Abo

Der flexible Abrechnungsmodus ermöglicht die Erstellung von Abos mit gemischten Intervallen, die für mehrere wiederkehrende Preise mit unterschiedlichen Intervallen abrechnen können. Dadurch können verschiedene Preisstrukturen innerhalb eines einzelnen Abos kombiniert werden.

Klassisch	Flexibel
Nicht unterstützt. Alle Posten in einem Abonnement müssen Preise mit dem gleichen Intervall und der gleichen Intervallanzahl haben.	Posten in einem Abo mit gemischten Intervallen können wiederkehrende Preise mit unterschiedlichen Intervallen oder Intervallanzahlen enthalten. Zum Beispiel kann ein monatlicher Preis und ein jährlicher Preis für dasselbe Abo gelten.