# Vergleich von klassischem und flexiblem Abrechnungsmodus Erfahren Sie mehr über die Unterschiede zwischen den verschiedenen Abrechnungsmodi Wir empfehlen die Verwendung des [flexiblen Abrechnungsmodus](https://docs.stripe.com/billing/subscriptions/billing-mode.md), 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. > Ein Abonnement kann nicht vom flexiblen Abrechnungsmodus in den klassischen Abrechnungsmodus migriert werden. ## 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](https://docs.stripe.com/billing/subscriptions/prorations.md#credit-prorations). | **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 anteilsmäßige Guthabenverrechnung generiert, wird für diese anteilsmäßigen Verrechnungen der ursprüngliche abgebuchte Betrag anstelle der aktuellen Abonnement-Werte verwendet. Wenn der Zeitraum, für den die Gutschrift ausgestellt wird, ursprünglich über mehrere Lastschriften abgerechnet wurde, generiert Stripe mehrere anteilsmäßige Guthabenverrechnungen: jeweils eine für jede ursprüngliche Lastschrift. | ### Anwendung von proportionalen Rabatten für anteilmäßige Verrechnungen Bei der [anteilmäßigen Verrechnung](https://docs.stripe.com/billing/subscriptions/prorations.md#prorations-and-discounts) werden die Rabatte anteilmäßig auf jeden Posten des Abonnements verrechnet, anstatt sie gleichmäßig zu verteilen. Dies führt zu mehr anteilmäßigen Verrechnungen, insbesondere wenn Sie Rechnungen pro Posten stellen oder Posten mit ungleichmäßig verteilten Rabatten stornieren. | **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. | Dies gilt jedoch nicht für Rechnungen, die während des Abrechnungszyklus erstellt werden. Die Rechnung enthält alle verbrauchsabhängigen Posten, einschließlich der Positionen mit dem Betrag 0 USD. ### 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: 1. Zu Beginn beträgt der Preis 0.1 USD pro 100 API-Aufrufe (Preis A) 1. Nutzung zum 5. Januar: 1.000 API-Aufrufe 1. Am 15. Januar ändert sich der Preis auf 0.15 USD pro 100 Aufrufe (Preis B) 1. 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 = . | ### 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](https://docs.stripe.com/billing/subscriptions/billing-cycle.md) 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](https://docs.stripe.com/api/subscriptions/object.md#subscription_object-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 ### Kündigungen im Kundenportal Wenn eine Kundin/ein Kunde eine Kündigung über das [Kundenportal](https://docs.stripe.com/customer-management/cancellation-page.md) zeitlich plant, wird im flexiblen Abrechnungsmodus direkt `cancel_at` anstelle von `cancel_at_period_end` verwendet. Weitere Informationen zu den Unterschieden zwischen `cancel_at` und `cancel_at_period_end` finden Sie [im Änderungsprotokoll](https://docs.stripe.com/changelog/basil/2025-07-30/cancel-at-enums.md). | **Klassisch** | **Flexibel** | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `cancel_at_period_end` ist auf `true` festgelegt und `cancel_at` ist auf den `current_period_end`-Zeitstempel festgelegt. Da `cancel_at_period_end` `true` ist, wird `cancel_at` bei jeder Änderung des Werts `current_period_end` aktualisiert. | `cancel_at_period_end` ist auf `false` festgelegt und `cancel_at` ist bei allen Abonnementposten auf den maximalen Wert für `current_period_end` festgelegt. Wenn sich der Wert für `current_period_end` eines Postens ändert, wird das Kündigungsdatum (`cancel_at`) nicht aktualisiert. | ### Ohne anteilsmäßige Verrechnungen für den ersten gekürzten Rechnungsstellungszeitraum Der flexible Abrechnungsmodus ermöglicht es, anteilmäßige Verrechnungen für einen verkürzten ersten Rechnungsstellungszeitraum (bei Festlegung von `cancel_at` bei Erstellung) mithilfe des Parameters `proration_behavior`, der auf `none` gesetzt ist, 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](https://docs.stripe.com/billing/subscriptions/backdating.md) 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 `hypernian_tokens` (nutzungsbasiert) haben, wird die Beschreibung des Abos wie folgt angezeigt: | **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 hypernian_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 hypernian_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](https://docs.stripe.com/billing/subscriptions/mixed-interval.md), 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](https://docs.stripe.com/billing/subscriptions/mixed-interval.md) 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. |