Autorenewal in SAAS, Payments/Commerce and Data Agreements
In many customer-vendor SAAS negotiations, the vendor will usually ask for autorenewal at the end of the initial term, and the customer will often try to fight it.
On the SAAS vendor side, the thinking behind autorenewals is that autorenewal is a core principle of SAAS business models (e.g., autorenewals are a mechanism for increasing the expected value of future SAAS revenue). On the SAAS customer side, the fear is that an auto-renewal clause has the practical effect of locking the customer into sequential self-renewing terms even when the customer does not like the SAAS service anymore (e.g., customers are concerned about missing the non-renewal deadline).
Sophisticated customers and experienced SAAS vendors know, however, that this binary view of the world is not an optimal general rule. In fact, the interests of customers and vendors in the SAAS, Payments/Commerce and Data Analytics spaces are aligned in many cases with respect to auto-renewing agreements.
This article outlines a number of reasons why SAAS customers may want autorenewal clauses in SAAS vendor agreements, and suggests a few strategies for negotiating win-win outcomes for customers and vendors in auto-renewing SAAS, Payments and Data agreements.
1. PCI DSS Compliance Concerns
If you are a customer and your vendor is providing PCI-compliant Payment-related services, think twice before you fight autorenewal. You do not want to find yourself in a situation where the inbound agreement expired automatically, both parties missed the renewal date, and then you find yourself noncompliant with the PCI DSS standard. PCI DSS requires an active agreement between you and your vendors that provide PCI-compliant services on your behalf (e.g., payment processors, billing vendors, omnichannel service providers, mobile wallet holders, etc.).
If the customer’s agreement with the PCI-compliant vendor expires, the customer will either be out of PCI compliance (actually both parties will be out of PCI compliance), or the vendor must stop providing services for you immediately upon expiration. Neither option is good for the customer: (i) if PCI compliance ends, a series of unpleasant consequences could follow quickly, potentially including significant fines from the Card Networks and suspension from future processing of VISA, MasterCard, American Express and Discover cards; (ii) alternatively, if the vendor realizes that the agreement expired, the vendor may immediately stop providing PCI-compliant services on behalf of the merchant because the end-consumer Cardholder consent chain has been severed, in which case the customer’s corresponding business may grind to a stop unexpectedly.
The message in Commerce/Omnichannel Agreements: as a Commerce customer, think twice before fighting autorenewal clauses in your agreements with your Payments and Omnichannel Commerce vendors. It may have significant unintended consequences, and other solutions exist to address your concerns around perpetually self-renewing agreements.
2. Data Agreements
In agreements in which a vendor processes personally-identifiable consumer data (usually denoted “personally identifiable information” or “PII” in the US, or “personal data” in Europe and in other non-US jurisdictions), the scope of end-consumer consent is critical to the relationship between the vendor and consumer. In agreements such as Data-As-A-Service, Loyalty agreements, Payment Processing agreements, Omnichannel and other Payments-related agreements, CRM, ERP and other SAAS and cloud-based agreements where end consumer data is exchanged, processed or stored, issues of end consumer consent inherently arise either as first-level issues for the consumer-facing company, or as second-level issues for vendors.
In the US for example, US states and Federal statutes have strengthened privacy protection for consumers over the past 15 years, and one manifestation of this trend has been a transition from opt-out privacy frameworks to opt-in principles. In general, a vendor may only handle data for a consumer-facing company (a B2C company) if the scope of the consent obtained by the B2C company is sufficiently broad to encompass the activities of the vendor. In the Federal domain, legislative areas like Banking, HIPAA and Government benefits unambiguously protect consumer information without the need for consumers to affirmatively opt in. At the State level, States like Alaska, California, Connecticut and Illinois have adopted opt-in privacy principles. Additionally, state laws may reach directly through the consumer-facing company and regulate the conduct of the data vendors themselves even when removed from the end consumer (see, e.g., Section 1798.82(b) of the California Civil Code).
In Europe, the Data Protection Directive 95/46/EC (DPD) and related EC/EU publications), adopted by the EU Parliament in 1995 (“DPD”) and the DPD Article 7(a) provides that personal data may be processed only if “the data subject has unambiguously given his consent…” The DPD does not explicitly require an opt-in consent approach for consumers, but B2C companies should err on that side and obtain affirmative opt-in consent from consumers. The General Data Protection Regulation (GDPR) framework, approved by the EU Parliament in 2016 and scheduled to become effective on May 25, 2018 (“GDPR”), strongly suggests affirmative consent with an opt-in approach (See Article 6 of GDPR and Article 7 for guidelines on the types of consent required).
The requirements for data privacy consent from end consumers are global concepts and occur in virtually all jurisdictions. See also the consumer consent requirements under Canadian law (e.g., Section 4.3.7 of Principle 3 of the Personal Information Protection and Electronic Documents Act of 2000 (PIPEDA)) and under Japanese privacy laws (e.g., Article 15 of the Act on the Protection of Personal Information (APPI) administered by the Personal Information Protection Commission, Japan (June 2017)).
So as a general rule, a data vendor cannot process personal data from end consumers unless the vendor has the requisite consumer consents, and because the vendor does not usually have a direct nexus with the end consumers, the consent is necessarily flowing through the consumer-facing B2C company. This means that if a vendor agreement between a B2C company and a vendor expires, and the chain of consent for personal data is broken, either (a) the vendor is not aware of the loss of consent, which means that the B2C company would be immediately in breach of applicable Privacy laws, or (b) the vendor realizes that consent to process personal data has ended, and the vendor stops its activities under the agreement, in which case the B2C company’s business will be correspondingly impacted, likely materially and unexpectedly.
As a side note, remember to address carefully the flow of consent in vendor agreements where personal data is flowing between a B2C company and a data vendor. Doing that properly will help the customer entity put in place more sophisticated business contingency planning that could address such end-of-consent situations as well.
As another side note, it is important to note that if a data agreement expires and the vendor continues to process personal data without either party realizing that end consumer consent has ended, the repercussions could be significant not just for the B2C company, but also for the vendor. In the US, both Federal and State laws impose clear obligations on B2C companies to ensure contractually that data transferred to other entities continues to be handled in accordance with applicable laws and regulations, and data vendors themselves may come under the direct purview of laws (see for example Section 1798.82(b) of the California Civil Code). In Europe, while the DPD does not currently address data processors directly, GDPR will affirmatively require regulatory compliance by both data processors and data controllers (see, e.g., Articles 5.2, 28 and 30 of GDPR). Additionally, the contract between the corporate customer and the data vendor will likely also include indemnification and remedies for one or both parties, and typical contractual provisions do not contemplate the case where consent for PII processing ends inadvertently through expiration of the agreement, so the liability and remedies between the parties may be complex and unpredictable, if they survive at all.
The message in Data Agreements: as a B2C company engaging vendors to help you with the collection, processing and/or storage of personal data, think carefully before you delete autorenewal clauses in your agreements with your data vendors. The inadvertent severance of the consent chain that permits your vendors to process PII for your end consumers could have material negative implications for both you and your vendors. This is another case where the interests of both customers and vendors are aligned in ensuring that data agreements do not expire inadvertently.
3. Strategies for Negotiating Autorenewals in SAAS, Commerce/Payments and Data Agreements
It is normal for a customer entity to generally favor fixed-term vendor agreements that require affirmative renewal by the parties (except that you should reconsider that view for critical Commerce and Data agreements if you are a B2C company). It is also normal for a vendor to generally prefer autorenewals, particularly in SMB market segments where the vendor seeks to deploy an agreement in high volume and with minimal changes. But when these two views conflict in negotiations, it should not result in endless negotiations, recurring redlining, and repeated phone calls between Business and Legal teams. Here are some strategies that could get you to a solution quicker in agreement negotiations and could improve the outcome for both the customer and the vendor:
a. Accept an autorenewal clause and track it. Some sophisticated enterprises are very good at tracking critical dates in commercial relationships, such as legal agreement renewal dates. If you are a company with strong logistical processes and a good contracts management platform, you may have the confidence to accept an autorenewal clause with the expectation that you will be able to act within the applicable window and prevent autorenewal if you decide to terminate the relationship.In this case, the customer may trade autorenewal for other important levers in the negotiation.
I admire this confidence when I see it, but here is a caveat: automatic reminders in contract management systems are only as good as the data that is input into the platform, and requires ongoing updates to remain accurate. As both customers and vendors move deeper into SAAS and automation, as the internal teams become leaner, and as data management is outsourced to different geographies, even the most sophisticated organizations can miss deadlines or get false positives. Remember that contract amendments, new subsidiaries being added to agreements, amended and restated documents, corporate reorganizations, and other similar events can introduce discrepancies between the dates being tracked by contract management systems and the actual contracts. Do not rely on your organization catching critical deadlines unless you are indeed confident that you will catch them, and even then, it is not a bad idea to introduce contingency plans in your agreements.
b. Compromise on renewal terms that are shorter than annual intervals. One way to bridge the autorenewal gap between a customer and a vendor is to agree on a shorter autorenewal term. For example, if the vendor is insisting on an annual renewal term, the customer may propose six months as a compromise. If the resource deployment required by a vendor to maintain a SAAS platform is significant, or if the transitional phase at the end of the relationship is more complicated, then longer renewal terms are a more equitable compromise (e.g., 6+ months). If this is a turn-key platform operating through standard APIs, then quarterly auto-renewing terms may be appropriate. There are cases where shortening the renewal term does not make sense, but in general, think of the duration of the renewal terms as another negation lever that both parties can pull.
c. Adopt a dynamic term approach in complex agreements with high regulatory stakes. For example, you could make the agreement auto-renewing, with the renewal term being split in two phases.The first phase could be an autorenewal quarter term (3 months starting on the autorenewal date), and during this term either party may terminate the agreement for convenience with 60- or 90-day notice. If neither party terminates during that first phase renewal quarter, the agreement becomes non-terminable for the subsequent nine months. This approach can balance a customer’s fear that an agreement may expire inadvertently, against the customer’s desire to maintain additional flexibility in terminating the agreement, and against the vendor’s desire for predictable revenue and extended automatic renewal terms.
d. Trade renewal for termination for convenience. For example, the Business and Legal teams negotiating on behalf of one or both of the parties may not have sufficient authority to compromise on their default renewal position.In that case, the customer may accept an autorenewal provision coupled with the right to terminate the agreement for convenience during the renewal term. If the vendor must absolutely have an autorenewal clause in the agreement, and if the customer is absolutely not going to accept that, I am sometimes successful in bridging the gap by introducing a termination for convenience clause that only becomes effective after the initial term. The termination for convenience notice period can be increased or decreased, depending on the various applicable factors and circumstances. I typically start this discussion at 90 days, from where it can go up if the vendor needs more predictability, or down if the customer has significant leverage and wants maximum flexibility.
e. Approach the renewal concept from the pricing perspective: if the customer and vendor are at a standstill over the renewal issue, which happens in about 20% of my more complex Enterprise-level B2B negotiations, consider proposing a solution in which the agreement can be terminated for convenience by the customer with a termination fee. This could give the customer the confidence that it can terminate the agreement at any time after the initial term, while giving the vendor a degree of assurance in terms of financial return.
I sometimes see some misconceptions among Sales or Legal teams regarding the GAAP treatment of termination for convenience clauses. In fact, termination for convenience clauses should not have any material impact under most revenue recognition regimes around the world: (a) with respect to bookings, a simple termination for convenience right does not change the ability of a vendor to book revenue as long as the termination is a pure contingency with no reasonable expectation of actual occurrence; and (b) with respect to revenue recognition, a vendor cannot recognize recurring revenue using a recurring revenue approach until the vendor delivers the services, even if the customer prepays fees, so if a customer exercises a termination for convenience right, that would simultaneously both terminate the agreement and also end the vendor’s ability to recognize further revenue. Therefore, adding a termination for convenience clause to a contract should have no material impact by itself on either bookings or revenue recognition.
How should the termination fee be established? We can find a wide range of solutions here – once the parties are able to move away from the irreconcilable issue of agreement renewal, creativity and economic analysis usually start flowing freely in both directions. A logical starting point for the vendor is to ask for a fee equal to the SAAS fees that would have been collected for the rest of the renewal term, post-termination. The customer could counter that that since there are no vendor services post-termination, any termination fee is a bonus and windfall to the vendor. A good starting compromise to skip this initial bargaining step could therefore be that the customer would pay 50% of the fees remaining post-termination for the then-effective renewal term. From there, the termination fee could increase or decrease depending on relative negotiation leverage and other relevant factors. This negotiation can become more complicated in agreements that do not cover a pure SAAS model, such as Payment Processing agreements or ISO referral agreements that include a transactional revenue component, but a mutually-acceptable solution can always be found if both parties are rational.
In conclusion, trading a termination for convenience right for a termination fee could be another effective mechanism for bridging the autorenewal gap between customers and vendors in SAAS, Payments or Data agreements.
Other negotiation techniques could be deployed if the circumstances differ or if the approaches suggested above fail. In general, an autorenewal clause is fundamentally a mechanism for risk allocation, and it can be addressed with any solution or combination of solutions that can reduce risk and/or increase the expected economic value for each party.
I hope this helps you save some time and improve your business negotiations in your next SAAS, Payments/Commerce or Data agreement, whether you are on the customer or on the vendor side. Best of luck!
If you would like to discuss any aspect of this article please do not hesitate to contact us at Hello@svskyline.com.
The opinions in this article are limited to the scope of this article, and do not necessarily reflect our opinions in general, or the opinions of any of our clients or business affiliates. This information is provided for informational purposes, is not guaranteed to be accurate or up to date, and does not constitute legal advice.
