Jan 13

Print this Post

Structuring a contract

I’ve been a lawyer for more than ten years, and contracts have been the bread and butter of much of my working life.  I’ve written many, but as a specialist litigator I’ve argued and fought over even more.  Seeing contracts fall apart because the parties can’t understand them or use them effectively is one of the things that made me passionate about writing in plain English.

Contracts are often complicated.  Even when they’re short, they contain specific obligations for each party which need to be communicated clearly to be effective.  When you scale that up to a really large contract – say a business sale agreement which includes premises, staff, goodwill and intellectual property, all wrapped up in a complicated financing structure – then communicating each party’s rights and obligations clearly becomes even more vital.

The contract is like a road map for the parties’ relationship, and there is too much at stake if they can’t make sense of it themselves. Obviously there are lots of complicated concepts to express, and the challenge is to express them clearly.  You want the parties to be able to understand the contract themselves (that is, without needing to call their lawyer). The point isn’t to “dumb it down”, but to make it clear for the reader.  Clarity is not the same thing as over-simplicity.  Getting the right mix of specificity and clarity is a real art.

Part of the toolbox in making an agreement clear is using a plain English style.  Equally important is the visual appearance – page design and layout, font, spacing, numbering and bullet styles, size, and so on.

Then there is the structure of the contract itself, including the “signposting” to show the reader where to find the right information.  This includes a table of contents, a definitions section, schedules and annexures, and the way defined terms are identified.

There is plenty of debate about how these structural elements should be used, but ultimately people tend to have their own preferences.  Here are mine, but I’d be fascinated to hear about yours:

  • Table of contents – These tend to occur at the beginning of a contract, but they do come at the end in some firms’ precedent style.  I like them at the beginning.  If you’ve got a long contract, you’ll be needing the table of contents to find your way around, and the beginning is where you’d go to look for it.  It also helps you get an overview of what’s covered by the contract from the moment you pick the document up.
  • Definitions – People have very definite views on whether your definitions section (or “dictionary”) should be the first clause, the last clause, or a separate schedule.  The argument in favour of the first clause is that it’s easy to find and (in theory at least) you can read it first and know what all the defined terms are throughout the contract.  However, if you feel that a long list of definitions makes a contract look intimidating, you might argue in favour of removing them to a separate schedule.  My own strong preference, though, is for the definitions to be the last clause of the contract.  I think this makes the contract more accessible than having a big list of defined terms as the first thing the reader comes across, while also keeping the definitions clearly as part of the body of the contract.
  • Defined terms – How do you indicate that a particular word in a clause is a defined term?  If it’s not clear that it has a specific meaning in this particular contract, then you risk ambiguity and confusion.  The main options are capitalising all defined terms, using bold or underline, and hyperlinking in the case of electronic documents.  I like hyperlinking best – it’s clear visually, and has the bonus of making it easy to bring up the definition straight away.  For hard-copy documents, however, my preference is for bolding.  Most lawyers would expect that a capitalised word indicates that there is a special definition for it – but non-lawyers don’t follow this convention as rigidly as lawyers think they do.  Bolding gives a strong visual indication, and I think is more in keeping with the way people write in the “real” world.

There are other things to consider as well, such as where to place schedules and annexures, whether to pull out a list of principal terms, and so on.  I’ll discuss these in future posts.

On what I’ve talked about here, though – defined terms, definitions sections and tables of contents – what do you like?  I’m interested in views from non-lawyers as well as lawyers on this; they may not be the same…

Permanent link to this article: http://wordsmadeclear.com/2012/01/13/structuring-a-contract/


  1. Jo

    Definitely the defined terms. Trying to minimise them sounds like such a good idea, but it only leads to long clunky clauses trying to make it clear what the terms mean. A few bullet points in a definition of Confidential Information is clearer and more efficient even if you do need to flick a page and check what’s included. It let’s people get the sense of the contract and alerts them that the Defined Term needs to be checked if it is material to them.

    I also think recitals need to be shorter and clearer. No more management speak. Even as a lawyer I have read many contracts where a page of recitals leaves me none the wiser about whether they are buying goods, providing services or providing an indemnity.

    I think part of the problem is the business gets so bogged down in the technicalities it loses sight of the simplicity of the transaction. And lawyers are sometimes afraid to cut through and return to the simple act of buying/selling/guaranteeing.

    1. angela

      I couldn’t agree more about the recitals. Management speak adds nothing to the contractual obligations, and just makes the whole thing more confusing three years later when some poor soul is trying to interpret it and avoid a dispute.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>