Misapplying Sale-of-Goods Concepts to Services

Selling services is very different from selling stuff, so contracts for one are different from contracts for the other. Yet drafters are prone to deploying in contacts for the sale of services concepts that make sense only for selling goods.

One example of that is saying that services are being sold “as-is.” When you sell a car “as-is,” that means the buyer is welcome to check for themselves what condition the car is, but you’re not making any promises. It doesn’t make sense to apply that concept to selling services—you cannot assess the quality of services before they have been performed!

Nevertheless, it’s routine to see contacts that do exactly that. Here’s one example:

And here’s another:

Another sale-of-goods concept that doesn’t apply to sale of services is rejection. You can reject widgets: Widgetco sends you the first consigment of 1,000 widgets, and the darn things don’t comply with the specifications! You rejected them! Well, you can’t reject services, because they’re not, you know, a thing—once someone has, say, cleaned your offices, but sloppily, there’s nothing to reject!

Yet here we are:

I’ve looked in the obvious places, but I haven’t seen anyone make this point. So I guess I’m on my own again.

I’m always open to finding out that I’m mistaken, but currently I chalk this up to clueless victims of the copy-and-paste machine.

About the author

Ken Adams is the leading authority on how to say clearly whatever you want to say in a contract. He’s author of A Manual of Style for Contract Drafting, and he offers online and in-person training around the world. He’s also chief content officer of LegalSifter, Inc., a company that combines artificial intelligence and expertise to assist with review of contracts.

