How would you structure a contract/subscription model using Sales Hub Pro only?

Smart CRM & Sales Hub
1

Hi HubSpot community experts! I’d love to get some opinions from other HubSpot partners/experts on a setup I’m currently working on for a client.

The client is on Sales Hub Professional and is not willing to upgrade, so we don’t have access to the Subscriptions or Contracts tools.

They still need something that behaves somewhat like a contract/subscription structure, so we’re considering building it using Deals + custom properties + workflows.

The current idea is:

  • Create a Master Contract Deal that stores the overall contract information through custom properties.
  • Based on those properties, workflows would create Child Deals for the different payment/contract components.
  • For example, the Master Deal could have properties such as:
    • Setup Amount
    • Setup Billing Date
    • Setup Separate?
    • Renewal Year 2 Amount / Due Date
    • Renewal Year 3 Amount / Due Date
    • Revenue Type
    • etc.

If the Master Deal indicates that the setup is not billed separately, for example, a workflow could create a child deal such as “First Use + Setup”, using the setup amount stored on the Master Deal.

The concern comes with monthly payments. If we use a child deal for each payment/transaction, we could potentially end up creating 11+ deals per client/contract, which feels like it could become unnecessarily complex and make reporting and pipeline management harder.

My question for other partners:
How would you approach this architecture in Sales Hub Professional without access to Subscriptions or Contracts?

Would you still use child deals for each payment, or is there a better way to model the recurring payment schedule while keeping reporting reliable?

I’d especially appreciate examples of how others have handled similar “subscription-like” structures using Deals and custom properties only.

3

Hey @CarolinaDM26,

Thanks for bringing this to the community! :waving_hand: :mirror_ball:

Great question! HubSpot did launch a native Contracts object (currently in beta), so depending on your client’s setup it may be worth exploring! The beta is currently available for All Hubs and Tiers, but "Please note that you need a Revenue Hub seat to create and manage contracts via HubSpot quotes."

Heres another thread that might be helpful as a starting point:

Tag in some folks from the community to see if they have any additional suggestions for you!

Hey @GRajput, @JasmineOejbro, @Lnorden2 – do you have anything you’d like to add here?

Thanks!!

Sam, Community Manager

4

Thanks but they also don’t count with a revenue hub seat and not willing to add one.

5

Hi @CarolinaDM26 ,

Thanks for the tag @stassey !

For your specific example, I think you may run into a few issues with your workflow when trying to target a singular deal when referencing associations. You can use things like specific field matches to ensure the correct record is grabbed for Data comparison and updates but then you must ensure each sub Deal is also provided with a unique ID # which should also somehow be correlated to the Master Deal, along with all the other sub deal IDs. It would be a tricky setup for sure.

Instead of trying to redesign an existing HubSpot Object, if it were me, I would be looking at building a Custom Object, assuming you have that as an option. Your Custom Object could be the “Master” which houses all your properties (and can be assigned default values), and the records created within that Custom Object would be your “Deals”.

Granted, HubSpot won’t pull these custom fields automatically for default reports, but most of that could be automated via workflows instead and visualized with Custom reports and Dashboards.

Hopefully I am understanding the need correctly and that all makes sense, but I’m happy to chat further if needed!

Thank you,

Lindsey Norden

HubSpot Community Champion

6

Do not model monthly invoices as child deals. That is what makes Pro setups explode.

On Sales Hub Professional without Contracts, Subscriptions, or a Revenue Hub seat, treat objects by job:

  1. One Deal = the commercial commitment (sold package, term, ARR/MRR intent). Keep it in pipeline until Closed Won, then leave it as the contract anchor (or move to a Closed Won / Renewals pipeline). Do not open 11 child deals for 11 monthly charges.
  2. Schedule lives on properties, not as deals. On the master Deal (or Company): setup_amount, setup_billed_separate, term_start, term_end, billing_cadence, next_billing_date, mrr, arr, revenue_type, renewal_y2_amount, renewal_y3_amount. Workflows can stamp next_billing_date forward and notify finance or the owner. Reporting reads those fields, not a pile of micro-deals.
  3. Child deals only for distinct commercial events. Examples that earn a second Deal: a real upsell, a mid-term expansion, or Year-2 renewal as a new opportunity when you re-negotiate. Not “October invoice” and “November invoice.”
  4. Line items / products for what was sold. Put setup and recurring SKUs on the Deal as line items (or quote line items) so amount and product mix stay auditable. Override unit price when the commercial price is special; do not invent five Deal records to express five price points.
  5. Custom Objects are usually the wrong bet on Pro. Many Pro portals do not have Custom Objects. If the client truly has no CO access, do not design the whole model around them. Stick to Deal + Company properties + workflows + reports.
  6. Finance truth can sit beside HubSpot. If they need a true invoice schedule, keep the ledger in billing/finance and sync status or next_billing_date back to the Deal. HubSpot then owns pipeline and renewal risk; finance owns cash collection.

