A client asked me today if it is more usual for customer payments to be in advance or in arrears in Software-as-a-Service (SaaS) license agreements. It is a great question as this is a common point raised in licensing agreement negotiations.
The nature of a SaaS law license is that it is a subscription transaction. There is a guaranteed term with a right to some use of the technology. What makes SaaS transactions unique is the collaborative support services that support the license. Some attorneys want to treat these transactions as service engagements rather than software licensing – but true to the heart of any SaaS transaction, it is a license to use the technology. There is scope of use, restrictions on use, user seats, types of seats, IP restrictions and other common licensing terms.
This is key when chosing a pricing model as it should be priced as a software license (which requires the water to be turned on) rather than a services engagement (which requires delivery and acceptance). Regarding the guaranteed term, most SaaS licenses are either on-demand (client pays as they use) or term subscriptions (e.g., monthly or annual rates regardless of amount of use). For the on-demand licenses, payment terms are easy – they pay as they go.
For the installment payments, payment terms should be set based on the nature of the SaaS tool itself. If the payment is based on some variable component, such as a savings level acheived through the technology, it should be in arrears. If it is a structured payment schedule, it might as well be in advance.
As a point of clarification, regardless of the form in which you receive your software (traditional, locally-installed product versus SaaS), you should ALWAYS have some form of “delivery and acceptance testing”.
The mere fact that the software is provided as a service doesn’t absolve the vendor of showing that the product works as advertised prior to the first payment. In fact, there are many vendors whose quality has substantially decreased in the SaaS model (because they didn’t accurately scale their app, etc).
Additionally, just because it’s still software does not mean that it needs to be priced as software. Pricing can happen on any metric that is mutually agreeable to the parties (though unless you’re a huge customers, it’s always going to be priced the way the vendor really wants it to be priced). So there’s really no “choice” of pricing model.
Lastly, IMHO, payments should always be made based on a balance of value received and services/product delivered. In the traditional model, that’s meant pre-payment – because of the unlimited nature of use, how else would you know when to pay. Then you’d hopefully have negotiated for service level credits to be issued against any monies owed in the event of a poor service month. But in the SaaS model, there’s the opportunity for payment in arrears based on whether the service was actually delivered as promised. [You won't find many vendors who will agree to this, though, as they still want cash-in-hand with an "option" for rebates/credits/refunds based on poor performance.]
i am a management student, can u suggest some implementations of saas model in India which can be used as a reference for a study. also can you comment on the different variations of these agreements based on what things(hardware , software, etc) are put in the contract.
Hi,
Saltmarch Media is organizing its third season of Business Technology Summit 2010 which is going to take place on 11 and 12 Nov’10 in Bangalore. The summit will feature topics like Soa, Cloud Computing, Cloud Services, Cloud Application, Cloud Case Studies and more. For details log on to btsummit dot com