+1-480-241-8198
+44-7428758945
+61-1300-332-888
+91 9811400594A subscription in Salesforce starts out one way but doesn’t always stay the same. The initial sale defines product, price, quantity, and period, but that’s just the beginning of the commercial story; there are upgrades, quantity changes, and usage affecting billing and customers who renew or cancel. All those events have an impact on order management, billing schedule, invoice, payment, and accounting.
That makes Salesforce subscription management a question of ownership, not just functionality. All subscriptions are managed using the Salesforce Revenue Cloud and Revenue Management. For even deeper billing capabilities, processes related to taxation, payment, accounting, or others may be covered. Thus, there can be differences in the approach to architecture. The purpose is to know when something is done natively by Salesforce and when something else starts working.
Decide Who Owns Which Truth
Ask two questions first: What did the customer buy, and at what price and period? And what does your ledger say you owed? The first is the commercial truth. The second is financial truth. Salesforce should answer the first. Your ERP answers the second.
Billing is the handoff, and most arguments happen there.
Which Salesforce you run matters too. Salesforce Billing, the older managed package, uses its own billing data model, separate from the newer Revenue Cloud architecture. Revenue Cloud Advanced, now marketed as Agentforce Revenue Management, is the native replacement and covers quoting, billing, revenue recognition, and order management. Moving forward, it requires a migration plan.
What Runs Natively
Follow one deal through Salesforce subscription management and the native boundary gets easier to see.
You start with the rep who quotes a product with a selling model tied to it. Term-defined means that it has a set expiry date. Evergreen means that it continues until the cancellation of the customer. When the order is activated, Dynamic Revenue Orchestration triggers the fulfillment process and Salesforce creates a billing schedule for each order item depending on the sales and billing policies.
Then the invoice scheduler does its job. On each run, it picks up everything due in that window, sorts it by account and legal entity, and creates the invoices. Payments get applied against those invoices. Refunds and credit memos are handled the same way.
The subscription itself lives as an asset with history. Amendments, renewals, and cancellations apply to that asset. A mid-term upgrade is an amendment order made to it; therefore, the history is preserved, and ARR, MRR, and churn statistics are calculated along the same path. When the accounting period ends, the data processing engine runs a job for closing the period for each legal entity.
Where Native Ends
The subscription billing Salesforce handles natively stops where money moves, and tax law starts. This table shows the five places teams most often need something outside the platform, and what to put there.
| Need | What Salesforce handles | What you add |
|---|---|---|
| Tax | Tax policy and treatment per legal entity | Avalara or Vertex for the calculation |
| Payments | Applying payments, refunds, credit memos | A gateway to collect cards and bank debits |
| Ledger | GL account mapping, entity accounting periods | ERP for close, consolidation, filings |
| Usage | Consumption management and usage billing | A metering pipeline that sends aggregated usage |
| Dunning | Varies by edition | Gateway retries or a collections tool |
Swipe to see more →
Data flow is not unidirectional all the time. Orders and invoices can be sent from Salesforce to ERP, while financial information is sent from ERP to Salesforce. Payments and ledger postings come back.
Give every field one owner, or two systems will overwrite each other and finance will spend close week finding out why.
Legal Entities That Create the Most Headaches
If we had to pick one setup choice that causes the most rework, it is the legal entity. This is like an admin object with a name and an address. It actually selects the billing treatment, the tax treatment, and the accounting period for everything underneath it.
Selecting the wrong tax jurisdiction for an entity will mean that all invoices within that entity will have the wrong tax rate. Skip the entity on an order product and the system falls back to a default treatment, which may be wrong for that sale. A tax policy is required even when you have no tax engine, so nobody can skip that step.
The entity also changes how invoices get built. The invoice scheduler groups by account and legal entity, so two order products that differ only by entity land on separate invoices. Customers notice that. So does accounts receivable.
The fix is dull and effective. Decide the entity model before data load, and stamp the entity with a Flow keyed on billing country, so nobody fills in that field by hand. Two smaller traps belong here. An amendment order that is never contracted can leave future invoicing wrong. And an order activated after the scheduler runs waits for the next run.
Salesforce Billing vs Zuora
The architectural difference becomes clearer once billing moves outside Salesforce. Zuora has its own subscription model that allows synchronization of accounts, products, orders, etc., with Salesforce. The problem is that this link is created in exchange for consistent data in the implementation.
A Salesforce-centric billing system retains more of the business history within a single data model. It will be able to keep the quote, order, asset, and invoice together inside Salesforce without having to migrate them from one subscription system to another.
Zuora has real strengths. Reviewers rate its dunning, retry logic, reminders, and global payment handling highly. If collections are your biggest headache, or subscriptions also start outside your sales team, take it seriously. If the majority of business goes through reps, the native approach wins. The synchronization process is not free of charge. Every account, every product, and every amendment that you map between two systems can go off the desired course, and somebody will need to reconcile it.
Here is a quick test. Pick any invoice line and ask finance to trace it back to the quote line, the asset, and the amendment. If they can do that without switching systems, your Salesforce recurring revenue numbers will hold up in an audit.
Conclusion
If Salesforce already holds the customer’s commercial record, build on it. Add a tax engine, a payment gateway, and your ERP where money and tax rules come in, each with a named owner. Before you approve any Salesforce subscription management design, sketch quote to cash on a single page. Mark every arrow with the system that owns the data and who fixes it when a sync fails.
About Author
Akanksha is a technical content writer with 3+ years of experience creating content for IT services, software development, and Salesforce consulting companies. She specializes in SEO-focused content, technical storytelling, and marketing assets that drive visibility, engagement, and business growth.
Share this post on:
