From Salesforce Billing to Revenue Cloud Billing

Moving from the Salesforce Billing package (namespace blng) to Revenue Cloud Billing means a new billing data model on standard objects. There is no in-place conversion. Open invoices, billing schedules and payment history are either finished in the old package or moved as balances. My recommendation: cut over at the end of an accounting period, run the last invoices in the package, move open receivables and active contracts, and keep closed history readable or archived. Billing schedules in Revenue Cloud come from orders, so they follow the migrated assets. Finance signs off, not the CRM team, because tax, payments and journal entries change with the system.

What is the status of Salesforce Billing?

Salesforce Billing came with Salesforce CPQ from SteelBrick and is a managed package. In March 2025 a Salesforce spokesperson told SalesforceBen1 that current Salesforce CPQ and Salesforce Billing customers “will continue to receive full access”, including customer support. For new customers and existing customers who want to update their products, Salesforce offers Revenue Cloud Advanced and Revenue Cloud Billing.

The CPQ end-of-life page2 only describes Revenue Cloud Billing as a separate, complementary product in the suite. A separate end-of-sale statement for the Billing package is something I did not find on Salesforce’s pages in October 2026. So there is no deadline for billing either. The trigger for a move is usually the CPQ migration: once quotes, orders and assets live on standard objects, a billing package that reads CPQ objects no longer fits.

A note on names: Salesforce Help currently calls the product Revenue Management, earlier Revenue Lifecycle Management, and the CPQ page says Agentforce Revenue Management. Salesforce’s product pages say Revenue Cloud, with Revenue Cloud Billing as the billing add-on.

Package objects in the blng namespace against standard objects

The package has 59 custom objects in its developer guide3. Revenue Cloud Billing uses standard objects from the Revenue Management Developer Guide4. Salesforce publishes no official mapping between them; the table is my orientation by function:

Function	Salesforce Billing (package)	Revenue Cloud Billing (standard objects)
Billing logic	blng__BillingRule__c, blng__BillingTreatment__c	BillingPolicy, BillingTreatment, BillingTreatmentItem
Tax	blng__TaxRule__c, blng__TaxIntegration__c	TaxPolicy, TaxTreatment, TaxEngine with a provider adapter
Invoice	blng__Invoice__c, blng__InvoiceLine__c	Invoice, InvoiceLine, InvoiceLineTax
Invoice run	blng__InvoiceRun__c	InvoiceBatchRun
Credit and debit	blng__CreditNote__c, blng__DebitNote__c	CreditMemo, DebitMemo
Accounting	blng__FinanceBook__c, blng__FinancePeriod__c, blng__GLAccount__c	AccountingPeriod, GeneralLedgerAccount, GeneralLedgerJrnlEntryRule
Legal entity	blng__LegalEntity__c	LegalEntity
Payments	blng__Payment__c, blng__PaymentGateway__c	Salesforce Payments objects plus PaymentLineInvoiceLine

Two differences matter more than the names, and a third point is open:

• Billing schedules come from orders. According to the Billing overview5, Revenue Cloud generates billing schedules through the context service and creates invoices from them. An old schedule is therefore rebuilt from a migrated asset and order.
• Tax and payments are connected differently. Tax runs through a TaxEngine record with a provider adapter and a named credential. Payments use standard Salesforce Payments objects with an external gateway. Your tax provider and payment provider both need to confirm the new connection.

What happens to open invoices, schedules and payments?

Salesforce Help lists billing data as its own topic in the migration guide6, next to product and asset data. For each kind of record, I would decide like this:

• Closed invoices and paid history: do not migrate. Keep them readable in the package for the retention period or export them to an archive that finance can search.
• Open invoices: finish them in the package. Collect the payments there or move the open amount as a balance into the new system, with a reference to the old invoice number.
• Open credit notes: apply them before the cutover where possible. What remains moves as a balance, like an open invoice.
• Billing schedules for active contracts: rebuild them from migrated assets and orders. The first invoice run in Revenue Cloud must start exactly after the last billed period in the package, otherwise a customer gets billed twice or not at all.
• Stored payment methods: clarify with your payment provider whether tokens can be reused in the new connection.

The cutover belongs at a period end

Revenue Cloud Billing works with accounting periods per legal entity. The billing deployment notes7 state that accounting periods can only be created in Open status, and that a legal entity must be active when child records are created. Journal entries then flow from Salesforce to the ERP; Salesforce’s Revenue Cloud Billing page8 describes Salesforce acting as a sub-ledger “while synchronizing journal entries”.

At a period end the old subledger is closed and reconciled with the ERP. The new system starts with opening balances that finance has agreed. In the middle of a period you would have to split one month across two subledgers, and reconciliation gets twice as hard.

Invoice numbers need the same care. Revenue Cloud Billing has sequence policy objects (SequencePolicy, SequenceGapReconciliation); check with your partner that they cover your invoice numbering. Set the starting number so that new invoices continue the series without collisions, and check the format with your tax adviser.

What has to be ready before the first invoice run?

The deployment notes name several setup steps that are easy to miss:

1. 01

   Data pipeline

   Is enabled before Billing is enabled.

2. 02

   Order to Billing Schedule flow

   Is copied from its template and activated.

3. 03

   Legal entities and periods

   Legal entities and open accounting periods exist.

4. 04

   Configuration in order

   Billing treatment item, billing treatment, billing policy; tax treatment, tax policy; payment term item, payment term.

5. 05

   Tax and payments

   Tax engine and payment gateway are connected and tested with real addresses and amounts.

How these configuration records move from sandbox to production is covered in Revenue Cloud deployments, and the general approach in the DevOps masterclass chapter on data and configuration.

Worked example: 800 subscription customers invoiced quarterly

A machine builder sells remote monitoring and maintenance subscriptions to 800 customers and invoices them quarterly from Salesforce Billing. Machine invoices come from SAP. The company moves quoting to Revenue Cloud. All figures are assumptions.

The billing team plans the cutover for 31 March, the end of a quarter. The last invoice run in the package covers Q1. In April finance reconciles the subledger with SAP. 120 open invoices stay in the package until paid. Assets for the 800 subscriptions are migrated in March, and the first billing schedules in Revenue Cloud start on 1 April, so the first invoice run in July bills Q2. Closed invoices remain readable in the package until the CPQ and Billing licences end.

Before the cutover, finance checks one more topic: from 2027 German e-invoicing duties apply. Whether invoices should come from Revenue Cloud at all is covered in Revenue Cloud Billing or SAP and e-invoicing in Germany from 2027.

First step: finance signs the cutover checklist

Finance signs off, not the CRM team. The decisions here are accounting decisions: opening balances, period close, tax treatment, journal entries to the ERP and invoice numbering. I would set up the cutover with a written checklist that finance signs, and plan the licence cost of Revenue Cloud Billing early; how it is charged is explained in Revenue Cloud Billing costs. The overall migration order sits in CPQ to Revenue Cloud migration and in the masterclass chapter from CPQ to Revenue Cloud. The interfaces between Salesforce and SAP are part of my work in Salesforce integration.

Sources8

1. 1SalesforceBen (opens in a new tab)salesforceben.com
2. 2CPQ end-of-life page (opens in a new tab)salesforce.com
3. 3developer guide (opens in a new tab)developer.salesforce.com
4. 4Revenue Management Developer Guide (opens in a new tab)developer.salesforce.com
5. 5Billing overview (opens in a new tab)developer.salesforce.com
6. 6migration guide (opens in a new tab)help.salesforce.com
7. 7billing deployment notes (opens in a new tab)developer.salesforce.com
8. 8Revenue Cloud Billing page (opens in a new tab)salesforce.com