Hi all (not sure if this is the right channel but posting just in case!)
I have a challenge/question around Hubspot’s standard revenue recognition model.
I am working with a company that has a daily newsletter with the main revenue stream as ad placements to sponsors that could occur many times throughout the year.
The challenge is that HubSpot’s standard revenue recognition model doesn’t align with this ad-based business:
Currently, a closed won deal means that a sponsor has agreed to place ads potentially many times throughout a period. But, the sponsor makes payment for each ad before the placement date so the revenue should be recognised at that future date (and not at closed won date). However, HubSpot automatically recognises revenue at the closed won date, which creates difficulties in managing campaigns that span multiple ad runs and even quarters.
Sales reps should also receive commission based on the sponsor’s payment date and not on closed won date.
The company’s workaround is to export all data to Sheets for manual analysis and forecasting.
I had already proposed creating a custom object but Hubspot’s Enterprise plan that includes custom objects is too cost-prohitive.
What are other options? For example, I am considering these two options:
Using custom properties on individual line items (for Products related to Deals)
This would allow for revenue recognition calculations to be performed on each line item by enriching them with the necessary custom fields.
Implementing a separate tracking pipeline (ie parent deal for the agreement with sub/child deals for each ad/campaign)
This approach would break each single deal into multiple smaller deals (or sub-deals) that close on different dates, thereby more accurately tracking when revenue is booked for each ad campaign.
I also recognise that there are downstream impacts with both of these workarounds, so any thoughts are appreciated.
Hey @PatrickH429, thank you for posting in our Community.
I want to mention that I replied to this post here.
Looks like this one is a duplicate.
Kindly,
Pam