Taxonomy of contract logic

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.

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.