Von Salesforce Billing zu Revenue Cloud Billing

Der Wechsel vom Paket Salesforce Billing (Namespace blng) zu Revenue Cloud Billing bedeutet ein neues Abrechnungsdatenmodell auf Standardobjekten. Eine Umwandlung an Ort und Stelle gibt es nicht. Offene Rechnungen, Abrechnungspläne und Zahlungshistorie werden entweder im alten Paket abgeschlossen oder als Salden übernommen. Meine Empfehlung: Umstellung zum Ende einer Buchungsperiode, letzter Rechnungslauf im Paket, offene Forderungen und aktive Verträge übernehmen, abgeschlossene Historie lesbar halten oder archivieren. Abrechnungspläne entstehen in Revenue Cloud aus Aufträgen und folgen damit den migrierten Assets. Freigeben muss die Finanzabteilung, nicht das CRM-Team, denn Steuer, Zahlungen und Buchungen ändern sich mit dem System.

Wie ist der Stand bei Salesforce Billing?

Salesforce Billing kam zusammen mit Salesforce CPQ von SteelBrick und ist ein Managed Package. Im März 2025 sagte ein Salesforce-Sprecher gegenüber SalesforceBen1, dass heutige Kunden von Salesforce CPQ und Salesforce Billing “will continue to receive full access”, einschließlich Kundensupport. Neukunden und Bestandskunden, die ihre Produkte modernisieren wollen, bietet Salesforce Revenue Cloud Advanced und Revenue Cloud Billing an.

Die CPQ-End-of-Life-Seite2 beschreibt Revenue Cloud Billing lediglich als eigenes, ergänzendes Produkt der Suite. Eine eigene Verkaufsende-Aussage zum Billing-Paket habe ich im Oktober 2026 auf den Seiten von Salesforce nicht gefunden. Eine Frist gibt es also auch hier nicht. Auslöser für den Wechsel ist meist die CPQ-Migration: Sobald Angebote, Aufträge und Assets auf Standardobjekten liegen, passt ein Billing-Paket, das CPQ-Objekte liest, nicht mehr.

Zu den Namen: Die Salesforce-Hilfe nennt das Produkt derzeit Revenue Management, früher Revenue Lifecycle Management, die CPQ-Seite spricht von Agentforce Revenue Management. Auf den Produktseiten von Salesforce heißt es Revenue Cloud, mit Revenue Cloud Billing als Zusatzprodukt für die Abrechnung.

Paketobjekte im Namespace blng gegen Standardobjekte

Das Paket hat laut seinem Developer Guide3 59 eigene Objekte. Revenue Cloud Billing nutzt Standardobjekte aus dem Revenue Management Developer Guide4. Ein offizielles Mapping veröffentlicht Salesforce nicht, die Tabelle ist meine Zuordnung nach Funktion:

Funktion	Salesforce Billing (Paket)	Revenue Cloud Billing (Standardobjekte)
Abrechnungslogik	blng__BillingRule__c, blng__BillingTreatment__c	BillingPolicy, BillingTreatment, BillingTreatmentItem
Steuer	blng__TaxRule__c, blng__TaxIntegration__c	TaxPolicy, TaxTreatment, TaxEngine mit Provider-Adapter
Rechnung	blng__Invoice__c, blng__InvoiceLine__c	Invoice, InvoiceLine, InvoiceLineTax
Rechnungslauf	blng__InvoiceRun__c	InvoiceBatchRun
Gutschrift und Belastung	blng__CreditNote__c, blng__DebitNote__c	CreditMemo, DebitMemo
Buchhaltung	blng__FinanceBook__c, blng__FinancePeriod__c, blng__GLAccount__c	AccountingPeriod, GeneralLedgerAccount, GeneralLedgerJrnlEntryRule
Rechtseinheit	blng__LegalEntity__c	LegalEntity
Zahlungen	blng__Payment__c, blng__PaymentGateway__c	Objekte von Salesforce Payments plus PaymentLineInvoiceLine