22 thoughts on “Misapplying Sale-of-Goods Concepts to Services”

  1. I think you probably are on your own on this one, because “AS IS” works just fine for services — as a grand-nephew put it (having heard it in pre-school), “You get what you get, and don’t get upset.”

    And services can be “rejected,” too, in the sense that the customer or client can say, “you’re not done, fix it or you’re in breach.”

    • Ken:

      I mostly agree with DC. People included these provisions by way of analogy to a known thing that is reasonably clear (and just in case there were mixed goods and services, or the services resulted in the provision of goods). And that’s good enough. It does the job because everyone knows what it means. In particular, I don’t see any problem with rejecting the services. I’ve rejected services many times, and the outcome is very predictable — the vendor domes out and fixes it.

      But I’m always open to learn from a situation where it’s actually unclear in context. Do you have one?


      • Here’s the original first sentence of my comment: “As you might imagine, I’m not inclinded to do what’s dumb and call it ‘good enough.'” Here’s a slightly more nuanced take: The “as-is” approach is glaringly at odds with what’s going on. It doesn’t make sense, so it’s a poor analogy. It follows that I don’t think it’s good enough. (More generally, I’m not in the good-enough business. My whole schtick is finding the best way to articulate stuff.)

        If the concern is deliverables or goods that are to be provided as part of performing services, then devote a sentence to expressing exactly what the concern is, rather than hoping it will be covered indirectly in a provision that on its face doesn’t make sense. And even if one were being explicit about it, I’m not sure that saying a deliverable (for example, a report) is “as-is” makes sense: a report isn’t a consumer good.

        Thus endeth the rewrite.


        As regards rejecting services, the provider has breached their obligation in some manner. That would be the standard way to express it.

        • Ken:

          But really, do you have an example? Like one where a court said that “AS-IS” didn’t disclaim the warranty of workmanlike performance? Your examples above are terrible examples.

          The first and second examples appears to be from a software-as-a-service provider. That’s just renting software that already exists. AS-IS is a reasonable way of saying you get what already exists.

          The third one doesn’t really use the mechanisms of the UCC to handle rejection. It just uses a label, and provides what seems to be an appropriate fix-it remedy.

          Some of the service agreements I’ve written avoid the AS-IS formulation, at least when it’s clear that nothing involved will ever be the sale of goods. But the problem is that almost ALL services agreements involve more than just services. If your janitor replaces the toilet paper, is that the service of cleaning the bathroom or the sale of toilet paper? I don’t want to have to figure it out, and the AS-IS formulation gives some protection at the cost of a single, fairly brief sentence. In response to a comment below you say that you didn’t have SaaS services in mind, but they are just one example where it’s really unclear whether there can be a sale of goods involved. I’d say that your “regular services” — i.e. services without even arguable sale of goods — doesn’t cover much in the actual economy. It’s why “deliverables” provisions take up so much room in many services contracts.

          If a drafter is relying ONLY on the AS-IS formulation to protect themselves, they have a lot to learn — even within the sale of goods. While that seems not to be the point that you’re making, I’d say that just throwing AS-IS at everything doesn’t make a lot of sense in a services agreement. But it does make sense to negate any background warranties you can before constructing things like service level credits, re-performance obligations, and refunds.


          • Hi again, Chris. The test for whether something is worth changing isn’t whether it has prompted litigation: that’s putting the bar way too high.

            To suggest that this kind of provision occurs outside of software-as-a-service contracts, I replaced the second example with one that relates to advisory services, for whatever that’s worth.

            Yes, the third example uses “rejection” as a label. But that label is a term of art, and an unnecessary one, so it’s not ideal. Would I mark up the other side’s draft to change it? Probably not, but that’s a different question.

            If this kind of provision is intended to cover deliverables or goods, it would be best to make that clear. It wouldn’t take a lot, and it could be written so you could include it in all contracts, including those without deliverables or goods. But I’m not sure it would make sense to treat deliverables as if they’re consumer goods.


          • Ken:

            Where do you contend the bar is? So far, I’m not seeing any evidence that anyone has actually been confused about what these provisions do. What’s the reasonable alternate reading?

            The advisory services agreement is definitely a better example.

            What would you call a demand that the service provider re-perform or otherwise correct the rendition of services to be conforming, if rejection is so polluted by its UCC use that you would not use it?

            I agree that you could write out extensive provisions about deliverables. Do you have a sense for whether your examples were on vendor paper? If so, many vendors place a very high value on brevity. Since I can’t see any actual confusion arising from these usages, I would not hold it against them that their forms prioritize brevity over a hypothetical improvement in clarity.

            On balance, I think I’m still disagreeing with you, but I’m open to the possibility of being dead wrong.


          • I figure out how to say stuff clearly. Saying that services are provided “as-is” is eye-rollingly illogical. If I were required to point to litigation showing that a given usage is bad before I could change that usage, I wouldn’t get very far.

            It’s standard to refer to breach or nocompliance in analogous contexts, so that’s what I’ll do here, instead of referring to rejection.

            I leave to others whatever compromises (sensible or otherwise) people insist on.

          • Ken:

            Referring to breach instead of rejection would ignore the typical business substance of that provision. There’s a notice that does not yet assert breach. Instead, it demands re-performance or correction. That’s why it is called rejection, not notice of breach. Your job is certainly to say things clearly, but not to change the actual substance of a widely accepted commercial mechanism — and that’s what your change would do. It’s not just a matter of semantics either: you often have obligations to report notices of breach to investors or insurers, but rejection and correction is commonplace.


  2. Nearly all Internet-based services these days work by sending software to the computer of every user-visitor. There is some combination of code the provider keeps to itself and code it sends across to web browsers. For example, your blog sends software to my computer for this comment box. So when it comes to software, the product-service distinction isn’t crisp anymore. It’s often actively error-prone.

    This isn’t a new phenomenon in the industry. But the industry’s in one of those turns of the cycle where it matters a lot.

    Agreements for software-based services frequently include rejection mechanisms. Especially when the software-service is in some sense custom to agreed spec, or even just configured for the customer by the vendor. It’s not UCC rejection. It’s contract-defined rejection. Which is how most deals for delivering installable software I’ve seen do it, too.

    • This makes sense to me. SaaS, as I understand it, is comprised of both property (software) and services (connectivity to servers, software updates, troubleshooting, etc). The software is property, and as such, can be rejected because it does not conform or perform to the customer’s specifications. The service component is subject to the same issues that I specified in my prior post. I hazard that remedies in SaaS contracts address both the property and service aspects of SaaS.

    • Regarding “as-is,” even if applying a consumer-goods concept makes sense (I’m not sure it does, but this ain’t my area), it would be helpful to be more specific, rather than just saying the services are “as-is.”

      And regarding rejection, why use a sale-of-goods term of art? There are simpler ways to express the concept. And hey, you’re Mr Get-Rid-of-“Indemnify”! :-)

  3. I’m with Ken on this one. It is impossible to provide services in “AS-IS” condition because the services do not exist until they are performed. Once performed, services can’t be given back. “AS-IS” is a property concept. Services aren’t property (the right to services is property, but I digress). The UCC does not cover service contracts.

    The solution is remarkably simple. Specify objective performance standards for the provider. You’ll need to specify what happens when the service objective is unmet. The service objective may be unmet because the service provider provided services that fell below the specified performance standard or because, notwithstanding adequate performance, the services were insufficient to meet the recipient’s service objective.

    Specify what happens next. Is the provider obligated to provide additional services? Are damages in order because you don’t want the provider to continue providing defective services? In either case, the recipient does not–and indeed cannot–return anything to the provider. Instead, the provider must provide more services or pay damages.

    I speculate that inserting “AS-IS” into service contracts is an inartful way of expressing that the provider is not guaranteeing a specific outcome and that the provider will not provide additional services in the event that the provider performs adequately but the recipient is dissatisfied with the outcome. But, taking a page from Ken’s book, if that’s the goal, then say so in the contract. Don’t appropriate a term of art from another body of law to convey the intended meaning.

    On a final note, in the colloquial context, I interpret “rejection” to mean “You didn’t do what you said you’d do. Do it again or give my money back!” But that’s not rejection. That’s informing the provider of the breach plus a demand to correct the breach.

    • > The solution is remarkably simple. Specify objective performance standards for the provider.

      Except that parties often don’t want to incur the time or expense of doing so — we contract professionals should be supporting that, in the interest of cutting costs and getting to signature sooner.

      > Don’t appropriate a term of art from another body of law to convey the intended meaning. *** But that’s not rejection. That’s informing the provider of the breach plus a demand to correct the breach.

      That comes across as the sort of lawyer-as-High-Priest-of-The-Law magic-wordery that Ken used to (correctly) rail against. If a term in a contract would be immediately and unambiguously understood by the parties (and, ideally, by judges), that’s the only thing that matters.

    • Another vote for “what Daniel says”. I negotiate and edit services contracts every day and do it exactly as Daniel says. Very often I have clients send us a PO with terms for goods that are totally inappropriate. We have some very high value contracts and goods type language in contracts for our services creates too much risk and uncertainty.

  4. Services can be non-conforming if they aren’t performed in accordance with contract standards (if stated), or (in the Government context), they are performed successfully but did not comply with contract requirements.

    One example is the Service Contract Act (SCA), which requires employers to pay prevailing wages and benefits. The contractor could provide services flawlessly, but if they did not comply with SCA, then the services were non-conforming and the non-conformance will need to be corrected (typically by paying the employees the balance of wages/benefits owed).


Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.