Before we can delve into exactly how document assembly works, we first need to define a few key terms. No doubt you will have heard of some or all of these before.
- a template refers to an electronic document that has fixed content. Generally used as a basis to create new documents from, such as a template basic Will, where names and details are changed
- a document is a draft or finalized electronic document
- a variable is a piece of data within a document or template that changes from matter to matter. For example, a Plaintiff’s name is a variable, as it will be different for each different matter.
- static text is the boiler plate part of a document that never changes from matter to matter
- conditional text is “yes/no” type data, for example, a closing paragraph seeking retainer funds from a client IF a retainer has not been received. It will either appear, or not
- a logic tree refers to a decision making tree. As an attorney for example, options will be evaluated for each matter. Should this company be incorporated in Delaware? If it should, what type of Delaware corporation should it be? If not, what state should I advise my client to incorporate in?
- a library refers to a grouping of templates, usually organized by practice of law or application
- a collection or repeat refers to a single set of data that is re-used across several different persons or entities. For example, a “Plaintiff collection” would be a single set of variables but it repeats itself, collecting data on multiple Plaintiffs, until there are no more to be added
All about Document Assembly
The essence of document assembly is quite simple – identify the static, conditional and variable text contained within a given practice area or template set, so that minimal data entry and post drafting proof reading is required.
Consider a series of templates related to lending and finance. Consider the amount of times all the names of the borrowers appear throughout all documents. How often the name of the financier appears, the promissory note date, the security date, and so on. Each time one of these variable pieces of data is typed, it takes time. It also multiplies the chance of human error. The result of this is that huge amounts of time are spent drafting these documents carefully and proofreading them after they have been drafted.
Now lets consider an expert document assembly system, designed to handle those same lending and finance templates. In each and every template, a variable marker is placed which replaces the name of the borrower(s). When the document assembly system encounters that variable marker, it checks whether it has been told what the value of that variable marker is. If it knows what the value of the marker is, it inserts it because the user has already entered that data. If doesn’t know that information, it prompts the user to enter it.
The ramification of this “variable marker” approach is simple yet powerful: in a well drafted expert document assembly system, data is only ever typed once, and data re-entry is totally eliminated. Immediately in every file, across all lending and finance matters, you will only ever type a borrower’s name, or the amount of the loan ONCE. This concept applies to dates, properties, descriptions, types of loan, floating interest rates – whatever type of information and data is contained within your system, it is programmable and reproducible!
Ok, lets take this one step further, and look at the concept of a logic tree. The decision making process is possibly what defines the difference between a good end result and an average one – the amount of thought, and the depth of the logical considerations that went into creating it.
For example, a given loan is in excess of $250,000, “Lender X” requires a guaranty to be supplied personally by all directors of all borrowers. If the borrower is a natural person, Lender X requires guaranties from other persons or entities with a demonstratable net liquidity of at least 115% of the loan amount. However, “Lender Y” doesn’t require this additional security until the loan amount is in excess of $500,000. And “Lender Z” is overly cautious, they simply won’t lend until they have secured instruments and guaranties in excess of 150% of the loan amount, meaning absolutely NIL exposure.
This is a basic example of a logic tree – the rules and requirements under which each transaction is handled. A good document will cater to each of these lender idiosyncrasies, as a good attorney or paralegal will have considered all of these requirements. A good document assembly system will have this exact logic tree built into it.
As soon as a user checks the “Lender X” box, rules become active in the background, awaiting further data input. At the point where the user enters in a loan amount, the document assembly system checks the amount and compares it to the pre-defined rules (ie: $250,000 or greater loan amount). If the amount is larger than the given limit or limits, it will then require the user to enter details about guarantors and their net liquidity. If however, Lender Y was chosen, the rules would not be brought into force until such time as the loan amount was in excess of $500,000. This is the power of real document assembly – documents that do a lot of the thinking for you.