Zwei Unterschiede wiegen schwerer als die Namen, ein dritter Punkt ist offen:

• Abrechnungspläne entstehen aus Aufträgen. Laut Billing-Übersicht5 erzeugt Revenue Cloud Abrechnungspläne über den Context Service und daraus die Rechnungen. Ein alter Plan wird also aus einem migrierten Asset und Auftrag neu aufgebaut.
• Steuer und Zahlungen sind anders angebunden. Steuer läuft über einen TaxEngine-Datensatz mit Provider-Adapter und Named Credential. Zahlungen nutzen Standardobjekte von Salesforce Payments mit einem externen Zahlungsanbieter. Steuer- und Zahlungsanbieter müssen die neue Anbindung bestätigen.

Was passiert mit offenen Rechnungen, Plänen und Zahlungen?

Die Salesforce-Hilfe führt Billing-Daten im Migrationsleitfaden6 als eigenes Thema neben Produkt- und Asset-Daten. Pro Datenart würde ich so entscheiden:

• Abgeschlossene Rechnungen und bezahlte Historie: nicht migrieren. Für die Aufbewahrungsfrist im Paket lesbar halten oder in ein Archiv exportieren, das die Finanzabteilung durchsuchen kann.
• Offene Rechnungen: im Paket abschließen. Zahlungen dort verbuchen oder den offenen Betrag als Saldo ins neue System übernehmen, mit Verweis auf die alte Rechnungsnummer.
• Offene Gutschriften: wenn möglich vor dem Cutover verrechnen. Der Rest wandert wie eine offene Rechnung als Saldo.
• Abrechnungspläne aktiver Verträge: aus migrierten Assets und Aufträgen neu aufbauen. Der erste Rechnungslauf in Revenue Cloud muss genau nach dem letzten abgerechneten Zeitraum im Paket beginnen, sonst bekommt ein Kunde doppelt oder gar keine Rechnung.
• Gespeicherte Zahlungsmittel: mit dem Zahlungsanbieter klären, ob Tokens in der neuen Anbindung weiter nutzbar sind.

Der Cutover gehört ans Periodenende

Revenue Cloud Billing arbeitet mit Buchungsperioden je Rechtseinheit. Die Deployment-Hinweise zu Billing7 sagen, dass Buchungsperioden nur im Status Open angelegt werden können und dass eine Rechtseinheit aktiv sein muss, wenn abhängige Datensätze entstehen. Buchungssätze fließen dann von Salesforce ins ERP. Die Produktseite zu Revenue Cloud Billing8 beschreibt Salesforce als Nebenbuch, das Buchungssätze synchronisiert.

Am Periodenende ist das alte Nebenbuch geschlossen und mit dem ERP abgestimmt. Das neue System startet mit Eröffnungssalden, denen die Finanzabteilung zugestimmt hat. Mitten in einer Periode müssten Sie einen Monat auf zwei Nebenbücher aufteilen, und die Abstimmung wird doppelt so schwer.

Rechnungsnummern brauchen dieselbe Sorgfalt. Revenue Cloud Billing hat Objekte für Nummernkreise (SequencePolicy, SequenceGapReconciliation). Lassen Sie sich vom Partner zeigen, dass sie Ihre Rechnungsnummern abdecken. Setzen Sie die Startnummer so, dass neue Rechnungen den Nummernkreis ohne Überschneidung fortsetzen, und stimmen Sie das Format mit Ihrer Steuerberatung ab.

Was muss vor dem ersten Rechnungslauf stehen?

Die Deployment-Hinweise nennen mehrere Einrichtungsschritte, die leicht übersehen werden:

1. 01

   Data Pipeline

   Ist aktiviert, bevor Billing aktiviert wird.

2. 02

   Flow Order to Billing Schedule

   Ist aus seiner Vorlage kopiert und aktiviert.

