Summary. When an ERP, CRM, or other enterprise software project runs years late and millions over budget, the customer and the integrator usually end up arguing about the same short list of questions: which body of law governs, whether the breach was material, what the warranties and remedy limits actually say, and whether a fraud claim can escape the liability cap. This article explains each question in plain English and then gives the practitioner detail, using the cases that shaped the field, including Advent Systems v. Unisys, State of Indiana v. IBM, Metropolitan Life v. Noble Lowndes, the Hertz v. Accenture rulings, and the economic loss cases from Michigan, Wisconsin, California, and Florida. It walks through the anatomy of a failed project from the sales pitch to the termination letter and shows which documents at each stage become evidence. It covers the UCC predominant purpose test, express and implied warranties and their disclaimers, failure of essential purpose, the direct-versus-consequential damages fight over re-implementation costs, gross negligence and willful misconduct carve-outs, integration and non-reliance clauses, and the rarely successful theory of IT professional negligence. It also addresses exit issues, including transition assistance, source code escrow, data return, and ownership of custom code, along with damages proof, project records, experts, limitations periods, and arbitration. An extended worked example, common mistakes, an FAQ, and practical takeaways for both customers and vendors close the article.

The chief financial officer of Bramblewood Foods, a regional food distributor with 1,400 employees, is standing in a warehouse in Ohio at 6:00 a.m. watching forklifts sit idle. The new enterprise resource planning system went live on Saturday. By Monday it cannot release pick tickets for orders that span two warehouses, the pricing engine is applying last year's customer contracts, and the finance team is closing the books by exporting spreadsheets from the old system, which was supposed to be switched off. The integrator, Northgate Systems Partners, has billed $11.2 million against an original estimate of $4.8 million. Its project manager says the problems are "data issues on the client side" and that a "stabilization phase" will need another nine months and another $3 million on time-and-materials rates.

The CFO wants to know three things. Can we stop paying? Can we fire them? Can we get our money back? The answers depend less on how bad the software is than on what the contract says, which body of law governs it, what Bramblewood's own people wrote in emails and tickets over the last two years, and whether anyone at Northgate said something before signing that was not true.

This article explains how those disputes are actually fought and decided. A companion guide, Pursuing or Defending a Failed Technology Project Claim: A Practical Guide, gives the step-by-step litigation playbook for both sides; Troubled Technology Project Checklist: A Practical Checklist tracks the warning signs from the first missed milestone to termination; and Technology Project Dispute Toolkit: Notice of Breach Letters, Cure Plans, and Project Record Protocols supplies the letters, plans, and protocols.

The short answer

  • Most failed-implementation cases are contract cases. The customer's best claim is usually breach of the master agreement and statement of work (SOW): missed milestones, deliverables that fail acceptance criteria, or a failure to meet stated performance standards. Whether the breach is "material" decides whether the customer may terminate, and courts apply the contract's own materiality standard when it has one, as the Indiana Supreme Court did in State v. International Business Machines Corp., 51 N.E.3d 150 (Ind. 2016).
  • Which law applies matters more than people expect. If the deal is predominantly a sale of software (goods), UCC Article 2 supplies implied warranties, a four-year limitations period, revocation of acceptance, and the "failure of essential purpose" doctrine. If it is predominantly services, common law governs. Courts split on how to classify integration deals; compare Advent Systems Ltd. v. Unisys Corp., 925 F.2d 670 (3d Cir. 1991), with Pearl Investments, LLC v. Standard I/O, Inc., 257 F. Supp. 2d 326 (D. Me. 2003).
  • The limitation-of-liability clause sets the stakes. A cap at fees paid in the prior twelve months and an exclusion of "lost profits, lost savings, and consequential damages" can turn a $20 million loss into a $2 million claim. The real fights are over carve-outs (gross negligence, willful misconduct, fraud) and over whether the cost of fixing or replacing the system is a direct damage that survives the exclusion.
  • "Willful misconduct" is narrower than customers hope. In Metropolitan Life Insurance Co. v. Noble Lowndes International, Inc., 84 N.Y.2d 430 (1994), a software developer's deliberate decision to stop performing an unprofitable contract was not "willful misconduct" that lifted the cap.
  • Fraud claims are the customer's way around the cap, and they face four gates: puffery, particularity under Fed. R. Civ. P. 9(b), the economic loss rule or "duplicative of contract" doctrine, and integration or non-reliance clauses. The Hertz v. Accenture rulings show all four in action.
  • Professional negligence against IT consultants rarely works. Most courts decline to treat programmers and integrators as "professionals" with a tort duty independent of the contract.
  • Exit terms decide leverage. Transition assistance, data return, source code access, and ownership of custom code often matter more in the first month after termination than any damages theory.
  • The records decide the case. Jira tickets, Slack threads, steering committee minutes, change requests, and status reports are the trial evidence. Both sides should preserve them from the first serious dispute.

The anatomy of a failed project, and the documents each stage leaves behind

Enterprise software projects tend to fail in recognizable ways, and each stage produces the documents that will later be exhibits. A lawyer who understands the stages can find the evidence faster and can tell a client early whether its story holds up.

Stage What happens Documents that become evidence Typical legal issue
Sales and proposal The vendor pitches capability, team, methodology, and timeline RFP, response, demo scripts, slide decks, reference calls, emails Fraudulent inducement, express warranty, puffery
Contracting MSA, SOW, pricing, assumptions, change control Signed agreements, redlines, assumption lists, negotiation emails Integration clause, non-reliance, order of precedence, caps
Discovery or "blueprint" phase The integrator documents business processes and designs the solution Blueprint, fit-gap analysis, design documents Scope disputes, whether the design was competent
Build and configuration Configuration, custom development, interfaces, data conversion Jira or similar tickets, code repositories, sprint reports, Slack Quality, staffing, missed milestones
Testing Unit, integration, user acceptance testing (UAT) Test plans, defect logs, sign-offs, acceptance certificates Acceptance, deemed acceptance, waiver
Go-live and stabilization Cutover, hypercare, defect triage Cutover plans, incident tickets, business impact reports Material breach, consequential damages
Dispute and exit Notices, cure periods, termination, transition Breach notices, cure plans, termination letters, transition plans Cure, termination for cause vs. convenience, data return

The failure patterns repeat. The vendor sells an "out-of-the-box" fit and the blueprint reveals that the customer's pricing rules require heavy customization. The customer's subject-matter experts are pulled back to their day jobs and stop attending design sessions. The integrator rotates its senior architects off the account after the sale and staffs the build with junior developers. Data conversion is assumed to be "the client's responsibility" in an assumptions schedule nobody read. Change requests pile up unsigned, so the parties later disagree about whether the scope changed. Testing is compressed to hold a go-live date. Each pattern points to a different defendant, or to the customer itself.

