Happy Business Starts Here

Understanding ContractEffectiveDate

Highlighted
Valued Scholar

Understanding ContractEffectiveDate

Hi everybody,

 

I cannot figure out what the effect of setting 'ContractEffectiveDate' is. For example the documentation says 'The value of the ContractEffectiveDate field is often the same as the value for the SubscriptionStartDate, but it doesn't have to be.'


As far as I can see, it is always the same as SubscriptionStartDate, so when it is not used as the SubscriptionStartDate?

 

The Subscription Start Date seems to me a much better name than contract effective date for being the begin date of the contract.

 

Any kind of explanation would be appreciated.

Regards

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Zuora Staff

Re: Understanding ContractEffectiveDate

Great question Dave the default Zuora behavior is to set the Subscription Start Date (SSD) to the specified Contract Effective Date (CED), they are different for good reasons as they have different purposes. The CED records when the associated change takes effect, the SSD is there to unambigously record when the subscription started. And while this are the same for a new subscription, things get murkier over the entire subscription lifecycle.

 

Every subscription and amendment (a change to a subscription) requires that CED be specified, so it's purpose is to tell Zuora when a subscription change (including it's creation) takes effect. And the CED is just one of three possible Zuora 'trigger' dates,, the other two are known as Service Activation Date and Customer Acceptance Date. You can configure your tenant to require the other two if you need, but these are for less common use cases usually around delayed provisioning where you pay a setup fee today but it may be a few days before the service is avaialable for you to access. So in Zuora terms you would create a one time fee for the setup fee with a trigger date of CED and then create a recurring charge for the service that has Service Activation Date specified as it's trigger date. Now when you create your subscription you specify CED and you can either specify a different, later, date for the Service Activation Date, or even leave it blank for specification at a later date when the service is actually provisioned (imagine a home security service that requires someone to go install security gear such as cameras in the customer's home, you want to take money today but you don't know for sure when one of your third party contractors is going to get access to the home to install the gear so you leave Service Activation blank while still being able to bill for the setup). And since you could add or remove such a product at any time, all amendments also require specifying CED and the other trigger dates as appropriate.

 

In contrast to all this, the SSD is set once and doesn't ever change! It's a permanent record of when the subscription started and while you could infer this date from looking through the subscription history, you don't need to since it's captured here.

 

Final note, there's a third date, Term Start Date that you left out! This too is usually initially set to the CED for a new subscription (but you can specify a different date is you'd like), but upon renewal the Term Start Date shifts out the term length, e.g. moves out 12 months for a 12 month term and in the initial term Term Start Date will equal SSD, after the initial term the Term Start is a date later than the SSD. So now you can always see both when a customer first signed up vs when their current term started.

 

Hope this helps, CED is not an intuitive concept and often causes confusion. It perhaps would have been more useful if Zuora had simply called this field, Trigger Date A, and the other two Trigger Date B and Trigger Date C. CED just records the effective start date of a billing action.

View solution in original post

2 REPLIES 2
Highlighted
Zuora Staff

Re: Understanding ContractEffectiveDate

Great question Dave the default Zuora behavior is to set the Subscription Start Date (SSD) to the specified Contract Effective Date (CED), they are different for good reasons as they have different purposes. The CED records when the associated change takes effect, the SSD is there to unambigously record when the subscription started. And while this are the same for a new subscription, things get murkier over the entire subscription lifecycle.

 

Every subscription and amendment (a change to a subscription) requires that CED be specified, so it's purpose is to tell Zuora when a subscription change (including it's creation) takes effect. And the CED is just one of three possible Zuora 'trigger' dates,, the other two are known as Service Activation Date and Customer Acceptance Date. You can configure your tenant to require the other two if you need, but these are for less common use cases usually around delayed provisioning where you pay a setup fee today but it may be a few days before the service is avaialable for you to access. So in Zuora terms you would create a one time fee for the setup fee with a trigger date of CED and then create a recurring charge for the service that has Service Activation Date specified as it's trigger date. Now when you create your subscription you specify CED and you can either specify a different, later, date for the Service Activation Date, or even leave it blank for specification at a later date when the service is actually provisioned (imagine a home security service that requires someone to go install security gear such as cameras in the customer's home, you want to take money today but you don't know for sure when one of your third party contractors is going to get access to the home to install the gear so you leave Service Activation blank while still being able to bill for the setup). And since you could add or remove such a product at any time, all amendments also require specifying CED and the other trigger dates as appropriate.

 

In contrast to all this, the SSD is set once and doesn't ever change! It's a permanent record of when the subscription started and while you could infer this date from looking through the subscription history, you don't need to since it's captured here.

 

Final note, there's a third date, Term Start Date that you left out! This too is usually initially set to the CED for a new subscription (but you can specify a different date is you'd like), but upon renewal the Term Start Date shifts out the term length, e.g. moves out 12 months for a 12 month term and in the initial term Term Start Date will equal SSD, after the initial term the Term Start is a date later than the SSD. So now you can always see both when a customer first signed up vs when their current term started.

 

Hope this helps, CED is not an intuitive concept and often causes confusion. It perhaps would have been more useful if Zuora had simply called this field, Trigger Date A, and the other two Trigger Date B and Trigger Date C. CED just records the effective start date of a billing action.

View solution in original post

Highlighted
Valued Scholar

Re: Understanding ContractEffectiveDate

Thank you Richard.

 

As always a clear detailed answer to a question. I would have given 100 kudus if it was possible.

 

Based on your explanation I think that we could see CED as activation date of a subscription. We might create a subscription as a draft and assign Term Start Date, but the billing won't start until the CED is filled in (which should always be in the future). Then SSD and CED will be the same and Term Start Date will stay as it was filled when the subscription was created as Draft. Although I think Term Start Date should always be equal to or less/newer than the CE. ( Term Start Date <= CED == SSD )

 

If I understand it correctly, this way if we want to start billing from the 10th of the next month, we should set CED to that date. Until then nothing would be billed.