3. 03

   Rechtseinheiten und Perioden

   Rechtseinheiten und offene Buchungsperioden sind angelegt.

4. 04

   Konfiguration in Reihenfolge

   Billing Treatment Item, Billing Treatment, Billing Policy; Tax Treatment, Tax Policy; Payment Term Item, Payment Term.

5. 05

   Steuer und Zahlungen

   Steuer-Engine und Zahlungsanbieter sind angebunden und mit echten Adressen und Beträgen getestet.

Wie diese Konfigurationsdatensätze von der Sandbox in die Produktion kommen, beschreibt Revenue Cloud Deployments, den allgemeinen Ansatz das Kapitel der DevOps-Masterclass zu Daten und Konfiguration.

Rechenbeispiel: 800 Abo-Kunden mit Quartalsrechnung

Ein Maschinenbauer verkauft Fernüberwachung und Wartungsabos an 800 Kunden und rechnet sie quartalsweise aus Salesforce Billing ab. Maschinenrechnungen kommen aus SAP. Das Unternehmen stellt die Angebotserstellung auf Revenue Cloud um. Alle Zahlen sind Annahmen.

Das Billing-Team plant den Cutover zum 31. März, dem Quartalsende. Der letzte Rechnungslauf im Paket deckt das erste Quartal ab. Im April stimmt die Finanzabteilung das Nebenbuch mit SAP ab. 120 offene Rechnungen bleiben bis zur Zahlung im Paket. Die Assets für die 800 Abos werden im März migriert, die ersten Abrechnungspläne in Revenue Cloud beginnen am 1. April, der erste Rechnungslauf im Juli rechnet also das zweite Quartal ab. Abgeschlossene Rechnungen bleiben im Paket lesbar, bis die Lizenzen für CPQ und Billing enden.

Vor dem Cutover prüft die Finanzabteilung noch ein Thema: Ab 2027 greift in Deutschland die Pflicht zur E-Rechnung. Ob Rechnungen überhaupt aus Revenue Cloud kommen sollten, behandeln Revenue Cloud Billing oder SAP und E-Rechnung ab 2027.

Erster Schritt: die Finanzabteilung unterschreibt die Cutover-Checkliste

Freigeben muss die Finanzabteilung, nicht das CRM-Team. Die Entscheidungen hier sind buchhalterische: Eröffnungssalden, Periodenabschluss, Steuerbehandlung, Buchungen ins ERP und Rechnungsnummern. Ich würde den Cutover mit einer schriftlichen Checkliste aufsetzen, die die Finanzabteilung unterschreibt, und die Lizenzkosten von Revenue Cloud Billing früh einplanen; wie sie berechnet werden, steht in Revenue Cloud Billing Kosten. Die Reihenfolge der gesamten Migration beschreibt CPQ zu Revenue Cloud migrieren und das Masterclass-Kapitel Von CPQ zu Revenue Cloud. Die Schnittstellen zwischen Salesforce und SAP gehören zu meiner Arbeit bei Salesforce-Schnittstellen.

Quellen8

1. 1SalesforceBen (öffnet in einem neuen Tab)salesforceben.com
2. 2CPQ-End-of-Life-Seite (öffnet in einem neuen Tab)salesforce.com
3. 3Developer Guide (öffnet in einem neuen Tab)developer.salesforce.com
4. 4Revenue Management Developer Guide (öffnet in einem neuen Tab)developer.salesforce.com
5. 5Billing-Übersicht (öffnet in einem neuen Tab)developer.salesforce.com
6. 6Migrationsleitfaden (öffnet in einem neuen Tab)help.salesforce.com
7. 7Deployment-Hinweise zu Billing (öffnet in einem neuen Tab)developer.salesforce.com
8. 8Produktseite zu Revenue Cloud Billing (öffnet in einem neuen Tab)salesforce.com