SaaS companies approach integrating subscription management data, including MRR/ARR tracking and reporting, into their CRM differently based on their GTM model (PLG, sales-led, hybrid), stage of life, product complexity, and existing business/billing systems.

If you have the luxury of being a sales-led business with a healthy ACV and fairly low order volume, you can create a robust subscription management system within Salesforce using just Rollup Helper (currently $1560/org/year for unlimited rollups – there are so many other great use cases!) and a custom Subscription object, which we did successfully at UserGems.

How we did it:
In this solution, the Opportunity Product becomes the source of truth:

  • Fee Type is either one-time or recurring, based on the Product, but can be overridden
  • Revenue Reason tells us whether the revenue is New Business, an upsell, downsell, or a renewal (if there is both a downsell and a renewal, there would be two line items)
  • Start & End Dates tell us when the ARR for this instance of the product is valid. The end date needs to be one day before the effective date of any changes to the subscription to avoid double-counting.
  • Current ARR is a formula field that looks at the Fee Type/override, the product dates, and decides whether to call the Sales Price ARR as of this moment
  • OLI Total ARR represents the total ARR on the line item, regardless of whether it’s active (aka “Current”) or not. OLI stands for “Opportunity Line Item,” another term for the Opportunity Product.

The Opportunity rolls up key ARR and OLI data that is useful for sales deal reporting:

The Opportunity then rolls up to the custom Subscription object, which can roll up currently active ARR and product data from one or multiple Opportunities, along with the complete history of all changes to ARR:

The Subscription object then rolls up to the Account:

    • We can see the Current ARR on the Account, which can be from one or multiple subscriptions. We can also roll up other product limits and entitlement data from the OLIs, for example, the number of units active shown above.

Rollup Helper Considerations: When designing the rollups, it’s helpful to use both real-time and scheduled nightly rollups at all levels. For the nightly rollups, follow the chain of rollups to reduce data delays (e.g., have the OLI > Opportunity rollup run an hour before the Opportunity > Subscription rollup, which runs an hour before the Subscription > Account rollup).

Why it made sense for us:
The custom object + Rollup Helper solution fit the bill well for our situation. We had hundreds of customers with high-value subscriptions, which they amended 1-2x per year. Customers were being quoted manually via a well-documented process using Google Doc templates and an approvals Slack channel.

The system worked well enough, even with a dozen sellers. The alternatives are almost universally more frustrating, heavy-handed, and costly, often forcing sellers through complex workflows, requiring .5-2x dedicated Sales Ops headcount, and slowing down the business’s ability to experiment with its pricing and packaging and product catalog.

What did our homegrown subscription management system get us?

  • ✅ A Finance Dashboard within Salesforce showing things like:
    • Current ARR against goal
    • Future-dated committed ARR
    • Currently Active ARR by Product
    • ARR change by month by Revenue Reason (New/Upsell/Cross-sell/Downsell/Churn)
    • NRR reporting across the install-base
    • Trailing 1-year ARR growth %
  • Current MRR & ARR data by Salesforce Account
  • Historical MRR & ARR change reporting by Salesforce Account
  • ✅ Support for multiple subscriptions per Salesforce Account (with Account-level ARR rollup)
  • ✅ A system that updates in real-time but also trued itself up nightly via scheduled jobs
  • ✅ A system that was ultimately driven by Sales + Renewal Opportunity Products, making our sales and renewal data the source of truth for MRR/ARR within Salesforce
  • ✅ High-quality data we trusted to run sales commission reporting

What didn’t it get us?

  • (1) We didn’t build the slick guided sales workflow that CPQ systems aspire to — instead, we documented the sales process in Notion/Guru and created a step-by-step approvals worksheet and order templates that sellers cloned and filled out for each deal.
  • (2) We didn’t get to building an integration with our accounting system to audit and align data or bring invoice and payment data into Salesforce.
  • (3) We didn’t integrate sales tax with quoting — but our prospects didn’t seem to mind the disclaimer that they might be invoiced sales tax not shown on the quote.