Practical shape for your example: 1 Master Deal Closed Won with setup + term properties, 0 monthly child deals, optional Year-2 renewal Deal created ~90 days before term_end. Pipeline stays readable; ARR/MRR views stay honest.

If you share whether they bill monthly in-house or through Stripe/another billers, the “property schedule vs external invoice sync” choice gets obvious fast.

7

@CarolinaDM26 Hello hello! :sun: I’ve explored similar setups for different type of client’s and it depends a bit on how divided you need the data to be. A few options are:

  • Hijack an existing but unused object, eg. Listings or Projects, to have that work as a stand-in for a subscription with the necessary details. Rename the object in the data model and add the necessary properties, and check limitations on things like workflow triggers or list filters before committing. Easiest to flag “active” or “inactive” status and show what contract followed.
  • Storing data on the Company card under a specific property category, only works well if contract data doesn’t need to be stored to follow changes per customer or if they have different ones attached.
  • Master Deal like you proposed.

Across orgs I’ve also seen three main ways of dealing with subscription data in Hubspot:

  1. Only record the initial sale with amount = expected yearly contract value (+ services) - so Deal keeps info on what was agreed, but not the subsequent monthly revenue. The deal covers the full expected period. A different system (billing & invoicing) holds the true final data for what was agreed vs actual money earned. Reports will show spikes that correspond to when deals land rather than when money is brought in.
  2. Deal to indicate closing of contract, monthly deals to represent expected payments. These can be created by workflow from your Master Deal or hijacked object record with the same sum each month. Suitable for orgs. where the contract is month-to-month and can be exited on short notice. The initial deal only covers €€ for month 1 + setup services.
  3. Similar to point 2, but one child deal covers several months, eg. 3, 6, or 12 months. For higher confidence and lower risk of churn accounts.

In the case where you have these child deals in play, it’s best to have a separate pipeline for them. Even if you use filters they will otherwise skew data on time-to-close, pipeline waterfall etc. and is often missed by casual observers, skewing their understanding of sales.

For name, it’s best to copy the name of the parent record (which needs to be super clear, eg Company name - Time period of full contract - Service type) + add a specific to tell them apart (add the current month, or expected close date etc)

Which option to choose comes down to “what data do they want to see in HubSpot?”.

For most orgs I’ve worked with the 1st option (only sale is recorded + hijack other object if more record keeping is necessary) is the easiest to set up an manage. Note the next renewal, and a renewal deal is auto-created 11 months later for sales to step in and work with.

But, as mentioned what do they need to have in their reports? Do they need deal amount broken down per month? Or can that be handled by a custom report using a custom calculation?

For child deals, the build itself is straight-forward.

On the Master deal have a tickbox or boolean to indicate it should create child-deals, each month create new deal + add values from the Master Deal properties (Eg. total amount, map service/subscrption to a line item) and use delays & “edit record” actions to move it across the board. Make sure to have outs, eg. if the Master deal is marked as “completed/churned” it stops creating new deals, and a person can intercept and move a monthly deal to closed lost.

Let me know if you’d like further details on anything and I can try to collect and share some more concrete examples :slight_smile:

8

Hi @CarolinaDM26

I’d probably avoid creating a child Deal for every monthly payment, as that can get messy pretty quickly from both a pipeline and reporting perspective.
I’d keep the main Deal as the contract/master record and use custom properties for things like billing frequency, next billing date, next billing amount, contract term, renewal date, etc. Workflows can then handle the recurring schedule by updating those fields and creating tasks/notifications when a payment is due.
If you need to maintain a proper history of every billing event, I’d consider using a separate record structure for the billing transactions rather than turning every payment into a Deal.
That way, the Deal continues to represent the overall customer contract, while the billing activity is handled separately. It should keep the pipeline much cleaner while still giving you enough data for reporting.
The exact approach would depend on how much payment-level history and reporting the client needs.

I hope this helps you out. Please mark it as Solution Accepted and Like to help another Community member.
This post was created with the assistance of AI tools

Thanks!