As far as tips on contract drafting go, “Don’t make mistakes. Don’t write typos.” seem to be fairly self-evident. Nevertheless, many a(n) (billable) hour is still being spent on “sanity checking”. This is in part due to a lack of standardised contract drafting and the fact that drafting in Microsoft Word is simply very error prone. Contract automation can offer some quick wins and eliminate a great deal of these potential errors.

The risks inherent in drafting errors

Without delving into jurisdictional differences in how contracts are interpreted and, by extension, how these errors would be treated by different courts, we can say that drafting errors generally fall into one of three categories:

  • Nonsensical errors. These errors cannot reasonably lead to any new or differing interpretation of what the parties intended to agree. While not entirely harmless, the only damage they do is to the reputation of the drafter. For example: “[…] the pubic authority  that awards the contract shall […]”
  • Errors that open up the possibility of an interpretation battle. Errors of this category give an unintended new meaning in such a way that it could be argued that there was no error at all and they therefore present a risk of protracted litigation. Examples typically include incorrectly written sums, such as adding an extra “0” to an employee’s salary or removing a “0” from the purchase price in an asset sale agreement.
  • Crucial errors. These are errors that, at face value, do not even seem like errors and are therefore much harder to catch. Any judge presiding over a contractual interpretation with this kind of error would likely consider the error to be the intended meaning. Examples include: forgetting the word “not”, writing a defined term without an initial capital[1], etc.

Security against drafting errors

In short, contract automation aims to have lawyers clean up or create their template material once, and then optimally reuse that content for future contracts. The idea is not to limit the amount of interaction the lawyer can have with the document, but the kind of interaction. For example, instead of taking an existing confidentiality clause and redrafting it in Microsoft Word to fit the contract being created, lawyers would instead define a number of confidentiality clauses up front (e.g.: a long and mutual clause, a short and mutual clause, a long and unilateral clause, and a short and unilateral clause). The lawyer does not have to choose the actual wording of the clause, which takes time and is risk-prone. He or she merely has to choose which variant is applicable.

While this can work under traditional contract automation software, these kinds of systems are generally not geared towards a large degree of variability. With every eventuality taken into account in a top-down system such as this, maintenance of the template document becomes that much more of a chore.

ClauseBase chooses to take a bottom-up approach with Clause9. Our software starts from the individual clauses that make up a contract and, with some minor modifications, turns them into intelligent building blocks. These building blocks are stored centrally in a clause library so that the lawyer’s task is to (1) pick the right clause from an organisation’s clause library and (2) engage with the intelligence embedded into this clause to present the correct legal nuance. The creation of a contract in this way still requires significant legal skills, but the boring and risk-prone drafting in Microsoft Word is kept to a minimum.  

Sources

[1] See for example: https://www.economist.com/finance-and-economics/2019/02/02/conflicts-in-the-credit-derivatives-market-threaten-to-undermine-it.

‍

‍