Skip to main content
Blog
Home/

Taxonomy of contract logic

Author Dan Selman
Dan SelmanDistinguished Engineer, Smart Agreements
Summary6 min read

Dan Selman lays out the three types of contract logic you can expect to encounter when automating contract processes.

    • Contract Definition Logic
    • Contract Automation Logic
    • Contract Assembly Logic
    • Summary

    Table of contents

    Diagram: structure of sample contract between Tally Inc. and Northwind Corp.

    I spend a lot of time talking to colleagues and connections about contracts, and the types of logic we find in contracts and in contract management. In this post I aim to describe my point of view on this topic and to provide some signposts and terminology to help you navigate this complex space.

    I will introduce three types of logic we find in contracts:

    1. Contract Definition Logic

    2. Contract Automation Logic

    3. Contract Assembly Logic

    To illustrate, let’s introduce two parties to a contract, Tania and Nelly. Tania works for Tally Corp. and Nelly works for Northwind Inc. and they would like to enter into a supply agreement. Tally Corp. will be supplying parts to Northwind for assembly into a product that Northwind will be selling to consumers. In supply chain parlance and in the contract, Tally is the SUPPLIER and Northwind is the CUSTOMER.

    When two companies enter in to a relationship for the manufacture and supply of goods, both sides often have legitimate concerns about the volume of future orders and production.

    Contract Definition Logic

    The most obvious place we find logic within a contract is in the clauses that are negotiated and agreed to by the parties. There are lots of ways to represent this logic (as text, code, rules, state-machines, process diagrams, etc.), but the goal is to create a machine-readable representation of the logical semantics of the clauses themselves, and how they interact with events taking place in the real-world.

    The supply agreement contains clauses to mitigate the concerns of both the supplier and the customer:

    Clause 1: Customer will pay Supplier for performing the Manufacturing 
    Services according to the Product Prices specified in Exhibit 1.
    

    This clause is straightforward: the supplier wants to get paid for producing the goods for the customer!

    Clause 2: By the tenth day of each month, Customer shall provide Supplier 
    with a non-binding rolling forecast of Customer’s estimated purchasing 
    requirements for the next twelve (12) months.
    

    A rolling forecast clause helps the supplier to manage their manufacturing schedule and capacity. With a fixed set of manufacturing assets (factories, robots, people), the supplier needs visibility into the predicted demand across all its customers. This is a non-binding clause, but it is important to maintain a healthy business relationship.

    Clause 3: The first month of the forecast shall impose a binding 
    commitment for Customer to place purchase orders for the stated 
    quantity of Product; the remainder of the forecast shall be 
    non-binding.
    

    The first month of the rolling forecast IS binding, and is a firm commitment of the customer to purchase product from the supplier.

    Clause 4: In the event Customer purchases less than the amount stated 
    in the binding portion of a forecast, Customer shall be liable for all 
    resulting damages, including without limitation finished Products, 
    unfinished Products and raw materials. Supplier shall use reasonable 
    efforts to reschedule those materials for production and delivery in 
    subsequent months.
    

    If the customer is unable to purchase the full amount of the first month of the forecast, then they are liable to pay damages to the supplier, because those goods will have already been manufactured.

    Clause 5: Supplier shall maintain an inventory of raw materials and 
    components necessary to manufacture Products in accordance with the 
    forecasts and shall provide Customer with quarterly updates on the 
    extent of such inventory.
    

    The supplier agrees to share data with the customer to reassure them on their ability to meet the forecast.

    Clause 6: If Supplier becomes aware that it may encounter difficulty 
    meeting any forecast quantity of Products, it shall immediately notify 
    Customer in writing, providing details of the expected shortfall, causes 
    of the shortfall and proposed solution. The Parties will discuss all 
    appropriate means of resolving the problem, including establishing 
    an alternate source of supply, a back-up manufacturing facility, or 
    other measures.
    

    In the event that the supplier will have issues meeting the forecast, they will inform the customer and work together to try to find solutions.

    Clause

    Obligation / Right

    Event / When

    From

    To

    Clause 1

    Obligation to pay

    On delivery of goods

    Customer

    Supplier

    Clause 2

    Obligation to notify rolling forecast

    10th of each month

    Customer

    Supplier

    Clause 3

    Obligation to notify binding forecast

    10th of each month

    Customer

    Supplier

    Clause 4

    Right to claim damages

    Customer purchases less than binding forecast

    Supplier

    Customer

    Obligation to purchase

    End of each month

    Customer

    Supplier

    Obligation (best effort) to reschedule

    Customer purchases less than binding forecast

    Supplier

    Customer

    Clause 5

    Obligation to notify of inventory

    End of each quarter

    Supplier

    Customer

    Clause 6

    Obligation to notify of possible delivery shortfall

    Immediately

    Supplier

    Customer

    Summary of contract rights and obligations

    Contract Automation Logic

    Once Tania and Nelly sign the supply contract, they are faced with a conundrum: how to efficiently meet their obligations and track their rights? 

    Tania needs a system to track forecasts from each of her customers, track inventory, and provide inventory data to customers. In the event of a customer purchasing less than their binding forecast, she needs a means to trigger her right to claim damages and to track progress of that claim.

    Nelly needs to put in place electronic payment for goods received, create a rolling 12-month forecast of product demand, send forecasts to Tally on the 10th of each month, and send purchase orders to Tally for the amounts in the binding forecast.

    Both Tania and Nelly are faced with a digital transformation effort within their respective enterprises. They may deploy CRM or ERP systems as part of that effort, or put in place business process management, dashboards, and descriptive and predictive analytics to help them meet their obligations. Or they may employ lots of PEOPLE and arm them with spreadsheets, office space and email… Tally may deploy the latest automation technology, while Northwind uses an offshore strategy, or vice-a-versa.

    I hope you can see that there is a fundamental difference (and difference in purpose) between the contract automation logic and the contract definition logic. The contract definition logic is a negotiated and shared description of the semantics of the contract, while the contract automation logic happens privately within each of the parties to the contract. Of course, having an unambiguous (and perhaps machine-readable?) description of the contract definition logic provides a much higher-quality specification for the contract automation logic, for both parties.

    Contract Assembly Logic

    Another place we often find logic related to contracts is related to how one of the parties assembles a contract for signature by another party. Enterprises typically strive to standardize their contracts with vendors, customers, and suppliers; using a system of templates, clauses, and playbooks.

    In the case of Northwind, they consider Tally to be a tier-1 supplier, producing hard-to-source goods that are critical to the delivery of their product. As a tier-1 supplier Northwind is prepared to work closely with Tally, providing demand forecasts etc for mutual benefit. Northwind also has tier-2 and tier-3 suppliers, for smaller components that are more easily sourced and replaced. Northwind does not typically provide demand forecasts for tier 2/3 suppliers or enter into such expensive-to-manage contracts. Northwind would typically prefer to use NET-90 payment terms, but for important or long-standing suppliers has agreed to NET-60 or even (in exceptional cases) NET-30 payment terms.

    Contract assembly logic such as the above is very common once enterprises move to using contract templates to assemble the text of contracts, and may include references to standard and fallback clauses from a clause library, or negotiation rules from a playbook.

    Contract assembly logic is all about how we FORM a contract: a contract that is likely to be accepted for signature by both parties. All parties to a contract may maintain assembly logic and the art of contract negotiation is to find a mutually acceptable space where the playbooks from all the parties to the contract intersect; given the specific risk/reward profile of this contract.

    Summary

    A useful way of remembering the three types of contract logic is:

    • Contract assembly logic is used to create a contract that COULD BE SIGNED by the parties

    • Contract definition logic is the description of the rights and obligations IN THE CONTRACT

    • Contract automation logic is used by each party for POST-SIGNATURE AUTOMATION to fulfil their respective rights and obligations

    I hope that this article will help you untangle the different types of logic you are likely to encounter when working with contracts.

    Author Dan Selman
    Dan SelmanDistinguished Engineer, Smart Agreements

    Dan Selman has over 25 years experience in IT, creating software products for BEA Systems, ILOG, IBM, Docusign and more. He was a Co-founder and CTO of Clause, Inc., acquired by Docusign in June 2021.

    More posts from this author

    Related posts

    • Trending Topics: Latest from our forums (November 2024)
      Developer Trending Topics
      Author Paige Rossi
      Paige Rossi
    • Leveraging Docusign AI and Salesforce for Improved Contract Management

      Leveraging Docusign AI and Salesforce for Improved Contract Management

      Author Subbarao Pydikondala
      Subbarao Pydikondala
    Trending Topics: Latest from our forums (November 2024)
    Author Paige Rossi
    Paige Rossi
    Leveraging Docusign AI and Salesforce for Improved Contract Management

    Leveraging Docusign AI and Salesforce for Improved Contract Management

    Author Subbarao Pydikondala
    Subbarao Pydikondala

    Discover what's new with Docusign IAM or start with eSignature for free

    Explore Docusign IAMTry eSignature for Free
    Person smiling while presenting