A Salesperson’s Practical Guide to Contract and Legal Terms

12 min readDec 26, 2022

Halifax, Nova Scotia; photo by the author

Nearly 17 years into leading go-to-market teams, I realize SaaS salespeople lack a practical guide to the contract and legal terms they encounter. This is my attempt at creating such a guide. My goal is to educate salespeople about what these terms mean and how buyers and sellers think about them, as this should make salespeople more knowledgeable about what buyers are requesting and better equipped to discuss these requests with their counterparts on the legal team.

An important disclaimer: I’m not a lawyer, and if you’re reading this post you probably aren’t a lawyer, either. Be careful not to fool yourself into thinking you can fake it.

Okay, on to the contract and legal terms. I’ve written before about how I think about negotiating contracts. In short, it is not a zero-sum game. Nevertheless, I exaggerate some buyer and seller positions in this guide for illustrative purposes.

Affiliates

Affiliates are entities that control, are controlled by, or are under common control with a subject entity, with “control” defined as owning more than 50% of voting interests in the entity.

For example, Brightflag has entities in the United States, Ireland, and Australia, and each is an affiliate of the others.

Buyers want affiliates to be able to benefit from contracts (i.e., use the software) and sellers want affiliates to be able to participate in the delivery of services under contracts (e.g., provide customer support from multiple geographic locations).

The inclusion of affiliates in sales contracts rarely is contentious, and for most purposes they’re treated as the same entity.

Assignment

Assignment is when a party to a sales contract shifts its obligations under the contract to another entity (“assigns” it). The two most common reasons for a contract to be assigned are acquisition or corporate restructuring (including divesture).

For example, if Acme Corporation is acquired by Hooli, it may want to assign its contracts from Acme to Hooli.

Typically, buyers want to be able to assign sales contracts without restriction but don’t want sellers to be able to assign them at all. Sellers, on the other hand, want to be able to assign sales contracts to affiliates or acquirers without restriction.

The most frequent compromise is that:

Either party may assign the contract with the other party’s consent.
Consent isn’t required for a party to assign the contract to an affiliate.
Consent isn’t required for a party to assign the contract in connection with an acquisition, unless the acquisition is by a direct competitor of the other party, in which case consent still is required.

Technically, contracts can be written to be assignable in part, but this is extremely rare and should be avoided because it introduces many complexities that are risky and difficult to manage.

Confidentiality

Confidentiality is a party’s obligation to keep private certain information received from the other party.

There are two main considerations:

To which party the obligation applies: Some buyers argue they should have no obligation of confidentiality to the seller; “just don’t send us anything confidential,” they might say. This is one of the more indefensible positions I’ve encountered. Sellers should always insist on a mutual obligation to confidentiality.
What information is confidential: The easiest approach is to treat all information received from the other party as confidential, subject to common exceptions. However, it’s more common to define confidential information as that which should be understood to be confidential given its nature (the “I know it when I see it” standard).

Other considerations, such as exceptions to confidentiality and protection of confidential information, rarely are contentious.

Data protection

Privacy law is changing rapidly (one of my 2023 predictions is that the US will enact a national privacy law), and partly for this reason poorly understood by many. Here’s the rub:

The law decides whether or not it applies to your contract. For example, the relevant data protection authority will decide if the GDPR applies to your contract, not what’s written in your contract.
The law decides each party’s obligations under your contract. For example, the role of each party—data controller or data processor—is decided by the law, not by what’s written in your contract.
The law decides the classification of data processed under your contract. For example, whether certain data is “special category” data is decided by the law, not by what’s written in your contract.

Here’s Brightflag’s buyer FAQ on this topic:

We aren’t a European company. Do we need to comply with the GDPR? If you provide Brightflag with data pertaining to any European Union citizen or resident, the GDPR applies to that data. This means if any of your users, matter subjects, etc. is an EU citizen or resident, the GDPR applies. This is true even if you aren’t a European company and even if the data isn’t stored or processed in the EU. Removing references to the GDPR or removing the DPA itself does not change your legal obligations and such removal is at your risk.
Why does the DPA reference special category data? The GDPR requires that special category data, such as data relating to ethnicity, political opinions, health, sexual orientation, trade union membership, or religious or philosophical beliefs, be identified and treated with a greater degree of protection. Many employment matters (among other types of legal work) involve such data. Removing references to special category data from the DPA does not change your legal obligations and such removal is at your risk.

