Use Case

Legal contract

Automated contracts - Bill of Sale

Legal Use Case

Tag can be used for document automation in the Legal sector, to create many different kinds of documents. This use case describes how a law practice could use Tag to automate bill of sale contracts.

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 potentially 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.

  • -> Save time for more important tasks
    -> Eliminate manual data entry
    -> Reuse standard legal clauses
    -> Keep it easy

  • -> Define all data fields supporting a contract within a single data setup file
    -> Turn static legal clauses into reusable named templates
    -> Embed live data to replace traditional underlined entry areas
    -> Define true/false data fields that reflect contract scope
    -> Enter all required data using a single form
    -> Generate a clean contact with a single button click with no copy/paste errors

How does it work?

At a minimum, a bill of sale requires three groups of data.

  • Party (buyer and seller) information

  • Contract details

  • Scope of contract

How the party’s 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 can be entered in the form 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).

The scope of contract, in this use case, will also be entered using the form. It amounts to a set of checkboxes which signal that specific clauses (or other text fragments) need to be included. The contract details and scope are combined into one “contract” data setup file which will generate a single form for data entry.

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 might look 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 use case, 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 can be 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:

  1. when -> isInternational checkbox is true insert the governing-law-international template

  2. when -> isFederal checkbox is true insert the governing-law-federal template

  3. 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, installments, 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.

Summary

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.