Um Doppelabrechnungen während einer WHMCS-Migration zu vermeiden, ordnen Sie jedem Kunden für seinen nächsten Abrechnungszeitraum ein System zu. Erfassen Sie die letzte Rechnung aus dem Altsystem, die erste Verlängerung im neuen System sowie alle bereits in der Warteschlange befindlichen Zahlungen, bevor Sie die neue Abrechnung aktivieren. Durch die Übertragung von Kundendaten wird weder die Abrechnungsverantwortung übertragen noch eine bestehende Zahlungsvereinbarung beendet.
Dieser Leitfaden richtet sich an Hosting-Anbieter, die die wiederkehrende Kundenabrechnung in ein neues Portal verlagern und dabei einen Teil der Hosting-Automatisierung beibehalten möchten. Der Schwerpunkt liegt auf dem Übergabetermin. Für einen umfassenderen Überblick über Daten und Module nutzen Sie das „Checkliste für die WHMCS-Migration“. Das unten stehende Arbeitsblatt ist ein manuelles Planungstool, kein automatischer WHMCS-Importer.
Was kann während einer WHMCS-Migration zu doppelten Abbuchungen führen?
Ein Duplikat kann durch sich überschneidende Rechnungen, zwei unabhängige wiederkehrende Vereinbarungen oder einen erneuten Zahlungsversuch entstehen, dessen Ergebnis noch nicht vorliegt. Die entscheidende Frage ist, welches System noch eine Zahlung für denselben Leistungszeitraum anfordern kann. Ein erfolgreicher Export beantwortet diese Frage nicht. Unter
Abrechnungslogik von WHMCS werden die Rechnungserstellung, Fälligkeitstermine und automatische Zahlungsversuche dokumentiert. Überprüfen Sie die installierte Version und Ihre Einstellungen, bevor Sie das Übergabedatum auswählen. Eine Rechnung für einen zukünftigen Zeitraum kann bereits vorhanden sein, auch wenn der Kunde den Verlängerungstermin noch nicht erreicht hat.
Unterscheiden Sie zwischen einer Rechnung und einem Zahlungsversuch. Zwei Rechnungen beweisen nicht zwei erfolgreiche Abbuchungen, und eine sichtbare Rechnung beweist nicht, dass nur ein System den Betrag einziehen kann. Überprüfen Sie sowohl die Abrechnungsanwendungen als auch den tatsächlichen Transaktionsstatus des Anbieters. Ausstehende Einzüge, abgeschlossene Zahlungen und fehlgeschlagene Zahlungen erfordern jeweils unterschiedliche Folgemaßnahmen.
Externe wiederkehrende Vereinbarungen verdienen eine eigene Überprüfung. WHMCS beschreibt optionale Gateway-Abonnementverwaltungen für wiederkehrende Vereinbarungen, die außerhalb von WHMCS abgewickelt werden. Die Modulunterstützung und die Einstellungen spielen eine Rolle. Gehen Sie nicht davon aus, dass die Änderung eines Dienstdatensatzes automatisch jede anbieterseitige Vereinbarung storniert.
Listen Sie auch Erinnerungen, Wiederholungsversuche und Sperraufträge auf. Selbst wenn nur ein System den Einzug vornimmt, können beide dem Kunden eine E-Mail senden oder eine Maßnahme wegen überfälliger Dienste einleiten. Eine Übergabe, die doppelte Geldbewegungen verhindert, kann Kunden dennoch verwirren, wenn zwei verschiedene Portale unterschiedliche Salden anzeigen.
Erstellen Sie einen Verlängerungs-Übergabedatensatz pro Dienst
Verwenden Sie eine Zeile für jeden wiederkehrenden Dienst, anstatt eine Zeile für ein gesamtes Kundenkonto. Hosting, Wartung und eine Domain-Verlängerung können unterschiedliche Termine und Zuständigkeiten haben. Gemeinsame Kontaktdaten sind nützlich für den Identitätsabgleich, machen die Dienste jedoch nicht austauschbar.
Laden Sie die CSV-Datei für die Übergabe der Vertragsverlängerungen herunter. Die Datei enthält englische Spaltenüberschriften und fiktive Beispielzeilen. Ersetzen Sie die Beispiele in Ihrer privaten Kopie. Es handelt sich nicht um ein Importformat für eine der beiden Plattformen und die Datei enthält keine Zahlungsdaten.
| Feld | Fiktives Beispiel | Vor der Aktivierung prüfen |
|---|---|---|
| Kunden- und Dienstreferenz | Beispiel A / Managed Hosting | Muss mit dem tatsächlichen Dienst übereinstimmen, nicht nur mit einer E-Mail-Adresse |
| Bezahlt bis | 31. Oktober 2026 | Bestätigen Sie den Zeitraum auf der ausgestellten Rechnung |
| Letzte Rechnung aus dem Altsystem | Hosting-Rechnung vom Oktober | Trennen Sie bezahlte, unbezahlte und strittige Salden |
| Erster neuer Leistungszeitraum | 1.–30. November 2026 | Stellen Sie sicher, dass dieser Zeitraum keinen anderen Rechnungsverantwortlichen hat |
| Erstes neues Rechnungsdatum | 1. November 2026 | Überprüfen Sie den Zeitplan des Anbieters und ausstehende Zahlungsversuche |
| Bereitschaft zur automatischen Zahlung | Noch zu bestätigen | Autorisierung vor dem Einzug überprüfen |
| Verantwortlicher für den Hosting-Lebenszyklus | Bestehender Hosting-Workflow | Festlegen, wer sich um Ausfälle und Kündigungen kümmert |
Fügen Sie Betrag, Währung, steuerliche Behandlung und die für die Genehmigung der Zeile verantwortliche Person hinzu. Diese Felder verhindern eine Migration, die zwar datumsmäßig korrekt ist, bei den Summen jedoch Fehler aufweist. Bei einem jährlichen Hosting-Vertrag mit monatlicher Abrechnung müssen die tatsächlichen Vertrags- und Leistungszeitraumdaten ebenfalls separat erfasst werden.
Bewahren Sie historische Rechnungsreferenzen auf. Der Austausch eines Portals sollte nicht dazu führen, dass Nachweise über abgerechnete und bezahlte Beträge gelöscht werden. Legen Sie fest, wo Kunden alte Dokumente abrufen können und wie Mitarbeiter Fragen zu Zeiträumen beantworten, die zum vorherigen System gehören.
Bestehende Rechnungen vor Beginn der Ersatzabrechnung abgleichen
Beginnen Sie mit einer kleinen Gruppe, deren Datensätze Sie einzeln überprüfen können. Trennen Sie alte, noch nicht beglichene Forderungen von der nächsten Verlängerung. Einen ausstehenden Saldo in ein neues Portal zu übernehmen und für denselben Saldo eine neue Belastung zu erstellen, ist keine Abgleichmethode.
Vergleichen Sie für jeden Kunden die alte Rechnung, die Transaktion des Anbieters und den Leistungszeitraum. Erfassen Sie Gutschriften und Rückerstattungen separat. Ein Guthaben kann die nächste Rechnung ausgleichen; wenn nur der Brutto-Wiederkehrpreis übertragen wird, kann dieser Zusammenhang verloren gehen. Lassen Sie die zuständige Abrechnungskraft entscheiden, wie der Saldo vorgetragen wird.
Überprüfen Sie die Zeitfenster für die Rechnungserstellung, nicht nur die Fälligkeitstermine. Wenn bereits eine alte Verlängerungsrechnung ausgestellt wurde, entscheiden Sie, ob diese Rechnung weiterhin als Zahlungsbeleg gilt oder entsprechend korrigiert werden muss. Halten Sie sich an Ihren Buchhaltungsprozess und die geltenden Anforderungen, anstatt Datensätze einfach zu löschen, nur damit das neue Dashboard übersichtlich aussieht.
Bevor Sie einen ausstehenden Zahlungsversuch ändern, erfragen Sie dessen aktuellen Status beim Anbieter. Eine verzögerte Bestätigung kann wie ein Fehlschlag wirken, obwohl der Geldtransfer noch läuft. Senden Sie dem Kunden keine zweite zahlbare Rechnung, nur weil die Anzeige des ersten Vorgangs noch nicht aktualisiert wurde.
Halten Sie Ausnahmen aus der ersten Gruppe heraus. Umstrittene Zahlungen, Salden in mehreren Währungen und Dienste mit ungewöhnlicher anteiliger Abrechnung erfordern eine separate Überprüfung. Der Zweck eines Pilotprojekts besteht darin, eine wiederholbare Übergabe zu etablieren, und nicht darin, komplizierte Konten innerhalb einer größeren Migrationssumme zu verbergen.
Durchgang eines fiktiven monatlichen Hosting-Übergangs
Angenommen, „Example Hosting“ verkauft Managed Hosting für 29 € pro Monat. Kunde A hat für Oktober bezahlt und sollte als Nächstes für November bezahlen. Der Planungsdatensatz besagt, dass WHMCS für den Oktober zuständig ist; PayRequest ist erst dann für den November zuständig, wenn die Einrichtung und die Zahlungsprüfungen abgeschlossen sind.
Stellen Sie sicher, dass das alte System die Zahlung für November nicht bereits angefordert hat. Falls doch, klären Sie diese bestehende Rechnung oder den entsprechenden Zahlungsversuch, bevor Sie eine neue Abrechnung autorisieren. Ändern Sie das erste neue Datum nicht einfach auf heute, nur weil der Kunde heute importiert wurde. Das Importdatum und das Datum der vollständigen Bezahlung dienen unterschiedlichen Zwecken.
Gehen Sie bei Kunde B davon aus, dass der November bereits im Voraus bezahlt ist. Der erste neue Zeitraum sollte dann an diesen bezahlten Zeitraum anschließen, vorbehaltlich der tatsächlichen Vertragsbedingungen. Eine pauschale Regel „Alle Kunden beginnen am 1. November“ würde B für einen Zeitraum belasten, der bereits abgedeckt war.
Nehmen wir für Kunde C an, dass der Oktober noch unbezahlt ist. Halten Sie diese Forderung als „Oktober“ erkennbar. Legen Sie den Verantwortlichen für die November-Abrechnung separat fest und entscheiden Sie, wie der überfällige Saldo kommuniziert werden soll. Die Aktivierung des Abonnements in einem neuen Portal bedeutet nicht, dass die ältere Rechnung bezahlt wurde.
Dies sind fiktive Beispiele, keine Berichte über abgeschlossene PayRequest-Migrationen. Ihr Wert liegt in der Entscheidungsregel: Für jeden zu bezahlenden Leistungszeitraum muss ein Verantwortlicher dokumentiert sein, und bereits bezahlte Zeiträume müssen im neuen Zeitplan sichtbar bleiben.
Abrechnungsänderungen getrennt von der Hosting-Kündigung behandeln
Verwenden Sie die Kündigung eines Dienstes nicht als Abkürzung, um alte Abrechnungen zu deaktivieren, ohne deren Auswirkungen zu prüfen. In der WHMCS-Anleitung „Unterlagen zur Kündigung“ wird erläutert, dass die Kündigung eines Dienstes ein Bereitstellungsmodul und die damit verbundenen Zugriffsrechte betreffen kann. Eine Abrechnungsmigration sollte nicht versehentlich zu einer Hosting-Abschaltung führen.
Halten Sie fest, welches System Konten bereitstellt, Domain-Verlängerungen abwickelt und Maßnahmen bei überfälligen Leistungen verarbeitet. Wenn Sie WHMCS für diese Aufgaben nutzen, vergewissern Sie sich, wie die Abrechnungsergebnisse dort ankommen. Das Vorhandensein einer API oder eines Webhooks bedeutet noch keine funktionierende Integration; jemand muss den tatsächlichen Lebenszyklus implementieren und überprüfen.
Beschränken Sie jede Änderung an der Automatisierung auf die genehmigte Gruppe. Das Deaktivieren eines globalen Jobs kann Kunden betreffen, die weiterhin über WHMCS abgerechnet werden. Führen Sie Aufzeichnungen über geänderte Einstellungen und den beabsichtigten Umfang, und lassen Sie von einem Mitarbeiter überprüfen, was für noch nicht migrierte Konten weiterhin aktiv bleibt.
Verwenden Sie die Funktion „Leitfaden zur Übergabe bei Kündigung“, wenn Kunden ausstehende Kündigungsanträge haben. Ein Kunde, der bereits gekündigt hat, sollte während der Migration nicht unbemerkt ein neues, laufendes Abonnement erhalten.
Teilen Sie den Kunden mit, welche Rechnung und welches Portal sie nutzen sollen
Senden Sie eine kurze Nachricht, in der das neue Abrechnungsportal, der erste betroffene Abrechnungszeitraum und alle tatsächlich erforderlichen Maßnahmen genannt werden. Versprechen Sie nicht, dass alle gespeicherten Zahlungsmethoden übertragen werden. Nutzen Sie die Funktion „Leitfaden zur Vorbereitung auf Zahlungsmandate“, bevor Sie entscheiden, ob jemand erneut eine Autorisierung vornehmen muss.
Eine wiederverwendbare Nachricht lautet: „Ab [erster betroffener Abrechnungszeitraum] erfolgt die Abrechnung für [Dienst] über [neues Portal]. Ihre bisherigen Rechnungen bleiben unter [Speicherort der Dokumente] verfügbar. Ihr nächster fälliger Betrag beträgt [Betrag und Währung] am [Datum]. [Geben Sie die bestätigte Zahlungsmaßnahme an]. Sollten Sie zwei Rechnungen für diesen Zeitraum erhalten, wenden Sie sich bitte an [Supportkanal], bevor Sie eine weitere Zahlung vornehmen.“
Ersetzen Sie jedes Feld in Klammern durch den verifizierten Datensatz. Versenden Sie die Vorlage nicht als pauschale Ankündigung, wenn Kunden unterschiedliche Zahlungsfristen haben. Gruppieren Sie die Mitteilungen nach dem tatsächlichen Übergangszeitraum und erläutern Sie separate Domain-Verlängerungen, sofern diese im alten System verbleiben.
Überprüfen Sie die Seite des öffentlichen Portals aus Kundensicht. Überprüfen Sie den Servicenamen, die Währung, das nächste Datum und den Zugriff auf die Rechnung. Eine korrekte interne Tabelle ist nur dann nützlich, wenn der Kunde übereinstimmende Informationen sieht und weiß, an welchen Supportkanal er sich bei Fragen zur Änderung wenden kann.
Überprüfen Sie die erste Verlängerung und legen Sie fest, wann ein Rollback erfolgen soll
Die erste Verlängerung ist der Zeitpunkt, an dem die Planung auf ein tatsächliches Abrechnungsergebnis trifft. Überprüfen Sie den Rechnungszeitraum, die Anbietertransaktion, den Kundensaldo und den Hosting-Status gemeinsam. Wenn ein Versuch des Anbieters aussteht, warten Sie auf ein verlässliches Ergebnis, bevor Sie entscheiden, erneut eine Zahlung einzuziehen.
Legen Sie vor der Erweiterung der Gruppe eine Stoppbedingung fest: ungeklärte doppelte Rechnungen, nicht übereinstimmende Beträge, fehlende Autorisierung oder falscher Servicezugang. Weisen Sie eine Person zu, die die Ausnahme behebt. Eine kleinere, geprüfte Migration ist einfacher zu handhaben als ein großer Stapel, dessen Fehler von den Kunden entdeckt werden.
Ein Rollback erfordert dieselbe Verantwortlichkeitsdisziplin wie die Inbetriebnahme. Überprüfen Sie ausstehende und abgeschlossene Versuche im neuen System, bevor Sie das alte Inkasso wieder aktivieren. Die Wiederherstellung des alten Auftrags, während ein neuer Versuch noch aussteht, kann erneut zu dem Duplikat führen, das Sie eigentlich verhindern wollten.
Das „Dokumentation zu Abonnementzahlungen“ von PayRequest unterscheidet zwischen manuell bezahlten wiederkehrenden Rechnungen und dem automatischen Inkasso über ein gültiges Mandat. Überprüfen Sie diese Unterscheidung sowie das „Portal-Demo“ und reichen Sie das ausgefüllte Arbeitsblatt anschließend im „Migrationsbewertung“ ein.
PayRequest Business kostet 20 € pro Monat und umfasst das Kundenportal sowie die wiederkehrende Abrechnung. Die Standard-Zahlungsgebühren der Plattform betragen 0 %, solange der kostenpflichtige Tarif aktiv ist. Bearbeitungsgebühren des Anbieters fallen separat an; für Provisionszahlungen gilt eine eigene Gebühr. Schließen Sie die Kontoeinrichtung ab und aktivieren Sie „Business“ an der Kasse. Die Auswahl von „Business“ bei der Anmeldung gewährt an sich noch keinen kostenpflichtigen Zugang. Informieren Sie sich unter Aktuelle Preise, bevor Sie Ihre Konfiguration auswählen.
Anmerkung der Redaktion: Dieser Artikel und das illustrative Titelbild wurden mithilfe von KI erstellt. Die offizielle Dokumentation wurde am 7. Oktober 2026 überprüft. Arbeitsblätter und Kundenmitteilungen sind originale Planungsvorlagen. Alle Beispiele sind fiktiv; für diesen Artikel wurden keine tatsächlichen Abrechnungen, Kundenmigrationen oder Hosting-Kündigungen durchgeführt.
