Automatische Verlängerung und bevorstehende Rechnungsstellung

Ein Tarif bestimmte, ob ein Abonnement nach Ende der aktuellen Periode in eine neue überging. Diese Auswahl war von der Zahlungsmethode getrennt: Eine automatische Verlängerung erstellte die nächste Periode, bewies aber nicht, dass Karte oder Rechnung bezahlt worden waren.

Alle Produktneuigkeiten

Historischer Rückblick: August–September 2024; seit Dezember 2025 bis September 2026 geändert

Dieser Artikel wurde nachträglich verfasst und beschreibt die Funktion, wie sie im angegebenen Zeitraum arbeitete. Spätere Meilensteine ergänzten Testphasen, Pausen und eine Verlängerungsübersicht. Testphasen und Pausen erscheinen als Perioden mit Preis null und sind keine zusätzlichen Status. Das Handbuch zum Abonnementlebenszyklus (Markdown-fil, AI-agentvenlig) beschreibt das aktuelle Verhalten.

Ein Tarif bestimmte, ob ein Abonnement nach Ende der aktuellen Periode in eine neue überging. Diese Auswahl war von der Zahlungsmethode getrennt: Eine automatische Verlängerung erstellte die nächste Periode, bewies aber nicht, dass Karte oder Rechnung bezahlt worden waren.

So funktionierte die Verlängerung

Beim Erstellen eines Tarifs wählte das Team ein Verlängerungsintervall und legte fest, ob der Tarif verlängert wurde. Sobald ein Abonnement aktiv war, erzeugte das Intervall die nächsten Perioden. Ein Verlängerungsdatum war daher der Tag, an dem eine neue Periode beginnen konnte; ein Enddatum markierte, dass danach keine weiteren Perioden erstellt werden sollten.

Künftige Perioden konnten vor der Rechnungsstellung angesehen werden. Sie zeigten Zeitraum, Währung und Betrag und wurden später zur Grundlage einer Transaktion und gegebenenfalls einer Rechnung. Eine künftige Transaktion war eine geplante Belastung und keine abgeschlossene Zahlung. Zahlungsmethode, Rechnungsmodus und lokale Zeitzone des Teams bestimmten, wann das Dokument erstellt und versendet wurde.

Beispiel aus dem historischen Modell

Ein Tarif mit monatlichem Intervall und automatischer Verlängerung konnte die Periode vom 1. bis 31. Oktober erstellen, als der September endete. Vor der Rechnungsstellung im Oktober konnte das Team Datum, Währung und Betrag in der bevorstehenden Position sehen. Bei manueller Rechnungsstellung war als Nächstes eine Aktion durch einen Benutzer erforderlich. Wurde eine Kartenbelastung abgelehnt, bestand die Periode weiterhin, ihr Zahlungsergebnis war jedoch nicht bestätigt.

Kündigung in der historischen Version

Ein Kunde konnte die nächste Verlängerung durch Kündigung des Abonnements stoppen. Dadurch wurden bereits in Rechnung gestellte Perioden nicht automatisch entfernt; eine Kündigung war auch keine Rückerstattung einer Zahlung. Die für diesen Artikel geprüften Quellen beschreiben die späteren Abläufe für Pausen und Testphasen nicht. Sie werden daher nicht als Funktionen des Jahres 2024 dargestellt.

War eine Periode bereits durch Rechnungsstellung oder Zahlung gesperrt, konnte eine spätere Änderung sie nicht einfach neu schreiben. Prüfen Sie immer bevorstehende Perioden und die letzte Rechnung, bevor Sie zu dem Schluss kommen, dass eine Verlängerung fehlt.

Häufige Fragen

Wann ist die nächste Verlängerung? Verwenden Sie das Verlängerungsdatum und die auf dem Abonnement angezeigten bevorstehenden Perioden. Die lokale Zeitzone kann die genaue Uhrzeit verschieben.

Warum wurde keine Zahlung eingezogen? Eine neue Periode kann bestehen, während eine Zahlung aussteht, abgelehnt wurde oder auf manuelle Rechnungsstellung wartet.

Kann der Kunde die Verlängerung stoppen? Ja, über den Kündigungsablauf des Teams. Dadurch ändern sich das Enddatum und künftige Perioden.

Das aktuelle Handbuch zum Abonnementlebenszyklus (Markdown-fil, AI-agentvenlig) erläutert Status, Perioden und Änderungen.

Bo Møller
Bo Møller
Emil Højbjerg
Emil Højbjerg

Die Menschen und KI-Helfer hinter den Neuigkeiten

Bo Møller und Emil Højbjerg entwickeln Alunta. Da sie die meiste Zeit programmieren, haben sie die Formulierung dieser Erklärungen an unsere KI-Helfer delegiert.

Die KI-Helfer verfassen ihre Texte auf Grundlage der veröffentlichten Produktänderungen. Bo und Emil verantworten die Änderungen und stellen sicher, dass die Informationen den tatsächlichen Veröffentlichungen entsprechen.