Dynamic legal contract
Background
Creating a contract can be a repetitive task, where clauses from earlier contracts are considered for reuse and copied to the new contract if applicable. Relying on human memory, to find all potential relevant clauses, can be challenging.
As with other document types, there is also a risk of copy/paste errors as party information and other contract details are inserted in the correct location.
This use case demonstrates how to automate a simple bill of sale contract. All files are available as a reusable sample in Tag (Scribe sample: "contract-product"). This sample runs in the Scribe app and can easily be adapted to meet other requirements.
Goals
- Save time for more important tasks
- Eliminate manual data entry
- Reuse standard legal clauses
- Keep it easy
How does it work
At a minimum, a bill of sale requires three groups of data.
- Parties information
- Contract details
- Scope of contract
How the parties information is handled depends on your legal practice. Are the parties known to you and, if so, can their identifying information be pulled from another tool or system (e.g., using CSV files)? If the parties are not known to you, this information can be entered manually when the contract is created.
Contract details are most likely entered manually when the contract is created. You can use text fields to collect names and short phrases, while text areas make more sense for longer descriptions (e.g., what goods are being sold). Specifying this distinction for the form is simple in Tag, and is done within the data setup screen.
The scope of contract, in this use case, will be entered manually. It amounts to a set of checkboxes which signal that specific clauses (or other text fragments) need to be included. Since contract details and scope are all entered manually, we can combine both into one “contract” data setup file.
The contract data setup file for the contract-product sample looks like this.
When writing smart content, you often start with one template that contains all the static content you want to automate (e.g., sample bill of sale). This can be done by importing a word processing file, or copying and pasting from another system.
Next you replace buyer and seller information by inserting parties data. For many contracts, this has the added benefit of making the final contract more readable. All of the underlined spaces, which someone is expected to fill in manually, are replaced by logic bubbles. No underlines will appear in the final document.
For example, if the starting paragraph looks like this in a static contract.
In dynamic contracts, the same introduction would look like this.
Legal contracts are a great fit for content automation, in part because so many clauses are conditional. In this sample, clauses are associated with true/false data values (scope). For example, if the standardWarranty field is true, the contract would include a clause something like "The Seller warrants that the Goods are free of any liens and encumbrances and that the Seller is the legal owner of the Goods".
More complicated logic may involve choosing between more than one clause. This is handled by choose/when instructions. A choose/when inserts the first "when" that is true, and if none are true inserts the "otherwise" if one exists. This could look something like the following:
- when -> isInternational checkbox is true insert the governing-law-international template
- when -> isFederal checkbox is true insert the governing-law-federal template
- otherwise -> insert the governing-law-state template
Dynamic clause content is also possible. Clauses do not have to contain static text, but instead can also include logic and data. This makes sense for payment schedules, which can be defined many ways (e.g., lump sum, in installments, in installments with interest). Logic within the payment schedule clause would insert party names where appropriate, while describing the flow of funds over time.
Another consideration is reuse of clauses between multiple contract types. For example, a bill of sale may require clauses that are also used in subcontracting contracts. Tag makes sharing clauses between contracts easy.
The Scribe app creates easy-to-use forms automatically to match your data setup files. Dates are entered using date pickers, you can tab from one field to the next, and dropdown lists can be used if you have a list of items to choose from.
The form for the bill of sale sample is shown below with the Scope section expanded.
Once all the data is entered, it is time to generate.
Generation usually creates a new word processing document and saves it to a file, however it can also save as plain text or other formats. The generated content for the bill of sale sample is shown below.
The generate page also lets you export data. This allows you to create one CSV file that merges data from all similar contracts. This could be useful when looking for patterns of client needs, or the frequency of use for particular clauses. These kinds of insights can signal where it is worth investing more in content automation.
Benefits
Time savings will increase along with the complexity of each contract. Using forms for data entry eliminates many manual steps involved in copy/paste merging of data from multiple sources. There is also less need to search through old contracts for useful clauses, or repeatedly draft similar clauses from scratch.
The elimination of manual data entry is a significant benefit. The final contract will look much cleaner (no more long underlines), and you have the option to analyze the data gathered.
Reuse of useful clauses is also a big benefit. Once you have given a name to each clause, you only need to select them from a list to use them.
The end result should be very easy to use. Once the templates have been written, the time spent on each contract is primarily data entry. Entering data will only take a few minutes, at which point the parties are ready to sign and you can move on to the next job.
There may also be practice-level benefits if multiple lawyers use a standardized process. You can share standard fragments and build a shared clause bank. This would improve consistency in contracts between lawyers, and facilitate knowledge transfer for new ones. A rich and deep clause bank could also provide a competitive advantage over law practices that remain stalled using static, paper-based contracts.
All files described in this use case are available as a sample in Tag that you can download. If you have any questions about how to reuse the "contract-product" sample, please contact us.
