Die Abrechnungsübergabe darf kein letzter Punkt am Closing-Tag sein

Kläre zuerst, ob das bestehende Stripe-Konto vollständig zum verkauften Geschäft gehört und mit dem Rechtsträger fortgeführt werden kann. Wenn der Verkäufer andere Produkte oder Kunden im Konto behält, der Käufer ein eigenes Konto benötigt oder Land beziehungsweise Rechtsträger wechseln, muss Stripe den getrennten Migrationsweg bestätigen. Halte Quell- und Zielkonto, wirtschaftlich Berechtigte, Länder, Bankverbindungen und Zuständigkeiten schriftlich fest.

Erstelle danach ein datiertes Manifest aller Kunden und Abonnements im Umfang. Erfasse Status, Währung, Betrag, Intervall, Menge, Abrechnungsanker, Testphase, Rabatte, Steuern, Collection Method und besondere Vereinbarungen. Markiere gemeinsam genutzte Kunden, bevorstehende Verlängerungen, ausstehende Rechnungen, Jahresvorauszahlungen und historische Sonderpreise. Eine reine Anzahl aktiver Abonnements reicht nicht als Umfangsnachweis.

Beantrage erforderliche Customer Data Copy früh genug und prüfe die Eignung der tatsächlichen Zahlungsmethoden. Stripe kopiert nur berechtigte Customer-Daten und unterstützte gespeicherte Zahlungsmethoden. Abonnements, Rechnungen, Pläne, Gutscheine, Ereignisse und Protokolle bleiben im Quellkonto. Nach der Kopie werden Zielkunden, neue Payment-Method-Kennungen und nutzbare Standardzahlungsarten abgestimmt.

Das Zielkonto muss betriebsbereit sein: Unternehmens- und Bankdaten, Produkte, Prices, Steuer- und Rechnungseinstellungen, Mahnwesen, Belegtexte und Kundenportal werden geprüft. Jede Quell-Price erhält eine fachlich passende Zielzuordnung. Wenn eine Zahlungsart fehlt oder nicht kopierbar ist, gehört der Kunde auf eine ausdrückliche Nacharbeitsliste statt in eine pauschale Aussage, dass niemand handeln müsse.

Erstellt zweckgebundene eingeschränkte API-Schlüssel mit getrennten Rechten für Quelle und Ziel. Prüft die Berechtigungen, speichert Geheimnisse nur im vorgesehenen Tresor und legt Widerruf sowie Rotation fest. Live-Schlüssel, Webhook-Geheimnisse und kundenbezogene Exporte gehören nicht in einen allgemeinen Deal-Datenraum. Die Käuferanwendung erhält eigene Produktionsschlüssel und darf den Migrationsschlüssel nicht dauerhaft weiterverwenden.

Die Anwendungsliste umfasst alte und neue Customer-, Subscription-, Product- und Price-Kennungen, Webhook-Endpunkte, Signaturgeheimnisse, Kundenportal, Berechtigungsregeln, Analyse, Mahnwesen und Supportwerkzeuge. Für jede Änderung gibt es Test, Verantwortlichen und Rückmeldung. Neue Zielobjekte sind wertlos, wenn die Anwendung weiterhin das Quellkonto abfragt oder Zugänge anhand alter Subscription-Kennungen vergibt.

Teste eine repräsentative Population in der Sandbox: Monats- und Jahresabos, aktive Testphasen, mehrere Positionen, Rabatte, besondere Anker, Send-Invoice und problematische Zahlungen. Sandbox- und Live-Kennungen werden getrennt zugeordnet. Der abschließende Probelauf gegen die aktuellen Live-Daten darf keine Objekte schreiben, muss aber fehlende Zuordnungen, unerwartete Status und geplante Quellaktionen anzeigen.

Käufer und Verkäufer prüfen denselben Bericht. Sie bestätigen Umfang, Zielzustand, Abrechnungsgrenze, Deaktivierungsstrategie und Ausnahmen. Außerdem braucht es Go/No-Go-Kriterien: unbekanntes Kontopaar, nicht abgestimmte Kundenzahlen, fehlende Price-Zuordnungen, ungetestete Webhooks oder unklare offene Rechnungen verhindern den Live-Lauf. Eine Kalenderfrist darf diese fachliche Freigabe nicht ersetzen.

Lege für das finale Umstellungsfenster fest, ob Selbstbedienungsänderungen kurz eingefroren oder als Delta erfasst werden. Erstelle oder terminiere die Zielabonnements und vergleiche pro Datensatz Kundenbezug, Betrag, Währung, Intervall, nächste Rechnung, Testphase, Rabatt, Steuer, Collection Method und Status. Die Zielmenge allein beweist keine richtige Konfiguration.

Deaktiviere Quellabonnements erst nach der Zielprüfung und vor einer überlappenden Belastung. Untersuche offene und entworfene Rechnungen sowie anstehende Rechnungspositionen in beiden Konten. Spiele danach neue Kennungen und Zielgeheimnisse in die Anwendung aus, prüfe Webhook-Signaturen und teste den Kundenweg vom Portal bis zur Berechtigung. Speichere Laufprotokoll, Kennungszuordnung und alle manuellen Entscheidungen.

In den ersten Stunden werden Webhook-Fehler, unerwartete Rechnungen, fehlende Berechtigungen und Supportmeldungen beobachtet. In den folgenden Erneuerungskohorten prüft das Team Zahlungen, Ablehnungen, Authentifizierungsanforderungen, Mahnwesen und mögliche Quellüberschneidungen. Ein aktives Abonnement bedeutet nicht automatisch, dass die erste Rechnung bezahlt wurde.

Stimme Quellmanifest, Zielergebnis und Ausnahmen ab. Jeder fehlende Datensatz, jede nicht unterstützte Zahlungsmethode und jede manuelle Korrektur erhält Eigentümer und Abschlussnachweis. Erhalte erforderlichen Zugriff auf historische Rechnungen, Ereignisse, Streitfälle und Steuerunterlagen; schließe das alte Konto nicht ohne genehmigten Aufbewahrungsplan. Widerrufe nicht mehr benötigte Migrationsschlüssel nach der vereinbarten Beobachtung.

Jahresvorauszahlungen können Erlösabgrenzung und Kaufpreis beeinflussen. Laufende Testphasen brauchen ein korrektes Ende. Bei überfälligen Abonnements muss vereinbart werden, ob offene Beträge im Quellkonto eingezogen, abgeschrieben oder anders behandelt werden. Unternehmenskunden mit Sonderverträgen können individuelle Kommunikation oder Zustimmung verlangen. Keine allgemeine technische Regel entscheidet diese Fragen.

Die Checkliste ist keine Rechts-, Steuer-, Bilanzierungs- oder Transaktionsberatung. Parteien sollten Vertrag, Datenschutz, Mandate, Steuern, Umsatzabgrenzung, Erstattungen und Haftung mit qualifizierten Beratern prüfen. Stripe-Funktionen und Zulässigkeit hängen vom konkreten Konto- und Länderkontext ab; prüfe die Live-Dokumentation unmittelbar vor der Terminierung.