Governing law and venue

Each state and country has its own body of laws and regulations. The parties to a contract can agree on which body of laws and regulations will apply to their contract within reason , i.e., so long as they aren’t intending to evade applicable law. This is the governing law, for example, the State of New York. Separately, the parties can agree on venue—the courts that will have jurisdiction over disputes or lawsuits related to the contract, for example, those in New York, New York.

Each party to a contract prefers their “home” governing law and venue, e.g., the State of New York and New York, New York for Brightflag. The reason is they have more knowledge of these laws, and in the event of a dispute costs are lower if the venue is close to home.

In the United States, many parties settle on Delaware governing law and venue as a neutral ground, and in Europe, on England and London. In any event, you want to align governing law and venue with one another (e.g., you don’t want to ask the courts in Chicago to interpret and apply New York law), and you want to choose a venue whose language of operation matches the language in which you do business (e.g., you don’t want to agree on Paris, France as a venue if you’re doing business in English).

Indemnification

An indemnity is a party’s obligation to defend and compensate (“indemnify”) the other party for losses arising from what it does or doesn’t do. In addition, the indemnifying party typically is responsible for intervening in and taking over any dispute or lawsuit made against the indemnitee in relation to the indemnification.

The most common indemnities in SaaS contracts are sellers indemnifying buyers against claims their use of the software violates a third party’s IP rights, and sellers indemnifying buyers against claims their storing and processing the buyer’s data violates a third party’s IP rights.

Let’s explore the former example. Imagine a competitor of the seller initiates a lawsuit against the buyer on the basis that the buyer’s use of the software violates the competitor’s IP rights. The seller will be responsible for responding to the lawsuit on the buyer’s behalf, including all associated costs. If the seller prevails, case closed (although it will have incurred legal costs along the way). But if the competitor prevails and a court assesses damages, the seller will be responsible for paying them—not the buyer. That’s indemnification. You can understand why parties to a contract are very careful about agreeing to indemnification.

I mentioned two common indemnities. Sellers understand they need to indemnify buyers in this way, but buyers frequently push back against indemnifying sellers in the same way. Their argument goes, “We can’t control everything that’s put in your software.” To which I say: If not you, then who? Between the parties, obviously this is the buyer’s burden to bear and sellers should insist on indemnification.

As you can imagine, there’s a world of complexity I’m not getting into here, such as exceptions to these common indemnities. Together with limitation of liability and warranties, this is one area in which you really, really shouldn’t play lawyer.

Licenses

A license is a party’s right to do something with the other party’s intellectual property. There are three broad categories of licenses applicable to SaaS contracts:

Software license: The seller retains ownership of the software and related assets (like the documentation) but gives the buyer a license to use it for so long as the contract is effective.
Customer data: The buyer gives the seller a license to store and process its data for the purpose of delivering the services for so long as the contract is effective.
Customer feedback: The buyer gives the seller an irrevocable license to use any feedback it provides (e.g., feature requests). Sellers insist on receiving this license because without it they can be exposed to future IP infringement claims.

Finally, a contract may obligate the seller to effectuate a transfer of IP ownership to the buyer of professional services work product if applicable law doesn’t automatically classify it as a work for hire.

Limitation of liability

Liability is a party’s obligation to cover the other party’s losses if they breach the contract. Understandably, both buyer and seller seek to place limitations on their liability.

There are three main considerations:

Damages for which neither party is liable: Both parties, but especially sellers, want to avoid accepting liability for lost revenues, profits, and the like. Imagine an e-commerce SaaS company breaching its availability SLA and the buyer losing business while the software is down. Sellers can’t accept this because doing so would be unacceptably risky: a simple mistake could bankrupt the company.
The maximum damages for which a party is liable: A common starting point is to limit damages at up to twelve months of fees. Naturally, buyers push for a higher cap, and many sellers agree to two or even three times twelve months of fees, or to the “greater of” some multiple and a fixed number, e.g., $1 million. Both parties seek to keep the cap at or below their level of insurance coverage.
Damages for which the cap doesn’t apply: It’s long been common for sellers to agree to exclude indemnification obligations from the liability cap, i.e., agree to indemnify buyers above and beyond the cap. These days, buyers often try to move additional considerations into the “no cap” territory, including breach of confidentiality or data protection laws. Depending on what your SaaS does, and the nature of the data you store and process, this has the potential to be very risky and so is understandably treated by sellers with caution.

