Contractions? In a Contract?

One sure route to a stiff, starchy prose style is not to use contractions. They’re suitable in all but the most formal kinds of writing, and they help you achieve a more natural, conversational rhythm.

For some reason that I’ve since repressed, I didn’t use contractions in MSCD. So for the second edition, I’m now adding them in wherever I think appropriate. Here’s a representative example of what that amounts to:

If you need to create a defined term for a definition that is that’s unique to a particular transaction, use a term that is that’s concise yet informative. Sometimes you will not won’t be able to avoid creating a defined term that is that’s a little long-winded, such as the PLM/Whitman Excluded Asset Proceeds.

I hope you agree that the effect is salutary.

But the reason for this post is that retrofitting contractions into my prose reminded me how last year, at a conference, I heard an expert on legal writing recommend that one use contractions in contracts.

Now I’m all for contractions in insurance policies or car rental agreements. But business contracts? I think not. Contract prose is like computer code—it’s devoid of tone or life, unless it’s poorly done, in which case can be redolent of pomposity. So the idea of using contractions in business contracts to achieve a natural, conversational rhythm seems bizarre.

Any thoughts?

About the author

Ken Adams is the leading authority on how to say clearly whatever you want to say in a contract. He’s author of A Manual of Style for Contract Drafting, and he offers online and in-person training around the world. He’s also chief content officer of LegalSifter, Inc., a company that combines artificial intelligence and expertise to assist with review of contracts.

16 thoughts on “Contractions? In a Contract?”

  1. C.S. Lewis tried to do this when first printing “Mere Christianity,” after having originally delivered much of the content orally. He later thought it a mistake, and revised his book. See the first paragraph under “Preface” at

    Even in the example you provide, I think that I’d rather not have the contractions. Whatever the difference between the dynamic of writing versus speaking is, I think that introducing contractions often would add a degree of informality that detracts its authority.

  2. I think you’ve missed the mark on this one, Ken. A wise man once wrote that there is no such thing as drafting style, only efficient or less efficient drafting. Your objection to contractions in contracts is stylistic. Contractions are, by definition, more efficient than expanded text. While there might be situations in which a contraction could introduce ambiguity, I can’t think of any right now. (I certainly wouldn’t advocate using contractions where they *would* introduce ambiguity. That would be inefficient.) Trust me, as someone who got over his stylistic resistance to contractions in formal court documents, you’ll feel much better — and readers of your contracts will thank you — if you expand your horizons with contractions.

  3. I don’t like contractions in contracts either. I especially find it annoying when people screw up possessive contractions. For some reason I’ve also been noticing more often how inept drafters are with ensuring that pronouns refer to the proper antecedent.

    Here’s one I’m dealing with on a call right now that hits both problems: bad contractions and bad possessives (btw, I obviously don’t have a problem with contractions in casual writing): “[ABC] shall report the failure to [XYZ] as part of its quarterly reports.” XYZ is the party that delivers the reports, not ABC. Am I wrong or am I being pedantic? Shouldn’t that read “[ABC] shall report the failure to [XYZ] as part of the quarterly reports [XYZ] delivers pursuant to Section __”?

  4. 10803: Your beef isn’t with contractions but rather the possessive form of the pronoun “it.”

    By the way, 10803, I’d appreciate it if you’d provide me with your email address. It’s sometimes helpful for me to be able to contact commenters.


  5. In the second sentence of the revised MSCD excerpt, should you have said: “…a defined term that’s a little long-winded…” (i.e., adding “a”)? As for contractions in contracts, I’m not a proponent. While it may seem more conversational, I believe it detracts from the authoritative nature and tone of the contract.

  6. Jimmy: You found a typo! Excellent! I’ve now fixed it; that’s one that won’t make it to the second edition. I’ll be doing my best to eliminate all such glitches. Ken

  7. How would you contract “shall not”? “Shan’t”? In 21st-century America, a contract with a sentence like “Buyer shan’t do such-and-such” would indeed be bizarre.

  8. Like Eric, I have no problem using contractions in some business-to-consumer contracts but avoid using them in business-to-business contracts.

    I like to avoid the word “shall” as much as possible, so I wouldn’t face the problem raised by Ray, but substituting “won’t” for “will not” just doesn’t have the right ring to it. To me, “Buyer will not do such-and-such” sounds more proscriptive than “Buyer won’t do such-and-such.”

  9. I agree that maintaining formality in most business to business contracts is beneficial; however, not all business to business contracts are alike. I work with many contracts in the entertainment industry and anything that can make for an easier and less formal read is viewed as beneficial by my clients. As long as the contraction doesn’t create additional formality (i.e. Shan’t) or take away from the meaning, I think there is benefit to using it. The focus should be less on the technical aspect of the contraction, than the tone it brings to the document (e.g. “the style”). What is right for the large corporation doesn’t always work for the start-up record label.

  10. I have to disagree that contracts have to be “devoid of tone or life.” I remember the first time I saw (I think your) wording regarding consent “which may not be unreasonably withheld,” and I loved it.


Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.