Login to MyACC
ACC Members

Not a Member?

The Association of Corporate Counsel (ACC) is the world's largest organization serving the professional and business interests of attorneys who practice in the legal departments of corporations, associations, nonprofits and other private-sector organizations around the globe.

Join ACC

This Wisdom of the Crowd (ACC member discussion) addresses Billing and Subscription Terms Tied to Custom Software as a Service (SaaS) Usage.  This resource was compiled from questions and responses posted on the forum for the IT, Privacy and e-Commerce Law ACC Network*.
*(Permission was received from the ACC members quoted below prior to publishing their Network Comments in this Wisdom of the Crowd resource.)
Hi. I'm looking for contract language specifying the billing and subscription term start date for a SaaS product that requires some configuration before the end-customer can start using the full features of the product. Do the SaaS vendors start the billing/subscription term on the date the end-customer can log into the SaaS product, or is it based on some other metric (e.g., 90 days after the order document is signed, after user acceptance testing, etc.)? I greatly appreciate ideas from others who offer SaaS products that are more than "plug and play". Thank you.
Wisdom of the Crowd:

Response #1: For our SaaS product, we specify the actions that we'll take to "deploy" the product upon signature of the contract, which include setting up the account, customization for the client, uploading data, etc. Then we specify in the payment schedule that billing commences upon deployment. Before that, we ran into issues where the client for whatever reason never used our SaaS product after signing the contract, and was disputing its obligation to pay. Hope this helps.1

Response #2: My company almost always starts the SaaS subscription at the time the contract is signed, even though it will probably be several months until the customer has a large number of users able to log in and get full benefits from the system. Customers understandably push back on this, but we explain that what they're paying for is much more than just a subscription to the technology. We have to immediately dedicate a team of people to support them, set up a dedicated server (this is not multi-tenant architecture), install and configure the software specifically for them, and start to dig in to the specific customer requirements, which usually aren't completely known at the start of the project. And the key customer team members will be able to log into the system almost immediately, even though the system won't be fully populated with data for several months. We've almost always been able to get the customers to agree to start the subscription at the time of contract signing.2
Response #3: Our company begins the monthly billing once the service is installed and a certain usage is met (see below). Two caveats, (1) you must be able to track the usage internally; and (2) have this clearly spelled out to your reseller/end user.
"The Service shall be deemed to have been "placed in service by the end-user" when such end-users have used the Service to track at least XXX number of units."3


Response #4: We have separate provisions for invoices vs. start of services terms. We invoice upon signing (either in full or payment installments). But service term doesn't start until actual activation of the service, and is set to expire if not activated within 12 months. However, I'd love some input regarding this as well. Thanks.4

Response #5: A couple of thoughts on this. We have an enterprise SaaS with a fairly complex implementation process (definitely not plug and play). Among the issues that we deal with are:

o When does the term start and end? o When does billing start? o What are the provider and client responsibilities around the events that trigger the above? o How do we manage the risk around a client's failure to go "live" after signing?

Our current practice is as follows:

o Start the term of the contract on or around execution, but have it run for X months after the client is "live" on the service. This way, we actually get X months of billing, not X minus the implementation cycle. The downside here is that it can make tracking the end of the term more complicated--we have to know the exact "live date" for each client in order to determine the end of the term. o Implementation fee billing begins at contract execution (50% up front and the remainder monthly during the implementation cycle). o Recurring billing begins when the client is "live." o "Live" is specifically defined and the live date is mutually agreed upon in writing. We also enumerate client responsibilities related to going live. o If the live date is delayed because the client hasn't fulfilled its responsibilities, the client must begin paying the recurring fees.

You could swap in "user acceptance" or some other milestone for "live date" in the above. I'm interested in whether others use a different milestone to begin the top of my head, possible milestones are: effective date, user acceptance date, an agreed-upon date, an actual live date, the date a user first logs in and uses the production service, the date a user first processes a meaningful transaction (however that might be defined for your service) on the service, etc.5 _________________________________________________

1Anonymous (November 2, 2016).
2Anonymous (November 2, 2016).
3Anonymous (November 2, 2016).
4Anonymous (November 2, 2016).
5Jeremy Liles, Vice President, Legal, Innovest Systems, LLC (November 4, 2016).
1 person found this helpful.
Region: United States
The information in any resource collected in this virtual library should not be construed as legal advice or legal opinion on specific facts and should not be considered representative of the views of its authors, its sponsors, and/or ACC. These resources are not intended as a definitive statement on the subject addressed. Rather, they are intended to serve as a tool providing practical advice and references for the busy in-house practitioner and other readers.

This site uses cookies to store information on your computer. Some are essential to make our site work properly; others help us improve the user experience.

By using the site, you consent to the placement of these cookies. For more information, read our cookies policy and our privacy policy.