I’ve done my best here to explain what can quickly become a complex topic. For example, buyers may seek to define precisely what does and does not constitute a direct damage; to negotiate different liability caps for different types of breaches; to negotiate higher caps for seller breaches as compared with buyer breaches of the same nature (ha!); and so on. Together with indemnification and warranties, this is another area in which you really, really shouldn’t play lawyer.

Overdue payments

Overdue payment clauses describe what happens if the buyer fails to pay an invoice in accordance with the agreed payment terms. Generally speaking, the buyer has escalating remidies:

The seller can impose late fees if payment isn’t received by the due date (typically at least 30 days after the invoice date). Late fees are nominal and most buyers look to have them removed from contracts. I‘ve yet to see a late fee assessed in my career.
If payment still hasn’t been received a certain number of days after the due date, the seller can suspend delivery of the services until payment is received. The grace period is a point of negotiation, but 30 days is a common and reasonable length of time.
If payment still hasn’t been received a certain number of days after the grace period ends, the seller can terminate the contract for cause. Again, 30 days is common.

What does this all mean in practice? Assuming net 30 payment terms:

Late fees apply if an invoice isn’t paid within 30 days (that is, if they aren’t removed from the contract).
The seller can suspend service if an invoice isn’t paid within 60 days (30-day payment terms plus a 30-day grace period).
The seller can terminate the contract if an invoice isn’t paid within 90 days (30-day payment terms plus a 60-day grace period).

Typically, overdue payment clauses create exceptions for portions of invoices being disputed in good faith, i.e., the seller can’t impose late fees, suspend service, or terminate the contract if the buyer’s non-payment arises from a good-faith dispute of the invoice.

Payment terms

Payment terms is the number of days the buyer has to make payment on undisputed invoices before they become overdue. Net 30 is standard and means the buyer can pay up to 30 days following receipt of undisputed invoices without payment being overdue.

Naturally, buyers want “longer” payment terms: net 45, net 60, even net 90 or above. The craziest request I’ve ever encountered is “fifth third prox”, which means the buyer has until the fifth day of the third month following receipt of an undisputed invoice before payment is overdue. I still haven’t managed to figure out the origins of that Frankenstein.

I personally don’t get worked up about payment terms so long as they aren’t longer than net 60, although ultimately it depends on the seller’s rights regarding overdue payments.

Publicity

Publicity is a party’s rights to promote the existence of the contract. Sellers want to be able to do this because it helps them to grow their business. In contrast, many buyers (especially larger companies) carefully guard who can use their name and logo, and how.

Here’s my opinion on publicity clauses: they don’t matter. As a seller, even if you negotiate a publicity right, what are you going to do if the buyer later tells you they don’t want you to use their name and logo—point them to the contract? Please. You’re going to stop using their name and logo. The best way to leverage the buyer for third-party validation is to deliver great results, at which point they’ll be enthusiastic supporters. This is one respect in which the contract doesn’t matter.

Subcontracting

A subcontractor is a person not employed by, or a business not an affiliate of, a party to a contract, and subcontracting is the act of delegating some or all of a party’s obligations under a contract to a subcontractor.

Nearly all SaaS companies use subcontractors, most commonly for cloud computing. For example, Amazon Web Services is Brightflag’s cloud computing subcontractor. Likewise, buyers may engage subcontractors, e.g., to use the software on their behalf or for their benefit. For example, law firms are subcontractors of Brightflag’s customers.

Buyers prefer (and some data protection laws require) the ability to consent to the use of subcontractors. On the other hand, sellers know entering into a contract that they’ll use certain subcontractors (such as Amazon Web Services) and want this use to be pre-approved. This has become less contentious as more companies have become familiar with how SaaS works; buyer concerns typically are limited to data residency, i.e., wanting to ensure subcontractors won’t export data from their country or territory (e.g., the European Union) to any other.

Whenever a contract permits the use of a subcontractor, the party doing the subcontracting is responsible for everything the subcontractor does or doesn’t do. Think of it this way: if something goes wrong with a subcontractor, the party that did the subcontracting is on the hook to the other party, not the subcontractor itself.

Termination

A contract terminates when the underlying SaaS subscription ends and isn’t renewed, or earlier if a party so chooses.