A Clause Library is largely what the name says; a library of clauses, categorized to indicate which clause can be used where. There’s mainly three types of clauses:
- Alternate wording based on certain factors (e.g. governing law)
- Clause equivalents in other languages
- Fall-back clauses (i.e. legal pre-approved fallback clauses that can be used during negotiation)
Implementing a clause library is typically seen as a very attractive option, however it does not always make sense, pending the following factors:
- Clause usage across contract types/portfolio
- Frequency of updates
- Whether fallback clauses exist
- Whether templates in other languages additionally contain local/regional variations
The main benefits of a clause library are in a) maintaining a single clause/source which is used across multiple templates, and b) having a list of fallback clauses (reducing reliance on Legal during negotiation). Even having equivalent clauses in other languages do not often give as much benefit as initially assumed, as often the meaning of the clause is not a one to one match, due to local/regional differences required for that contract.
Although the work required to populate/create a clause library is not overly significant, it is often overlooked that it then needs to be maintained. And for this there needs to be governance put in place to review/approve changes to clauses in the library. This is to avoid the library becoming a free for all and being useless within a year of implementing. Part of implementing a Clause Library will be to set this expectation and the support the Customer creating a governance model and associated processes around clause maintenance.
From a design perspective, there are 2 things to be considered:
- Full library vs Fallback only
- Clause Metadata model (not to be confused with the contract meta-data model)
The option to only populate the clause library with fallback clauses is fairly uncommon. This is sometimes used where a client does not have their templates/content harmonized (so not a high degree of shared content), but still wanting to relieve the reliance on Legal during negotiation. In this use case, the clause library is used as just a repository of clauses which the user can access during negotiation.
The clause metadata model comes into play when the clauses need to be pulled into the template. The template does a lookup and needs a method of identifying the correct clause(s) to retrieve. For a single clause, this could be a lookup by name. But where multiple clauses should be returned, it will be easier if these are defined with respect to their metadata classification, example: Return all clauses where the ‘Jurisdiction’ = United States and ‘Effective To’ is greater than today’s date and ‘Status’ = Published.
The aim is to have the relevant fields so that even if more clauses are added to the library, the template logic does not need to be updated to start pulling back the correct clauses. As such, some analysis is required to understand where the clauses go in contracts and how they need to be retrieved/presented to the user. The OOTB clause metadata model should enable the template to retrieve the required clauses, however if there is a use case where further granularity/distinction is required, then custom fields will need to be added to the metadata model.
Define a naming convention for clauses.
It is easy to populate a clause library, but if you have 300 clauses in a library and you are asked to identify whether a new clause (e.g. for a new contract being automated) already exists in the library, you need a way to search the library without checking each unique clause. For example, if the clause title is something like “Termination - For Breach - On Them - England - alternate 2”, you can quickly scan all your termination clauses to identify which clauses to review.
It is also the name the user will see if multiple clauses are presented in a Smart template interview for selection, so from the title it should be obvious what it covers.
As part of the governance process to maintain clauses, recommend that there is not a general ‘anyone can submit a request’ process. Rather, rely instead on the reporting (once available) that indicates whether a clause was amended. You don’t want to end up flooding the library with customer specific or one-off clauses. Using a data-driven approach to highlight where clauses need to be updated is a better approach. It also enables some analysis around whether a clause is always changed in the same way, which may prompt the original clause being updated instead of creating an additional one.
Things to avoid
Do not add one-off or client specific clauses in the clause library. The benefit of the library is for shared clauses. A client specific clause has already been negotiated away from the best practice clause and as such is an exception. That contract needs to continue to be treated as an exception (unless they can be brought onto standard clauses during renewal.)
Do not just take each contract template, identify the clauses, and stick it into the library, and then move onto the next contract template. It is critical that clause content is standardized ahead of creating a clause library. If not, you will just end up with a number of one-off clauses that aren’t shared across templates - which ultimately defeats the purpose of having a clause library.