Abonnements zurückdatieren

Erfahren Sie, wie Sie bestehende Abonnements zurückdatieren können.

Sie können ein Abonnement rückdatieren, um Kundinnen/Kunden einen bereits abgelaufenen Zeitraum in Rechnung zu stellen. Dies wird häufig bei einer Migration zu Stripe oder zu Dokumentationszwecken verwendet. Das Feld backdate_start_date gibt das Datum an, auf das der Beginn des Abonnements rückdatiert wird. Optional können Sie Kundinnen/Kunden diese bereits abgelaufene Zeit in Rechnung stellen und das nächste Abrechnungsdatum festlegen.

Überlegungen zum Abrechnungsmodus

Ab API-Version vom 30.04.2025 hängt das Rückdatierungsverhalten vom billing_mode Ihres Abonnements ab:

Vorher

Nachher

Verwenden Sie billing_mode=classic, um einen einzelnen anteiligen Posten für den rückwirkenden Zeitraum zu erstellen.

Verwenden Sie billing_mode=flexible, um für jeden natürlichen Rechnungsstellungszeitraum, der im rückdatierten Zeitraum liegt, einen Rechnungsposten zu generieren. Dies verhält sich ähnlich wie die reguläre Abrechnung.

Notiz

Die Rückdatierung wird nicht unterstützt, wenn eine Rechnung mehr als 250 Posten enthält. Dies ist das Standardlimit.

Rückdatieren und Nutzer/innen belasten

Manchmal können Nutzer/innen Zugriff auf Ihren Dienst haben, bevor Sie ein Abonnement für sie erstellen, und Sie ihnen diesen Zugriff in Rechnung stellen möchten.

Um einer Nutzerin/einem Nutzer diese Zeit über das Dashboard in Rechnung zu stellen:

Gehen Sie zur Seite Zahlungen > Abonnements.
Klicken Sie auf + Abonnement erstellen.
Suchen Sie nach einem/einer Kund/in oder fügen Sie eine/n Kund/in hinzu.
Geben Sie die Preis- und Produktinformationen ein.
Wählen Sie im Abschnitt Abonnementdetails das Start- und Enddatum des Abonnements aus. Wenn Sie es rückdatieren möchten, wählen ein Startdatum in der Vergangenheit aus.
Wählen Sie das Datum aus, an dem der Rechnungsstellungszeitraum beginnen soll.
(Optional) Legen Sie wahlweise die Option Zahlung oder Erweitert fest.
Klicken Sie auf Abonnement erstellen. Das Abonnement startet an dem von Ihnen ausgewählten Datum.

Dadurch wird eine Rechnung mit Zahlungen für den Zeitraum zwischen dem rückdatierten Startdatum und dem aktuellen Datum erstellt.

Wenn ein Abo billing_mode=classic hat, erstellt Stripe einen einzelnen anteiligen Betrag für den rückdatierten Zeitraum, basierend auf einem fiktiven Intervall, das am rückdatierten Startdatum beginnt. Wenn Sie beispielsweise einen monatlichen Rechnungsstellungszeitraum haben, der am ersten Tag des Monats beginnt und backdate_start_date auf den 15. Februar (in einem Nicht-Schaltjahr) setzen, berechnet Stripe die anteilige Gebühr auf Grundlage eines fiktiven Monats vom 15. Februar bis 15. März. Da der Februar 28 Tage hat, entspricht der anteilige Betrag für die 14 Tage vom 15. Februar bis 1. März genau der Hälfte einer regulären monatlichen Gebühr.

Wenn Sie backdate_start_date auf den 15. Januar festlegen, stützt Stripe die anteilmäßige Verrechnung auf einen fiktiven Monat vom 15. Januar bis zum 15. Februar. Dieser fiktive Monat hat 31 Tage, sodass der anteilig verrechnete Betrag für die 17 Tage vom 15. Januar bis zum 1. Februar 17 geteilt durch 31 (ca. 0,548) einer normalen monatlichen Zahlung ist.

Sie können die Berechnung auch anzeigen, indem Sie das rückdatierte Startdatum als ursprüngliches Startdatum betrachten. Der Beginn des ersten vollständigen Abrechnungszeitraums wird dann zum aktualisierten Startdatum.

Wenn ein Abo billing_mode=flexible hat, erstellt Stripe für jeden natürlichen Rechnungsstellungszeitraum, der im rückdatierten Zeitraum liegt, separate Rechnungsposten. Das bedeutet, dass jeder Zyklus so behandelt wird, als hätte Stripe ihn in diesem Zeitraum regulär abgerechnet.

Rückdatieren und Nutzer/innen nicht belasten

Sie können ein Abonnement auch zurückdatieren, ohne dem Kunden/der Kundin den rückwirkenden Zeitraum in Rechnung zu stellen. Dies ist nützlich, wenn Sie zu Stripe migrieren. Übergeben Sie dazu beim Erstellen des Abonnements proration_behavior: 'none'. Dadurch wird start_date auf den gleichen Wert wie backdate_start_date gesetzt, dem Kunden/der Kundin wird jedoch keine rückdatierte Zeit in Rechnung gestellt.

Rückdatieren und Abrechnungszyklusanker festlegen

Sie können backdate_start_date und billing_cycle_anchorkombinieren, um ein Abonnement rückzudatieren und den Abrechnungszyklusanker auf ein Datum in der Zukunft festzulegen. Dadurch wird auf der nächsten Rechnung ein anteilig verrechneter Posten für die Zeit zwischen dem rückdatierten Startdatum und dem Abrechnungszyklusanker erstellt. Dies ist hilfreich, wenn Sie zu Stripe migrieren und das nächste Abrechnungsdatum für Ihre Abonnements übertragen müssen, während Sie Kundinnen/Kunden die verstrichene Zeit in Rechnung stellen.

Beispiel: Am 15. Oktober migrieren Sie zu Stripe. Sie haben ein Abonnement, das am 1. September begonnen hat und der 1. November ist das nächste Abrechnungsdatum. Erstellen Sie zum Migrieren dieses Abonnements ein neues Abonnement und legen Sie backdate_start_date auf den 1. September und billing_cycle_anchor auf den 1. November fest.

Dadurch wird sofort eine Rechnung über den anteiligen Betrag für den Zeitraum zwischen dem 1. September und dem 1. November ausgestellt. Außerdem wird das start_date des Abonnements auf den 1. September festgelegt. Stripe stellt die nächste Rechnung am 1. November aus.

Ein Update rückdatieren

Um das Datum des Inkrafttretens von anteilmäßigen Verrechnungen beim Aktualisieren eines Abonnements festzulegen, verwenden Sie den Parameter proration_date. Übergeben Sie einen ganzzahligen Unix-Zeitstempel, der innerhalb des aktuellen Zeitraums der Artikel des Abonnements vorkommt. Wenn für das Abonnement ein Abonnementplan verwendet wird, stellen Sie sicher, dass der Zeitstempel vor dem Startdatum der nächsten Phase des Plans liegt.

Sie können ein proration_date nur während des ersten Zeitraums eines rückdatierten Abonnements vor dem aktuellen Zeitraum festlegen. In dieser Situation muss das proration_date vor oder nach dem subscription[start_date] liegen (rückdatiertes Startdatum). In allen anderen Fällen, darf das proration_date nicht vor dem current_period_start liegen.