Legalities: 8 ugly contract clauses

Legal risks for automation industry companies: Add these ugly 8 contract clauses to the dirty dozen to get 20 very serious legal risks.

A while ago I wrote in this space about the dirty dozen contract clauses—that lawyer-created prose that, above all others, creates big risks for companies in the automation industry.

The dirty dozen are: Limitations on damages, ownership of work product, risk shifting for delays, incorporation by reference, unconditional warranties, performance specs, termination for convenience, notice deadline traps, home court dispute resolution, back charges, pay-when-paid, and indemnifying others for their fault. (Got those memorized? My message was that if you could avoid the worst effects of those clauses in contract negotiation then you are looking pretty good.)

In retrospect, there should have been two big, fat asterisks next to that dirty dozen list.

One of those asterisks would have said that the choice of the dozen clauses was purely arbitrary. In other words, there are plenty of other offenders that can "contractually soil" control panels and PLCs.

The second asterisk would have introduced a little perspective. Whether any of those paragraphs is truly "dirty," of course, depends on who you are. Which is to say: one company's "dirty" is another company's "being careful." (Translation: Put them in your arsenal, Mr. End User. Avoid them, Mr. Integrator.)

Which brings us to today's message: With the first of those asterisks in mind (the dozen are just a starting place), I’ll add the "ugly Eight" to the list, bringing the number of offenders to an even 20.

1. "Free from defects." Perhaps there is some construction project—somewhere—where the phrase "free from defects" is appropriate in a contract, but automation projects are not one of them. Control engineering, by its very nature, involves software—and has there ever been a piece of software without defects? A global search for the word "defect" should be standard operating procedure in automation contract scrutiny. If not removed entirely, the phrase "free from defects" can be replaced with reference to best practices or industry standards.

2. Dragnet clauses. Perhaps you have seen these. Paraphrased, they purport to state—and I am not making this up—"on the off chance there is any ambiguity about exactly what it is your company agreed to do, you and we agree that you agreed to do whatever is worse for you." Now depending on what that extra obligation is, there may be arguing room about whether that is truly a binding commitment. Still—in the slippery world of automation specs, who wants to be burdened with trying to extricate themselves from that mud hole?

3. Retainage. For every ten dollars your company is owed, we will pay it nine—holding the final dollars till the end. While these "good faith" holdbacks sometimes make sense (ensuring solvency or workmanship or payment of subcontractors), there is no reason to blindly apply them. Are there equipment purchases requiring a larger fronting of cash? Is the upstream contractor (if there is one) subject to the same retainage? Is the percentage negotiable?

4. Assurances regarding site conditions. It is common for automation contracts to require a provider to vouch for the fact that the existing conditions of a facility—and even design components contributed by others—are sufficient for purposes of the upcoming project. Requiring such assurances can be fair to an extent; for instance, it is certainly not unreasonable for one to want, at a minimum, an integrator to have visited the site. Such assurances begin to cross the line when they have the provider acting, in essence, as an "insurance policy" against unforeseen conditions.

5. Audit rights/financial condition assurances. If you are a control system integrator and you have a lump-sum contract, does the end user have the right to look at your books? (If so, why? Does that make any sense?) Conversely, if you are the end user and a provider is working under a cost-plus arrangement, is there any reason you should not have this right? While the proper approach in those situations may be relatively clear, the issue is a bit stickier when it comes to confirmation of overall financial condition. Lump sum or not, if there are signs that a provider is becoming insolvent, requiring some showing of financial health mid-project seems reasonable, most would agree. However, what degree of assurance is appropriate? The matter is negotiable.

6. Bonding. Bonds reflect a guarantee from a third party (a surety) that a company will fulfill its obligations (such as paying its subs or installing a system). Although it is common to "pass through" the cost of bonds to the end user, procuring them is the catch-22 of contracting. At the risk of overstatement, bonds arguably are needed only when the bonded party's financial stability is somehow questionable. But they can only be procured if that stability is unquestionable! To observe that contracting around bonding is challenging is to state the obvious.

7. Additional insured endorsements. Another typical contractual requirement that can leave a party in unintended knots is the additional insured endorsement. This is asking your insurance company for an endorsement that gives someone else the right to make a claim on your insurance policy. Pitfall for the technology contractor: There is an extra cost to this endorsement—or it may not be available at all (for instance, it's never available on professional liability policies). Pitfall for the end user: It's not enough to have an additional insured endorsement required by the contract. You must also have the actual endorsement in hand. Owners often neglect that second step.

8. Right to correct work. If your company arguably does not fulfill its contractual obligations, does the owner have the right to step in to perform the work? It sounds like a reasonable remedy except for the usual collection of variables: Is it just any failure to perform that triggers the right or only an important failure? What notice, if any, must be given? Following notice, does the provider have the opportunity to correct the deficiency itself? Is the warranty period extended if the fix works? Must notice be given again if the fix does not work? If the owner exercises its right to correct the work, are all of the provider's remaining obligations cancelled or terminated? Creating a fair "right to correct" provision can be complicated.

So there you have them—the ugly eight contract clauses for automation. They may not make the lawyer all-star squad, but they are there on the sidelines ready to spoil your project.

Mark Voigtmann is a lawyer with Baker & Daniels llp (Indianapolis, Chicago, Washington, DC, and Beijing). His group assists the automation and process industry in structuring projects and resolving disputes. ( Mark.Voigtmann(at)bakerd.com or 317-237-1265).

- Legalities: Beware the dirty dozen - Want a good starting place for figuring out whether to accept another company's terms and conditions? Try looking for these "dirty dozen" contract flaws. If you are an integrator or outside engineer and find any of these in a proposed agreement, your internal warning bell ought to be sounding. (If you are an end user, on the other hand, you might consider engaging in a round of high fives.)

This article collection contains several articles on how advancements in vision system designs, computing power, algorithms, optics, and communications are making machine vision more cost effective than ever before.

Programmable logic controllers (PLCs) represent the logic (decision) part of the control loop of sense, decide, and actuate. As we know, PLCs aren’t the only option for making decisions in a control loop, but they are likely why you’re here.

This article collection contains several articles on how advancements in vision system designs, computing power, algorithms, optics, and communications are making machine vision more cost effective than ever before.

Programmable logic controllers (PLCs) represent the logic (decision) part of the control loop of sense, decide, and actuate. As we know, PLCs aren’t the only option for making decisions in a control loop, but they are likely why you’re here.

This article collection contains several articles on how advancements in vision system designs, computing power, algorithms, optics, and communications are making machine vision more cost effective than ever before.

Programmable logic controllers (PLCs) represent the logic (decision) part of the control loop of sense, decide, and actuate. As we know, PLCs aren’t the only option for making decisions in a control loop, but they are likely why you’re here.