That last point deserves emphasis. Many failed projects have two authors. Customers that withhold decisions, change requirements mid-build, or fail to supply clean data hand the vendor a causation and prevention defense, and a counterclaim for unpaid invoices. The best plaintiffs' lawyers test their own client's conduct first.

For how the MSA and SOW should divide these risks in the first place, see Negotiating a Master Services Agreement and Statement of Work. For projects run on agile methods, where the scope is deliberately unfixed, see MC Law's article on legal issues in agile software development.

Part I: Which law governs? The UCC and the predominant purpose test

Why it matters

Article 2 of the Uniform Commercial Code governs "transactions in goods" (Cal. Com. Code § 2102, mirroring UCC § 2-102), and "goods" means things that are movable at the time of identification to the contract (Cal. Com. Code § 2105, UCC § 2-105). Contracts for services are governed by common law. (This article cites Article 2 through California's enactment, the California Commercial Code, which numbers its sections to track the uniform text; check the enactment in the state whose law governs your contract.) The classification changes the outcome on at least six issues:

  1. Implied warranties. Article 2 implies a warranty of merchantability (Cal. Com. Code § 2314) and, where the seller knows the buyer's particular purpose and the buyer relies on the seller's skill, a warranty of fitness for that purpose (Cal. Com. Code § 2315). Common law service contracts usually carry only an implied duty to perform in a workmanlike manner.
  2. Limitations. Article 2 sets a four-year period running from tender of delivery, which the parties may shorten to not less than one year (Cal. Com. Code § 2725). State contract limitations periods for services range from three to six years or more and usually run from breach.
  3. Acceptance and rejection. Article 2 gives the buyer rights to reject nonconforming goods (Cal. Com. Code § 2601) and to revoke acceptance when a nonconformity substantially impairs value (Cal. Com. Code § 2608). Common law asks instead whether the breach was material.
  4. Adequate assurance and repudiation. A party with reasonable grounds for insecurity may demand adequate assurance of performance (Cal. Com. Code § 2609) and treat a failure to provide it as repudiation (Cal. Com. Code § 2610). Many states have adopted a similar rule at common law (Restatement (Second) of Contracts § 251), but not all.
  5. Failure of essential purpose. Only Article 2 has Cal. Com. Code § 2719 (UCC § 2-719(2)), which lets the buyer escape an exclusive "repair or replace" remedy that does not work.
  6. Formation. The battle of the forms under Cal. Com. Code § 2207 can decide whether a click-through license or invoice terms became part of the deal. See The Battle of the Forms Under UCC Section 2-207: Purchase Orders, Acknowledgments, and Whose Terms Govern.

The citations here are to California's enactment for convenience; every state except Louisiana has adopted Article 2 in substantially uniform form, and the section numbers track the model code. For a broader treatment of Article 2 itself, see The UCC Article 2 Sale of Goods: Formation, Warranties, Risk of Loss, and Remedies.

The predominant purpose test

Most courts classify a mixed contract by asking whether its "predominant factor, thrust, or purpose" is the sale of goods with labor incidentally involved, or the rendering of services with goods incidentally involved. The test traces to Bonebrake v. Cox, 499 F.2d 951 (8th Cir. 1974), a bowling-alley equipment case. Courts look at the language of the contract (does it speak of "purchase," "buyer," and "seller," or of "services" and "consultants"?), how the price is allocated between product and labor, whether the customer was buying a thing or a result, and the nature of the supplier's business.

Applied to software, the test has produced the following lines of authority:

  • Software as goods. In Advent Systems, the Third Circuit held that computer software is a "good" under Article 2, reasoning that a program, once implanted in a medium, is a movable thing and that applying the UCC promotes uniformity in a field where software and hardware are sold together. The Second Circuit had already treated a turnkey computer system with custom programming as a sale of goods in Triangle Underwriters, Inc. v. Honeywell, Inc., 604 F.2d 737 (2d Cir. 1979), with the result that the four-year UCC period, not New York's six-year contract period, barred the customer's claims. Judge Posner's opinion in Micro Data Base Systems, Inc. v. Dharma Systems, Inc., 148 F.3d 649 (7th Cir. 1998), noted that New Hampshire law treats custom software as a good while Indiana's appellate courts had treated it as a service, and analyzed the contract under Article 2. The opinion is a useful reminder that the classification can turn on choice of law. The Kansas Supreme Court held in Wachter Management Co. v. Dexter & Chaney, Inc., 282 Kan. 365 (2006), that a software purchase accompanied by installation, training, and support was predominantly a sale of goods, because the services would have been unnecessary without the software.
  • Development and integration as services. Other courts treat projects that are mostly custom labor as services. In Pearl Investments, a Maine federal court held that a contract to develop a custom automated trading system was predominantly for services and outside Article 2, even though it produced software. The Indiana Supreme Court reached the same result for a website design and hosting arrangement in Conwell v. Gray Loon Outdoor Marketing Group, Inc., 906 N.E.2d 805 (Ind. 2009).
  • Software as a service. A subscription to hosted software, where the customer never receives a copy, fits poorly into "goods" at all. Courts addressing SaaS have generally treated it as a service or have avoided deciding, and the trend in commercial drafting is to assume common law governs. Lawyers should not assume that answer in any particular jurisdiction; it remains unsettled. For the contract terms that fill the gap, see Cloud and SaaS Agreements: Service Levels, Data Rights, Security, and Exit.

A modern ERP implementation usually bundles three things: a license or subscription from the software publisher, implementation services from an integrator (sometimes the publisher's own consulting arm, often a separate firm), and ongoing support. When the publisher and the integrator are different companies, there are usually two contracts, and each is classified separately. The license may be goods; the implementation SOW almost certainly is services. That split explains why customers often sue the integrator for breach of contract and the publisher for breach of warranty and fraud.

Practical consequences of the classification

The classification fight is often a proxy war. Customers who missed the UCC's four-year window argue "services." Customers who want implied warranties or the failure-of-essential-purpose doctrine argue "goods." Vendors pick the opposite. A few practical points follow:

  • Read the contract's choice of law and any express statement about the UCC. Some agreements say the UCC does not apply, or exclude the U.N. Convention on Contracts for the International Sale of Goods. Courts usually honor a clear choice.
  • Check whether the parties disclaimed implied warranties anyway. If they did so conspicuously under Cal. Com. Code § 2316, the classification may matter only for limitations and remedies.
  • Do not let the classification question drift to summary judgment unaddressed. It is often decided as a matter of law on the contract documents, and the losing side can find its warranty counts or its limitations defense gone.

Part II: The contract claims

What the customer must prove

A breach of contract claim requires a contract, the plaintiff's performance (or excuse), the defendant's breach, and resulting damages. In an implementation case each element hides a fight:

  • The contract. Which documents? The MSA, the SOW, change orders, a "blueprint" the parties signed, a project charter, the vendor's proposal? An order-of-precedence clause usually decides conflicts, and an integration clause usually excludes the proposal unless it is incorporated. See How Courts Read Contracts: Ambiguity, Extrinsic Evidence, and the Canons of Construction.
  • The customer's own performance. Most SOWs list customer responsibilities: provide subject-matter experts, make design decisions within set periods, deliver clean legacy data, supply a test environment, staff UAT. A vendor's best defense is often that the customer failed those obligations, and the customer's own emails often prove it.
  • The breach. Missed milestones, deliverables that fail stated acceptance criteria, failure to meet service levels, or failure to provide "qualified" or "key" personnel named in the SOW. Vague promises ("industry best practices") make breach harder to show; specific acceptance criteria make it easier.
  • Causation and damages. The customer must tie its losses to the vendor's breach rather than to its own changes, the publisher's software, or a third party.

Fixed fee, time and materials, and the change order record

The pricing model frames the case. In a fixed-fee engagement, the vendor promised a defined scope for a defined price, so overruns are the vendor's problem unless the scope changed. The vendor's defense is that it did change, through formal change orders or through the customer's conduct. In a time-and-materials (T&M) engagement, the vendor promised effort, not a result, so the customer must usually show that the hours were wasted, that the vendor failed to staff competent people, or that the vendor breached an express estimate or "not-to-exceed" cap. Hybrid deals (T&M with a cap, fixed fee per phase, milestone payments with holdbacks) are now common and produce arguments about which model governs a particular overrun.

Change control is where most scope disputes are won or lost. If the SOW requires written, signed change orders, and the parties ignored that process and simply did the work, courts may find that the written-change requirement was waived by conduct, or may enforce it strictly and deny payment for unapproved work. Both results appear in the case law, and the outcome often turns on whether the customer knew of and accepted the extra work. A disciplined change order log, kept contemporaneously by both sides, is the best evidence either party will have. A change order log template appears in Technology Project Dispute Toolkit: Notice of Breach Letters, Cure Plans, and Project Record Protocols.

Acceptance testing and deemed acceptance

Acceptance provisions say how deliverables are tested, against what criteria, within what period, and what happens if the customer is silent. Three recurring issues:

  • Deemed acceptance. Many vendor forms say a deliverable is accepted if the customer does not reject it in writing within a set period (often ten business days) or if the customer uses it in production. Customers that go live to hit a business date may have accepted the system under these clauses, even though it does not work.
  • Acceptance criteria. "Materially conforms to the specifications" is only as good as the specifications. If the functional specifications were never finalized, the vendor will argue there is nothing to fail.
  • Acceptance and warranty interplay. Acceptance usually ends the customer's right to reject and starts the warranty period. Under Article 2, acceptance (Cal. Com. Code § 2606) does not bar a damages claim for nonconformity, and revocation of acceptance remains available for substantial impairment. In Hospital Computer Systems, Inc. v. Staten Island Hospital, 788 F. Supp. 1351 (D.N.J. 1992), the court, applying New York's version of the UCC to a custom billing system, held that whether the hospital had revoked acceptance was a fact question for trial, and that the hospital's continuing complaints to the vendor satisfied the notice-of-breach requirement of UCC § 2-607(3)(a) (Cal. Com. Code § 2607).

Material breach: the Indiana welfare case

When can the customer stop paying and terminate? At common law, only for a material breach. A minor breach gives a damages claim but does not excuse the other side's performance, and a party that terminates for an immaterial breach has itself repudiated the contract. That risk is why termination decisions in IT disputes are so fraught.

The most important modern decision is State v. IBM. In 2006 Indiana and IBM signed a ten-year, $1.3 billion master services agreement to modernize the state's welfare eligibility system, moving from county caseworkers to a centralized, call-center and web-based model. Less than three years in, after a rollout plagued by backlogs, errors, and public complaints, the state terminated for cause. Both sides sued. The trial court found that IBM had breached but that the breach was not material, considering the contract as a whole and the benefits the state had received, and it awarded IBM about $52 million in assignment fees, equipment fees, and early termination payments, plus prejudgment interest. The Court of Appeals reversed on materiality, reasoning that the breach went to the "heart" of the contract as defined by its policy objectives.

The Indiana Supreme Court took a third path. The MSA itself defined the standard: the state could terminate for cause only for a breach or series of breaches "material considering this Agreement as a whole." When the contract sets the materiality standard, the court held, that standard governs, and the common law factors in Restatement (Second) of Contracts § 241 apply only when the contract is silent. Applying the contract's own performance standards and indicators, the court held that IBM's collective breaches were material, reversed the trial court, and remanded to calculate both sides' damages with offsets. It left in place the awards to IBM of $40 million in assignment fees and about $9.5 million in equipment fees, while reversing the early termination payments and the prejudgment interest.

Three practical lessons follow. First, draft (and read) the termination-for-cause clause as the materiality standard that a court will actually apply. Second, define measurable performance standards in the contract, because those were the evidence that made IBM's breaches material. Third, a customer can win the materiality argument and still owe the vendor money, because the court remanded for damages on both sides.

When the contract is silent, courts use the Restatement § 241 factors: the extent to which the injured party loses the benefit it reasonably expected, whether damages can adequately compensate, the extent of forfeiture by the breaching party, the likelihood of cure, and the breaching party's good faith. The related doctrine of substantial performance, classically illustrated by Jacob & Youngs, Inc. v. Kent, 230 N.Y. 239 (1921), protects a contractor whose deviations were trivial and unintentional. A system that runs the business with workarounds may be "substantially" performed in a court's eyes even though the customer considers it a failure.

Cure notices and termination

Most MSAs require written notice of breach and a cure period (often 30 days) before termination for cause. Courts usually enforce these provisions strictly. A termination letter that skips the notice-and-cure step, or that identifies different breaches from those in the notice, invites a finding of wrongful termination. The notice should describe each breach specifically, tie it to a contract provision, state what cure would look like, and reserve rights. The vendor, in turn, should respond in writing with a cure plan or a reasoned dispute, because silence looks like acknowledgment.

Termination for convenience is different. Many MSAs let the customer terminate for any reason on notice, usually paying for work performed and sometimes a wind-down fee. A customer unsure whether it can prove material breach sometimes terminates for convenience to limit its exposure, then sues for damages for prior breaches. That works only if the contract preserves accrued claims after a convenience termination; read it first. In federal government contracts, termination for convenience is governed by detailed regulations and standard clauses (48 C.F.R. pt. 49; 48 C.F.R. pt. 52), and a termination for default that is later overturned is typically converted into one for convenience. State and local governments often have their own procurement codes with similar mechanics.

Where the customer wants to keep the vendor working while it decides, Article 2's adequate-assurance procedure, or a contractual demand for a recovery plan, lets it insist on a credible plan without terminating. The toolkit's cure plan template is built for that moment.

Part III: Warranties, disclaimers, and the failure of essential purpose

Express warranties hide in the sales materials

Under Article 2, any affirmation of fact or promise, any description of the goods, and any sample or model that becomes "part of the basis of the bargain" creates an express warranty, and formal words like "warrant" are unnecessary (Cal. Com. Code § 2313). A functional specification attached to the license, a statement in the SOW that the system "will process 5,000 orders per hour," or a demo the customer relied on can each qualify. Mere opinion or commendation ("best-in-class," "world-leading") does not.

In services contracts, the same function is served by the SOW's performance commitments and by any express warranty clause (for example, that deliverables will "conform in all material respects to the Specifications for 90 days after Acceptance"). Read the warranty clause together with its remedy, because the remedy is usually exclusive.

Implied warranties and how they are disclaimed

Merchantability and fitness for a particular purpose can be excluded, but only in the way the Code allows. A disclaimer of merchantability must mention merchantability and, if written, be conspicuous; a disclaimer of fitness must be written and conspicuous; and language like "as is" also works for both (Cal. Com. Code § 2316). Nearly every enterprise software license disclaims all implied warranties in capital letters. Customers attack disclaimers that are buried, that appear only in a click-through document not part of the negotiated agreement, or that conflict with an express warranty (an express warranty generally cannot be disclaimed by inconsistent language).

Failure of essential purpose

Software licenses typically make "repair or replace, or if neither is commercially reasonable, refund the license fee" the customer's sole and exclusive remedy for breach of warranty. Article 2 permits that kind of limitation (Cal. Com. Code § 2719), but adds two safety valves. Under § 2-719(2), where circumstances cause an exclusive or limited remedy to fail of its essential purpose, the buyer may pursue the Code's general remedies. Under § 2-719(3), consequential damages may be excluded unless the exclusion is unconscionable, and an exclusion in a commercial deal is not presumptively unconscionable.

A repair remedy fails of its essential purpose when the seller is unable or unwilling to make the system work within a reasonable time. The harder question is what happens to a separate consequential damages exclusion when the repair remedy fails. Two computer cases from the early 1980s still define the split:

  • The dependent view. In RRX Industries, Inc. v. Lab-Con, Inc., 772 F.2d 543 (9th Cir. 1985), a software system for medical laboratories never worked despite repeated repair attempts. The Ninth Circuit affirmed an award that included consequential damages, holding that the seller's default was "so total and fundamental" that its consequential damages limitation was expunged from the contract.
  • The independent view. In Chatlos Systems, Inc. v. National Cash Register Corp., 635 F.2d 1081 (3d Cir. 1980), a computer system that never functioned as promised led to a finding that the limited repair remedy had failed. But the Third Circuit, predicting New Jersey law, treated the consequential damages exclusion as an independent provision, valid unless unconscionable, and enforced it. The customer still recovered direct damages measured by the difference between the value of the system as warranted and as delivered, which can exceed the contract price.

Most courts now lean toward the independent view for negotiated commercial contracts, particularly where the exclusion and the repair remedy appear in separate clauses. The result is that failure of essential purpose often frees the customer from the "refund the license fee" ceiling but not from the consequential damages exclusion. For an overview of how these clauses work across deal types, see Indemnification and Limitation of Liability: The Risk Allocation Engine of Every Contract.

Part IV: The limitation-of-liability clause and its carve-outs

Anatomy of the clause

The typical clause has three parts. A damages exclusion bars indirect, incidental, special, consequential, exemplary, and punitive damages, usually with an illustrative list ("including lost profits, lost revenue, lost savings, loss of data, and business interruption"). A cap limits all other liability to an amount, commonly the fees paid or payable in the twelve months before the claim, sometimes the total contract value. A set of carve-outs removes certain liabilities from the exclusion, the cap, or both: often indemnities, breaches of confidentiality, data security breaches, gross negligence, willful misconduct, and fraud. The parties may also agree on liquidated damages for delay (Cal. Com. Code § 2718 governs those in goods cases; common law penalty doctrine governs otherwise), and service credits that may or may not be the "sole remedy" for missed service levels.

Courts enforce these clauses between sophisticated commercial parties. The litigation is about interpretation and about public policy limits.

Gross negligence, willful misconduct, and Noble Lowndes

New York, the governing law in many large technology contracts, will not enforce an exculpatory clause to shield a party from its own gross negligence or intentional wrongdoing. Kalisch-Jarcho, Inc. v. City of New York, 58 N.Y.2d 377 (1983), described the excluded conduct as conduct that "smacks of intentional wrongdoing" or reckless indifference to the rights of others. Sommer v. Federal Signal Corp., 79 N.Y.2d 540 (1992), applied that rule to a fire alarm monitoring company's limitation clause.

That public policy rule and an express carve-out for "willful misconduct" are often argued together, and Noble Lowndes is the case every IT litigator needs to know. In 1984 MetLife licensed a claims-processing software system from Noble Lowndes for about $160,000, plus functional specifications and customized enhancements to be billed on a time-and-materials basis up to a not-to-exceed figure. The contract excluded consequential damages and lost profits, with an exception for "intentional misrepresentations, or damages arising out of [the vendor's] willful acts or gross negligence." The vendor delivered the base system and specifications, but MetLife rejected two sets of enhancements, and the vendor ultimately stopped performing a project it had concluded was unprofitable. MetLife sued for its consequential losses, arguing that a deliberate refusal to perform was a "willful act."

The Court of Appeals disagreed. Read in context, "willful acts" meant conduct that is tortious in nature, wrongful conduct in which the vendor willfully intends to inflict harm on the customer, not an intentional nonperformance of the contract motivated by financial self-interest. Otherwise, the court reasoned, the exception would swallow the limitation, because nearly every breach involves some deliberate choice. Sophisticated parties represented by counsel were unlikely to have agreed to such a lopsided allocation.

The practical lesson cuts both ways. Customers that want a vendor's deliberate abandonment of a project to escape the cap need to say so expressly, for example, by carving out "abandonment" or "intentional refusal to perform," or by defining willful misconduct to include a knowing, material breach. Vendors facing an abandonment claim under a standard "willful misconduct" carve-out should start with Noble Lowndes.

Direct or consequential? The re-implementation fight

The single most valuable question in many IT cases is whether the customer's biggest loss, the cost of hiring a new integrator to fix or redo the project, is a direct (general) damage that survives a consequential damages exclusion, or a consequential one that does not.

The doctrine comes from Hadley v. Baxendale (Ex. 1854). General damages are those that flow naturally and necessarily from the breach; consequential damages are those that result from the plaintiff's particular circumstances and were recoverable only if within the parties' contemplation. The label depends on the relationship between the loss and the contract, not on the type of loss. Several modern decisions apply that idea to lost profits:

Customers use the same reasoning for cover. If the contract's very object was a working system, the reasonable cost of obtaining that system from someone else (less the unpaid contract price) is the classic measure of direct damages: the buyer's cover remedy under Article 2 (Cal. Com. Code § 2712) and the expectancy measure at common law. Vendors respond that re-implementation costs depend on the customer's choices (a new platform, a bigger scope, higher-priced consultants) and that some of those costs would have been incurred anyway. The answer is often fact-specific, and courts frequently defer it: in Hertz's suit against Accenture, discussed below, the court declined at the pleading stage to decide whether the contract's limitations barred Hertz's damages, noting that courts in that district often decide general-versus-consequential questions at summary judgment.

Drafting solves this better than litigation. A clause that states that costs of cover, re-procurement, re-performance, and transition "are direct damages" is generally enforced. For a buyer, that sentence may be the most valuable in the contract.

Under Article 2, consequential damages include losses resulting from the buyer's requirements that the seller had reason to know of and that could not reasonably be prevented by cover (Cal. Com. Code § 2715), and incidental damages include reasonable expenses of inspection, care, and effecting cover. An exclusion of "incidental and consequential" damages therefore bars more than many customers realize.

Part V: Fraud, misrepresentation, and the economic loss rule

Why plaintiffs plead fraud

A fraud claim offers a customer four things a contract claim does not: an argument that the limitation clause does not apply (parties generally cannot contract out of liability for their own fraud), rescission and restitution of everything paid, punitive damages in some states, and a different and sometimes longer limitations period. It also changes the tone of the case. That is why nearly every large failed-implementation complaint includes fraudulent inducement, negligent misrepresentation, or a state consumer protection count, and why vendors move to dismiss those counts first.

The fraud theory in an IT case almost always targets the sales cycle: claims about the software's capability, the vendor's experience with the customer's industry, the team that would be staffed, or the time and cost the project would take. The claim is that the vendor knew these statements were false when made.

Gate one: puffery

Statements of general superiority are not actionable. The clearest IT example is the October 2019 ruling in Hertz Corp. v. Accenture LLP, No. 19-cv-3508 (S.D.N.Y. Oct. 25, 2019). Hertz hired Accenture in 2016 to rebuild its websites and mobile apps after a one-day marketing presentation. According to Hertz's complaint, Accenture missed its December 2017 go-live date, asked for extensions to January and then April 2018, and was replaced in mid-2018; Hertz alleged it had paid more than $32 million. Hertz pleaded breach of contract and a claim under Florida's Deceptive and Unfair Trade Practices Act based on the pitch: Accenture's "800 experts," "the best talent in the world," "the skills you need to win," and its promise to "put the right team on the ground" from day one. The court held those statements were quintessential puffery, particularly when made to a sophisticated company with a long relationship with the vendor.

Gate two: particularity

Fraud must be pleaded with particularity under Rule 9(b): the statement, the speaker, when and where it was made, and why it was false. Hertz also alleged that Accenture misrepresented its expertise with a particular development framework and the extent of its code testing (including that portions of code had been "commented out" so tests would pass). The court held those allegations insufficient because the complaint did not say what Accenture had actually represented, by whom, or when, and it dismissed the statutory claim with prejudice. The contract claim proceeded. Customers building a fraud claim need the specific slide, email, or meeting notes, which is one more reason to preserve the sales file.

Gate three: the economic loss rule and "duplicative" claims

The economic loss rule began as a products liability doctrine: a purchaser whose only loss is that the product did not work, or damaged itself, must sue in contract, not tort. East River Steamship Corp. v. Transamerica Delaval Inc., 476 U.S. 858 (1986), adopted it in admiralty. States then extended it, unevenly, to fraud claims between contracting parties. The map is genuinely divided:

The practical upshot: a customer's fraud claim is strongest when it rests on a misrepresentation of present fact (the software already had a feature; the vendor had completed comparable implementations; a named architect was available and committed) rather than on a prediction (the project would take fourteen months). It is weakest when it simply restates the contract's warranties as lies.

Gate four: integration and non-reliance clauses

Every MSA has an integration (merger) clause. Many also have a clause stating that each party is not relying on any representation outside the agreement. These clauses are treated very differently from one another:

Customers negotiating an MSA should resist broad non-reliance language, or should incorporate the RFP response and key sales representations into the agreement as warranties, which converts the fraud fight into a contract claim with a better cap position. Vendors should include a specific non-reliance clause and keep the sales team's claims inside what the contract warrants.

Two cautionary stories: Marin County and BSkyB

Marin County, California, hired Deloitte Consulting in 2005 to implement SAP enterprise software for its finance and human resources functions. After years of problems, the county sued Deloitte in state court in 2010 for breach of contract and fraud, alleging that Deloitte misrepresented its expertise to win the deal, failed to implement the system properly, and covered up its failures. It then filed a second suit asserting civil RICO and related claims against Deloitte, SAP, and a former county official who had worked on the project. After removal, the federal court in County of Marin v. Deloitte Consulting LLP, 836 F. Supp. 2d 1030 (N.D. Cal. 2011), granted the motions to dismiss in part and denied them in part, dismissing the RICO claim against SAP for failure to plead a pattern of racketeering. The case shows both the appeal and the limits of escalating an implementation dispute into a racketeering case: the theory draws attention and pressure but must satisfy demanding pleading rules. The litigation settled in January 2013; according to press reports, Deloitte refunded about $3.9 million of its fees, and neither side admitted wrongdoing.

In England, BSkyB Ltd. v. HP Enterprise Services UK Ltd. [2010] EWHC 86 (TCC) remains the leading example of a fraud finding breaking a liability cap. The court found that an EDS executive had fraudulently misrepresented, during the bid, that EDS had carried out a proper analysis and could deliver a customer relationship management system within the stated time. The fraud finding took the case outside the contract's liability cap of about £30 million, and in June 2010 the parties settled for £318 million, as HP disclosed in its quarterly SEC filing. U.S. courts are not bound by the decision, but it is often cited in negotiations because the facts (an optimistic timeline presented as the product of analysis that had not been done) recur in nearly every failed project.

Negligent misrepresentation and IT "malpractice"

Negligent misrepresentation is pleaded often and succeeds rarely. In New York it requires a special relationship of trust or confidence that creates a duty to speak with care (Kimmell v. Schaefer, 89 N.Y.2d 257 (1996)); arm's-length vendor-customer negotiations usually do not qualify, though a consultant hired specifically to advise on system selection may come closer.

Professional negligence fares worse. Most courts have refused to recognize "computer malpractice" because programmers and integrators are not licensed professionals bound by a code of ethics and a state-imposed standard of care. In Hospital Computer Systems, the court rejected a hospital's professional malpractice counterclaim on exactly that reasoning, noting that without a higher professional code, "no duties independent of those created by contract or under ordinary tort principles are imposed." The exceptions tend to involve independent duties of the Sommer type, where the service affects public safety, or jurisdictions like Wisconsin that do not apply the economic loss rule to services. For the elements of professional negligence generally, see Professional Malpractice: Standards of Care, Expert Proof, and Defenses.

Part VI: The exit. Transition, source code, data, and who owns the custom work

A customer that terminates an integrator mid-project still needs a working system. The vendor still holds the code, the configuration, the documentation, the environments, and the people who know where everything is. The exit terms decide who has leverage in the first sixty days after termination, and they are often more valuable than the damages claim.

Transition assistance

Well-drafted MSAs require the vendor to provide transition assistance for a defined period after any termination, including termination for the vendor's breach, at stated rates. Assistance usually includes knowledge transfer sessions, delivery of documentation and work in progress, cooperation with the replacement vendor, and continued operation of anything the vendor hosts. The key questions are whether the obligation survives termination for cause, whether the vendor may condition it on payment of disputed invoices, and whether the customer can get emergency relief if the vendor refuses. A short-term injunction under Fed. R. Civ. P. 65 is sometimes available to compel contractual transition cooperation where losing access to a system would cause irreparable harm, but the customer must usually show that money damages would not suffice.

Who owns the custom code?

Custom code, configurations, interface programs, data conversion scripts, and documentation written by the integrator are copyrightable works, and ownership follows the Copyright Act unless the contract says otherwise.

  • Work made for hire. Under 17 U.S.C. § 101 and 17 U.S.C. § 201(b), the hiring party owns a work made for hire. But a work by an independent contractor qualifies only if it falls within nine statutory categories and the parties sign a written work-for-hire agreement. Software is not one of the nine categories (unless it is part of an audiovisual work or a compilation, which is sometimes argued), and an integrator's employees are not the customer's employees under the agency test of Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989). A "work made for hire" clause in an implementation SOW therefore often fails to transfer ownership on its own.
  • Assignment. The reliable route is a written assignment signed by the vendor, which 17 U.S.C. § 204(a) requires for any transfer of copyright ownership. Most well-drafted SOWs combine a work-for-hire statement with a present assignment ("hereby assigns") as a backstop, and carve out the vendor's preexisting tools and methods, which the customer receives under a license.
  • Implied license. If there is no valid assignment, the customer that paid for custom work usually has at least a nonexclusive implied license to use it. Effects Associates, Inc. v. Cohen, 908 F.2d 555 (9th Cir. 1990), recognized such a license where a contractor created and delivered work at the hiring party's request intending that it be used. Asset Marketing Systems, Inc. v. Gagnon, 542 F.3d 748 (9th Cir. 2008), applied the doctrine to custom software, holding that a company that paid a contractor to develop programs had an implied, unlimited, nonexclusive license to use, modify, and retain them. An implied license may not include the right to have a replacement vendor modify the code, however, and its scope is a fact question.

Vendors sometimes threaten to withhold code or disable a hosted system pending payment. Remote disabling of a customer's system without clear contractual authority risks claims under the Computer Fraud and Abuse Act, 18 U.S.C. § 1030, and state analogues, in addition to breach of contract. Customers, in turn, must respect the vendor's preexisting intellectual property and confidential methodologies, which may be protected as trade secrets under 18 U.S.C. § 1836. A replacement vendor that has seen the original vendor's proprietary tools may need a clean-room approach; see Running a Clean Room Software Development Project: A Practical Guide. For ownership and implied-license questions in more depth, see Copyright Ownership, Joint Authorship, and Termination of Transfers.

Source code escrow and vendor insolvency

For licensed software from a smaller publisher, customers often negotiate a source code escrow: the publisher deposits source code with a neutral escrow agent, to be released on defined triggers such as bankruptcy, cessation of support, or uncured material breach. Escrows are only as good as the deposit (is it current, complete, buildable?) and the release conditions. In bankruptcy, a licensee of "intellectual property" (as the Bankruptcy Code defines it, which includes copyrights, patents, and trade secrets) may elect to retain its rights under 11 U.S.C. § 365(n) even if the debtor rejects the license, and supplementary agreements such as escrow agreements are protected along with it. Mission Product Holdings, Inc. v. Tempnology, LLC, 587 U.S. 370 (2019), confirmed that rejection operates as a breach, not a rescission, so it does not terminate rights the licensee already holds.

Data return

When the system is hosted (by the publisher or the integrator), the customer needs its data back in a usable format, along with configuration exports, before access ends. Data return clauses should specify format, timing, cost, and certification of deletion. A vendor that withholds data in a payment dispute is in a weak position if the contract says the data belongs to the customer, but contractual remedies take time, and customers should extract regular backups while the relationship is still functional.

Part VII: Proving the case. Damages, records, experts, limitations, and forum

Damages

The default measure in contract is expectancy: the amount that puts the customer where it would have been had the vendor performed. In an IT case that is commonly the reasonable cost to complete or replace the system as promised, minus the unpaid contract price, plus any recoverable losses caused by the delay. Where expectancy is too speculative, a plaintiff may elect reliance damages, the amounts spent in reliance on the contract, subject to the defendant's right to prove that the plaintiff would have lost money even with full performance. Restitution (return of fees paid) is available on rescission for fraud or, in some circumstances, after a total breach.

Lost profits face the highest bar. Kenford Co. v. County of Erie, 67 N.Y.2d 257 (1986), denied lost profits for a domed stadium project because they were not proven with reasonable certainty and were not within the contemplation of the parties when they contracted; the case is routinely cited against claims that a new system would have produced projected revenue or savings. Once the fact of damage is proven, though, uncertainty about the amount is resolved against the wrongdoer, as the Supreme Court explained in Story Parchment Co. v. Paterson Parchment Paper Co., 282 U.S. 555 (1931). Customers also face a mitigation duty: they must act reasonably to limit losses, including by deciding promptly whether to continue, replace, or stabilize. For the general framework, see Proving Damages in Civil Litigation: Certainty, Causation, and the Numbers That Survive.

Vendors have their own damages claims: unpaid invoices, work performed after a disputed termination, and, where the customer terminated wrongfully, lost profit on the remaining term.

Project records

Few commercial cases are as document-dense. A typical two-year implementation generates hundreds of thousands of Slack or Teams messages, tens of thousands of tickets, weekly status reports, steering committee decks, test logs, and code commits. The duty to preserve arises when litigation is reasonably anticipated, which in an IT dispute is often the first written threat to terminate or the first notice of breach (Zubulake v. UBS Warburg LLC, 220 F.R.D. 212 (S.D.N.Y. 2003)). Electronically stored information that is lost because a party failed to take reasonable steps can lead to curative measures or, on a finding of intent to deprive, severe sanctions under Fed. R. Civ. P. 37(e). Collaboration tools with auto-delete settings, vendor-hosted ticketing systems that disappear when the subscription ends, and consultants' personal devices are the usual gaps. See Litigation Holds, Spoliation, and Rule 37(e): Preserving Electronic Evidence Before It Costs You the Case, and for authenticating chat evidence, Authenticating Text Messages, Chats, and Social Media Evidence: Rules 901 and 902, Metadata, and Deepfake Challenges.

The contemporaneous internal messages are often decisive: a vendor engineer writing "we have no idea how to build this interface," or a customer executive writing "we keep changing the requirements and they keep saying yes." Both sides should read their own client's messages first.

Experts

Two kinds of experts recur. A software project management expert evaluates whether the vendor's staffing, methodology, design, testing, and governance met the contract and accepted practice (often measured against frameworks such as PMI's Project Management Body of Knowledge or the publisher's own implementation methodology), and allocates responsibility for delays between the parties. A damages expert quantifies cost to complete, re-implementation costs, internal costs, and any lost profits. Both must satisfy Fed. R. Evid. 702, which since the 2023 amendment requires the proponent to show by a preponderance that the opinion reflects a reliable application of reliable methods to sufficient facts. Daubert v. Merrell Dow Pharmaceuticals, Inc., 509 U.S. 579 (1993), and Kumho Tire Co. v. Carmichael, 526 U.S. 137 (1999), make the gatekeeping obligation apply to experience-based experts like project managers. The common attack is that a delay expert attributed every slipped date to the vendor without analyzing the customer's late decisions, or that a damages expert priced a re-implementation that was larger in scope than the original contract. See Expert Witnesses After the 2023 Amendment to Rule 702: Daubert, Disclosure, and Cross-Examination.

Limitations

The limitations clock is easy to miss because troubled projects drag on. Under Article 2, a breach of warranty claim accrues on tender of delivery, regardless of when the buyer discovers the breach, unless the warranty explicitly extends to future performance (Cal. Com. Code § 2725). In Triangle Underwriters, the vendor's repeated attempts to fix the system did not toll the four-year period. Many MSAs also shorten the period contractually (one or two years is common), and courts generally enforce reasonable contractual limitations periods. Customers that keep negotiating a "path forward" for years should get a tolling agreement in writing.

Arbitration and forum

Many technology contracts require arbitration. The Federal Arbitration Act makes such clauses enforceable (9 U.S.C. § 2) and provides for stays of litigation and orders compelling arbitration (9 U.S.C. § 3; 9 U.S.C. § 4). If the clause delegates arbitrability to the arbitrator, courts must honor that delegation even if they view the arbitration argument as weak (Henry Schein, Inc. v. Archer & White Sales, Inc., 586 U.S. 63 (2019)). Judicial review of the award is narrow and limited to the statutory grounds (9 U.S.C. § 10; Hall Street Associates, L.L.C. v. Mattel, Inc., 552 U.S. 576 (2008)). Arbitration offers technical arbitrators and confidentiality, which some vendors value highly, but limited discovery can hurt the party that needs the other side's internal messages. Some MSAs require escalation to executives and mediation before either forum. See Selecting and Drafting an Arbitration Clause.

Splits and open questions

  • Is an implementation contract goods or services? Courts remain divided, and hybrid license-plus-services deals produce inconsistent results. SaaS has not been squarely resolved in most states.
  • Does a consequential damages exclusion survive a failed repair remedy? RRX and Chatlos still mark the split, with the independent view more common for negotiated contracts.
  • Are re-implementation costs direct damages? The answer turns on the contract and the facts, and courts often defer it to summary judgment or trial.
  • How far does the economic loss rule reach? States range from Florida (products only) to Michigan and Wisconsin (fraud must be extraneous), with Wisconsin excluding services entirely.
  • What counts as "willful misconduct" or "gross negligence"? Noble Lowndes narrows "willful" in New York; other states and other contractual definitions may read the words more broadly.
  • Will AI-assisted development change the standard of care? As integrators use code-generation tools, disputes over quality, testing, and IP provenance of generated code are beginning to appear. There is little appellate authority yet.

Practical implications for each side

For customers:

  • Put measurable performance standards, acceptance criteria, and a materiality definition in the contract; State v. IBM shows they will be applied.
  • Incorporate the RFP response and key representations as warranties, resist broad non-reliance language, and define cover and re-implementation costs as direct damages.
  • Carve "abandonment" or "intentional refusal to perform" out of the cap expressly; do not rely on "willful misconduct" after Noble Lowndes.
  • Document your own performance: decisions made on time, subject-matter experts staffed, data delivered. Your emails are the vendor's best defense.
  • Send specific breach notices, follow the cure procedure exactly, and secure transition assistance and data before terminating.

For vendors:

  • Keep the sales story within what the contract warrants. Train sales teams that "we have done this ten times" is a statement of fact.
  • Document customer dependencies and delays in writing as they happen, through change requests and risk logs, not in a retrospective after the dispute starts.
  • Use deemed acceptance and change control as written. Informal scope additions that you absorb today become waiver arguments tomorrow.
  • Respond to every breach notice in writing with a cure plan or a reasoned dispute.
  • Do not self-help: withholding code or disabling a hosted system without clear contractual authority can turn a fee dispute into a tort case.

Extended worked example: Bramblewood Foods and Northgate Systems Partners

Return to Bramblewood. Its contract documents are a master services agreement governed by New York law, a fixed-fee SOW for "Phase 1: Design and Build" ($4.8 million, with milestone payments and a 10% holdback), and a time-and-materials SOW for "Stabilization Support." The software itself is licensed directly from the publisher under a separate subscription agreement. The MSA caps each party's liability at "fees paid in the twelve months preceding the claim," excludes "lost profits, lost savings, and consequential damages," and carves out "gross negligence, willful misconduct, and breach of confidentiality." It contains a general integration clause and no specific non-reliance clause. Termination for cause requires 30 days' written notice and an opportunity to cure a "material breach."

Classification. The implementation SOW is predominantly services: Northgate sold labor and expertise, and the software came from a third party under a separate agreement. Article 2 likely does not govern Bramblewood's claim against Northgate, so its rights turn on the SOW's terms and the common law of material breach. The subscription agreement with the publisher may be different, but it disclaims implied warranties conspicuously and limits remedies to service credits.

The breach. Bramblewood's contract claim is good on paper. The SOW's acceptance criteria required that order-to-cash processes pass a defined set of UAT scripts with no "Severity 1" defects, and Northgate's own defect log shows 42 open Severity 1 defects at go-live. But Bramblewood went live anyway, after its chief operating officer emailed that "we cannot miss the fiscal-year start." Northgate will argue deemed acceptance through production use. Bramblewood's answer is that the MSA's acceptance clause requires written sign-off, which it never gave, and that production use under protest to avoid business shutdown is not acceptance.

Customer responsibilities. The SOW made Bramblewood responsible for "cleansed and validated legacy data." The Slack record shows that Northgate's data lead raised data quality concerns four times and that Bramblewood's master data team was cut from five people to two halfway through. That is a real causation defense to some of the defects. Bramblewood's lawyers should quantify it before the vendor does.

Fraud. In the sales process, Northgate's partner wrote that the firm had "completed eleven implementations for food distributors on this platform" and that its "pricing accelerator handles multi-tier customer contracts out of the box." Discovery may show that most of the eleven were small projects on an older version and that the accelerator did not support multi-tier pricing. Those are statements of present fact, specific, attributable to a named person, in writing, and outside the contract's warranties. Under New York law, the general integration clause does not bar the claim (Sabo), and a misrepresentation collateral to the contract that induced it can support a separate fraud claim (Bridgestone/Firestone). If proven, fraud would escape the cap. The broad claims of "deep expertise" in the pitch deck, by contrast, are puffery after Hertz.

The cap. Bramblewood paid Northgate $6.1 million in the twelve months before its claim, so the cap is about $6.1 million. Bramblewood's largest loss is the $7.5 million it expects to pay a new integrator to remediate and complete the project, plus $2.3 million in internal overtime and temporary staff and an estimated $4 million in lost margin from shipping errors and lost customers. The re-implementation cost is arguably direct damage (cost of obtaining the promised system), though Northgate will argue that part of the new integrator's scope is new work. The internal costs are contested. The lost margin is almost certainly excluded as lost profits or consequential damages unless the fraud claim succeeds. Northgate's deliberate decision to roll its senior architects to another client after the sale is a staffing breach, but not "willful misconduct" under Noble Lowndes.

Termination. Bramblewood's best path is a specific notice of material breach tied to the acceptance criteria and the key-personnel clause, a demand for a written cure plan within ten business days, a parallel demand for transition assistance and delivery of all custom code, interface programs, and documentation, and a litigation hold issued the same day. If Northgate's cure plan is not credible, Bramblewood terminates for cause after 30 days, withholds the 10% holdback, and preserves its accrued claims. It must also check the MSA's IP clause: the SOW says deliverables are "works made for hire," which will not work for software from a contractor, but it also contains a present assignment of "all right, title, and interest," so Bramblewood likely owns the custom code.

Northgate's position. Northgate's best arguments are deemed acceptance, Bramblewood's data and staffing failures, the cap, the consequential damages exclusion, and a counterclaim for $1.9 million in unpaid stabilization invoices. Its biggest risk is the sales email, which it should evaluate early and candidly.

Likely outcome. A case like this usually settles after document production and before expert reports, often with a payment or invoice write-off by the vendor, a structured transition, and mutual releases. The settlement will reflect the strength of the fraud claim, because that is the only path above the cap. For valuation and negotiation strategy, see Settlement Negotiation Tactics: Principled Negotiation, Anchoring, and Handling Hardball in Litigation.

Common mistakes

  1. Going live to hit a date without reserving rights. Production use can be deemed acceptance. Put a written reservation of rights in the go-live approval.
  2. Terminating without following the notice-and-cure clause. The terminating party becomes the breaching party.
  3. Pleading fraud from the pitch deck. Superlatives are puffery. Find specific statements of present fact.
  4. Ignoring the client's own record. The customer's Slack messages about its own delays will be Exhibit 1 for the vendor.
  5. Assuming "work made for hire" language transferred the code. For contractor-written software, it usually does not without an assignment.
  6. Letting collaboration data expire. Auto-delete settings on Slack, Teams, and vendor-hosted Jira instances destroy the best evidence.
  7. Waiting for the "path forward" talks to finish. Contractual limitations periods keep running. Get a tolling agreement.
  8. Overreaching on damages. A damages model that prices a bigger, better system than the one contracted for invites a Daubert motion and loses credibility with the factfinder.

Frequently asked questions

Can we stop paying the vendor while we dispute the work? Only if the contract allows withholding disputed amounts or the vendor's breach is material. Withholding undisputed invoices can give the vendor a breach claim and, in some contracts, a right to suspend work. Many MSAs require payment of undisputed amounts and a written notice identifying disputed ones.

Does the UCC apply to our ERP project? It depends on whether the contract is predominantly for software (goods) or for implementation services. A license purchased from the publisher may be goods; an integrator's SOW is usually services. Courts disagree, and SaaS subscriptions are generally treated as services or left undecided.

Can a fraud claim get us past the liability cap? Often, yes, if it survives. Most states will not enforce a cap against a party's own fraud. But the claim must rest on a specific, false statement of present fact, pleaded with particularity, not barred by the economic loss rule or a specific non-reliance clause, and not merely a restatement of the contract's promises.

Are the costs of hiring a new integrator "direct" damages? They can be, because they represent the cost of obtaining the performance promised. The vendor will argue that some costs are consequential or reflect a larger scope. Contracts that expressly define cover and re-procurement costs as direct damages avoid the fight.

Can we sue the integrator for professional negligence? Usually not. Most courts decline to recognize IT or "computer" malpractice, and contract law governs. Exceptions are narrow and state-specific.

Who owns the custom code if we terminate? The integrator owns it unless the contract contains a valid written assignment or the work qualifies as a work made for hire, which software from a contractor usually does not. Even without ownership, a customer that paid for the code usually has an implied license to use it.

How long do we have to sue? Check the contract first, because many shorten the period. Under Article 2 the default is four years from delivery. Common law contract periods vary by state. Repair attempts do not necessarily toll the clock.

Takeaways

  • Most failed-implementation cases are decided by the contract documents and the project record, not by the abstract quality of the software.
  • Classify the contract early: goods or services changes warranties, limitations, and remedies.
  • Treat the termination-for-cause clause as the materiality test; follow notice and cure procedures to the letter.
  • The cap and the consequential damages exclusion set the stakes. The direct-damages characterization of re-implementation costs and the fraud claim are the two ways around them.
  • Fraud claims need specific statements of present fact, particularity, and a path past the economic loss rule and any non-reliance clause.
  • Secure transition assistance, data, and code before or at termination, and confirm IP ownership through an assignment.
  • Preserve collaboration data at the first sign of a dispute.

This document is general information, not legal advice for any particular situation; the law changes, and the facts matter.

Related Documents

Related Articles

Related Guides

Related Checklists

Related Toolkits