Most large scale application projects are now provided under the Software as a Service (“SaaS”) business model, subject to a SaaS Agreement, as opposed to an End User License Agreements. In addition, most corporate Master Service Agreements (“MSA”) are basically consulting service agreements that anticipate that any software licenses will simply be appended to the project’s SOW (i.e. not addressed with the body of the MSA). These home-grown customer MSA’s sometimes address  equipment purchases, or occasional an onsite end user software license. However other customers feature their Purchase Order  (“PO”) terms in response to all purchasing activity (as opposed to an MSA for certain technology purchases), remember that PO’s are ordinarily developed with the sale of classical UCC goods in mind, anything from paperclips to large plant equipment; but PO’s are “not” specifically geared for technology products. So an MSA makes more sense than the standard Company PO as a stating place but even standard Corporate MSA is generally not very well suited for the purchase of SaaS offerings. In this paper first of 3 monthly SaaS installments, I plan to address the very important topic of SaaS “Acceptance”. Next month I will follow up with a discussion on SaaS “Warranty and Maintenance and Support “, then in two months I will discuss SaaS “IP Indemnity and Insurance”. These are very important contract concepts that are addressed quite differently within a SaaS Subscription Agreement. Collectively acceptance, warranty, and maintenance/support, IP Indemnity and Insurance protection are some of the most important aspects in any sales contract, so if you are considering a SaaS purchase you need to understand why and how each of these concepts are addressed within a SaaS context.

Acceptance:

One of the most important tasks any customer faces in  any purchase scenario is ensuring themselves that they have gotten everything that was promised during the sales cycle; i.e. they got what they ordered, it works as advertised and now it’s OK to pay the seller’s invoice. That certainly sounds easy enough but this can be abused buy buyers and sellers alike. If Acceptance is not clearly addressed, the buyer simply claims that the product or service has not been completely delivered, they withhold payment and the buyer and seller argue over the facts. I expected a little more of this, or that, and if the contract is not absolutely clear, that can represent an enormous problem for the Seller. However, if the seller delivers and quickly invoices, and buyer has not yet tested the product or service as delivered, they may find it does not work properly within their environment when it comes time to use the product or service. One of a seller’s biggest fears is that the seller just delays starting acceptance, they don’t claim anything is wrong but they just delay acceptance. Once the Buyer “Accepts” the product, the presales activity ends; the Seller can recognize the revenue; the warranty starts and the rights of the buyer and the seller fundamentally change (this is accurate even if payment for the goods have yet happened). Of all the buyer’s many rights there is none so powerful as simply just not accepting the products or service; once acceptance has occurred the buyer looses much of their leverage in the transaction. Conversely, once the seller

deliver’s they must depend upon the buyer to promptly accept and pay for the product.

In a consulting services context you might have a custom acceptance test that could stretch over several days. Often specific personnel from both side are required to attend  the test; the test is established in the initial contract or SOW, the even the test data may be stipulated, the test acceptance script may be defined, as well as the promised test results expected from the acceptance test. It sounds pretty ridged but it is actually the effort required from both parties to define acceptance so precisely is a tremendous benefit to both parties; when this process is done properly there is no gray area regarding whether acceptance has occurred. Unfortunately, the  SaaS business model by its very nature, is not a custom service, the SaaS offering utilizes the same application for all of the SaaS clients (there are no custom versions for clients). If the Seller’s SaaS cloud environment has been set up, then the new client is simply given login credentials to the Seller’s SaaS cloud platform environment and technically the buyer is capable of performing  (ramping-up) almost immediately. It is most likely the buyer’s preparation and their lack of familiarity with the SaaS application software that are the limiting factors in how long it will take the buyer to become productive. Because of this dynamic, frequently SaaS vendors will allow their customers a free trial period where the new client can test the SaaS application with their staff in advance of the placing an order, essentially performing the type of product validation you would ordinarily build into an acceptance test pan, but in advance of placing the order. This protects both parties, the buyer can confirm everything is in order before they buy, and by the time the SaaS seller receives the SaaS order they are assured that the SaaS Service will is accepted upon delivery and they can recognize the sales revenue.  Inside most company PO terms the company reserves the right to perform acceptance, often for extended lengths of time (30 days or more) and then just to preserve the buyer’s argument that they have not actually accepted the product or service they state in the PO that their payment of the seller’s invoice or the customer’s use of the product in a productive manner does not mean that they necessarily accepted the product or service; in a SaaS environment that just means they have full functionality for a month for free. Most SaaS Agreements do not actually  offer a classical acceptance term, or acceptance period, like the ones found in most End User License Agreements (“EULA”) and product sales agreements. SaaS is not a simple product being delivered, with title to the product passing to the buyer, rather it is a subscription that allows the buyer to utilize the Seller’s cloud hosting service, the licensed software, and all of the SLA support as a tool, it’s more like a short term lease of a bundled solution provided remotely over the internet.

SaaS when used properly offers buyers an ability to implement and support sophisticated applications without the need to buy elaborate computers, prepare a computer room, perform administrative computer support functions (back-ups, configuring applications etc.), but it all starts with “acceptance” and that generally happens within most SaaS Agreements day 1 when after the SaaS seller has established a separate instance of the software on their virtual cloud platform for the customer,  and that all happens without a classical acceptance right (as discussed above), as a result you need to ensure that you have adequately tested the SaaS Solution beforehand, and have appropriately broad warranty rights after acceptance has occurred. As I mentioned above, we will address SaaS warranty in next month’s SaaS post.