Representations and Warranties in an AI SaaS Sale

In an acquisition agreement, representations and warranties are the seller’s written statements about the business: who owns the code, what the revenue was, which customers and vendors matter, what could go wrong. The buyer prices the deal on those statements. If one turns out to be false, the buyer can seek a remedy, usually through indemnification. For an AI SaaS business, the statements that matter most are about code ownership, training data, third-party model dependencies, privacy and the accuracy of the revenue numbers.

This guide is for founders selling an AI product and for people buying one. It explains what reps and warranties are, which ones show up in AI SaaS deals, how disclosure schedules work, and how to avoid the mistakes that reopen price talks late in a deal. It is general information, not legal advice: have a transactional attorney review the agreement before you sign it.

TL;DR

• A representation is a statement of fact made to induce a deal. A warranty is a promise that the fact is true. In acquisition agreements they are usually bundled into one clause and tied to indemnification.
• Sellers protect themselves with the disclosure schedule. A risk mentioned on a call but missing from the schedule is still the seller’s risk.
• For AI SaaS, expect scrutiny on source code ownership, training data rights, open-source licenses, privacy compliance and model-provider terms.
• Buyers should negotiate AI-specific liabilities (IP infringement from training data, privacy breaches, harmful output) separately from the general cap and basket.
• On AIExchange.club, listings are free, the success fee is a flat 10% with no monthly fees, and deals close through escrow with standardized contracts. The marketplace is for AI SaaS businesses.

Representation vs. warranty: the short version

Lawyers distinguish the two terms, though agreements almost always use them together. Practical Law describes a representation as an assertion of fact, true on the date it is given, that induces another party to act, and a warranty as a promise of indemnity if the assertion is false. An American Bar Association article makes the same split more plainly: a representation is a statement of fact, a warranty is a promise of fact.

Why does it matter in practice? Because the remedy depends on how the agreement is written. A misrepresentation can support claims such as fraud or misrepresentation. A breach of warranty supports a contract claim for damages, and in an acquisition the agreement normally channels those claims into an indemnification section with its own limits.

The phrase “represents and warrants” in the opening line of the clause tells you the seller is doing both. For a founder, the working takeaway is simpler: every sentence in that section is a promise you may be asked to pay for if it is wrong.

How the clause works in a small AI SaaS deal

A typical asset purchase agreement (APA) or stock purchase agreement has four parts that work together:

1. The representations and warranties. The seller’s statements about the business.
2. The disclosure schedules. Lists of exceptions and details that qualify those statements.
3. The indemnification section. What happens if a statement proves false: who pays, how much, and for how long.
4. The closing conditions. Usually that the reps are still true at closing.

The indemnification terms are where deals are really negotiated. According to one M&A firm’s overview, the agreement sets the survival period for the reps, the basket that triggers indemnification, and the cap on liability. The same overview notes that which reps count as “fundamental” is negotiated, and that fundamental reps conventionally survive longer than the rest.

For a small deal, a few definitions are enough:

The numbers are negotiated deal by deal, and you should take legal advice on what is reasonable for your price and structure rather than copying a figure from a blog post, including this one.

The reps buyers push on in AI SaaS

Generic software reps still apply: the company is validly organized, the seller has the authority to sell, financial information is accurate, taxes are paid, there is no pending litigation. AI products add a layer on top. Here is where buyers concentrate.

Ownership of code and IP

The buyer wants to hear that you own the source code, or have a valid license to everything you cannot own, and that no contractor or former co-founder has a claim to it. Solo builders often have a gap here: code written by freelancers without an assignment, or a repo that sits under a personal account that is also used for other projects. Fix those before you list.

Research on AI deals points to the same priority. ABA contributors note that buyers of AI assets should verify source code and training data ownership, which are increasingly treated as fundamental reps in high-stakes AI deals.

Training data and model provenance

Most AI technologies need large datasets to train foundation models, and a buyer who acquires a company using a third-party vendor’s AI has to diligence that vendor too, as a 2024 ABA piece on diligencing AI-enabled targets explains. For a typical wrapper or agent product, the honest statement is often: “We call a third-party model through an API, we fine-tuned nothing, and here is the provider’s current terms of service.” That is a fine answer. A vague one is not.

Be ready to state:

• Which models and providers the product depends on, and under what plan or terms.
• Whether any customer data is used to train or fine-tune anything, and whether customers consented.
• Whether you scraped or licensed any dataset, and what rights you hold.

Open-source and third-party components

Expect a rep that the product does not use open-source code in a way that forces you to release proprietary code, plus a schedule listing the components. The ABA’s coverage of tech deals says disclosure schedules in this space are increasingly technical, covering everything from open-source license audits to vulnerability histories. A dependency scan before listing costs little and removes a point of leverage.

Privacy and security

Buyers ask whether the company has complied with applicable privacy laws, has a privacy policy consistent with what it actually does, and has had any breach or security incident. If your product processes user prompts, uploaded documents or personal data, assume this section will be read closely. Disclose incidents, even minor ones, in the schedule.

Output accuracy and AI-specific compliance

Vendors often try to disclaim every warranty, but the ABA contributors observe that buyers increasingly ask for express warranties on training data sources, output accuracy and compliance with the evolving AI regulatory landscape. Sellers should not give a flat promise that a generative product never produces wrong output. Offer a factual statement instead: what testing exists, what terms of use say, and whether any customer has complained or claimed harm.

Financial and customer metrics

For a revenue-generating micro-SaaS, this is often the heart of the deal. Buyers want representations on:

• Monthly recurring revenue and churn figures, tied to payment processor records.
• The number of paying customers and whether any single customer is a large share of revenue.
• Refunds, chargebacks and disputes.
• Ad spend, API costs and other costs that affect the profit the buyer is buying.

If the figures in your listing differ from the figures in the APA, the buyer will notice.

Disclosure schedules: the seller’s real protection

Practical Law defines disclosure schedules as a document that supplements the reps and warranties, which the disclosing party uses to disclose exceptions. Put simply: the rep says “there is no pending litigation, except as set out in Schedule 3.8.” If Schedule 3.8 lists a dispute, you are covered. If it does not, you are exposed.

A few points founders tend to miss:

Telling the buyer on a call is not enough. Commentary on a Delaware Chancery Court decision stresses that a risk discussed verbally but left out of the formal schedules can remain the seller’s liability. The same article notes Delaware’s “pro-sandbagging” default: a buyer can bring a post-closing claim for breach of a rep even if it suspected the problem before closing, unless the agreement says otherwise. Write it down in the schedule. Whether your agreement is governed by Delaware or another state’s law, ask your attorney how sandbagging is handled.

Schedules are leverage. Experienced acquirers treat missing or sloppy schedules as grounds to renegotiate the price after a deal has moved toward closing. That is a pattern reported in ABA analysis of technology deal terms, and indie founders who treat schedules as paperwork are the ones who get caught.

Be specific, not defensive. Over-disclosing everything in vague terms does not help. List the actual contract, the actual incident, the actual license.

A practical skeleton for an AI SaaS schedule set, which you can adapt with counsel (templates such as this disclosure schedules outline show the general format of exceptions and lists):

1. Material contracts: customer agreements, model-provider terms, hosting, payment processors.
2. Intellectual property: repositories, domains, trademarks, contractor assignments.
3. Open-source and third-party components.
4. Data sources and any customer data used for training or tuning.
5. Privacy and security incidents.
6. Litigation, claims, complaints and chargeback disputes.
7. Employees and contractors, including anyone with access to production.
8. Financial statements and any adjustments to them.

Don’t forget the no-reliance clause

The reps are only as safe as the line around them. ABA commentary on a Delaware fraud case argues that a seller needs an express clause disclaiming reliance on anything outside the written agreement, because otherwise pre-closing statements, pitch decks and emails can become the basis of a fraud claim even if they never made it into the signed documents.

For sellers, two habits follow:

• Treat your listing, your data room and your emails as statements you stand behind. Keep them accurate.
• Make sure the agreement says the buyer relied only on the written reps.

For buyers, the mirror image: if something matters to your decision, such as a churn rate or a claim that no user data trains the model, get it into the reps. A statement that lives only in a chat message may not be protected.

Negotiating AI-specific risk

Standard indemnity limits were built for ordinary software risk. AI adds liabilities that can be larger than the purchase price of a small product. The ABA contributors report a market move toward “super-caps” or carve-outs for critical AI liabilities such as IP infringement from training data, privacy breaches and hallucinated output, negotiated outside the basket or cap that applies to general reps.

In a deal under a few hundred thousand dollars, a full super-cap structure may be overkill. A workable middle path:

• Sellers: keep the cap tied to a share of the purchase price and the survival period short for general reps. Accept longer survival only for title and authority. Offer knowledge qualifiers (“to Seller’s knowledge”) on things you genuinely cannot verify, such as whether a model provider’s training data infringes anyone’s rights.
• Buyers: ask for the AI-specific items to be backed by a holdback or escrowed portion of the price, and insist the schedules name the model providers and data sources.

Qualifiers cut both ways. “To the seller’s knowledge” shifts risk to the buyer, so expect pushback where you could have checked.

A pre-listing checklist for founders

Do this before you list, not during due diligence:

1. Reconcile revenue. Match your stated MRR to payment processor exports, month by month.
2. Clean up IP. Collect signed assignments from every contractor. Move the code, domains and accounts into the entity or accounts being sold.
3. Inventory dependencies. Run a license scan and list model providers, APIs and their terms.
4. Document data practices. Write down what user data you store, where, and whether any of it trains a model.
5. Log incidents. Any outage, leak, abuse report or customer complaint goes on a list.
6. Draft your schedules early. Even a rough version shows you what you cannot yet represent.
7. Book an attorney review. A few hours from a transactional lawyer is cheap next to a post-closing claim.

Perspective: what we see in AI SaaS deals

We built AIExchange.club for AI SaaS businesses, and the pattern we care about is simple: deals go wrong at the point where what was said does not match what was written. A founder describes the product as fully proprietary, and the schedule later shows three open-source components and a contractor with no assignment. A buyer is told revenue is stable, and the processor export tells another story.

That is why we run every deal through a structured six-stage pipeline: kickoff call, LOI, due diligence, APA, escrow and closing. The reps and warranties sit in standardized contracts that are signed in-platform, so neither side starts from a blank page or from a template pulled off a forum. Funds are held in escrow until closing, which removes one more thing to argue about.

Our advice to sellers is to treat the schedule as the product of the sale. Prepare it before the buyer asks. Our advice to buyers is to read the schedules before the price, since the price depends on them. Neither side needs an AI-specific super-cap to start; both need an honest list of what the product runs on and where its data came from.

— Phillip

Selling or buying an AI SaaS business

If you are preparing to sell, listing is free. We charge a flat 10% success fee only when a deal closes, with no monthly fees, no listing fees and no upsells. Every deal closes through escrow with standardized contracts. Buyers who want full marketplace access can choose a membership at $49 per month or $399 per year. If you would rather have hands-on help with a larger or more complex AI deal, there is also our Boutique AI M&A Advisory service, which has no published price.

Sources

• Practical Law: Representations and Warranties
• Practical Law: Disclosure Schedules
• ABA Business Law Today: The Virtue of “Represents and Warrants”
• McLane Middleton: 3 Indemnification Terms and Concepts to Know in an M&A Transaction
• ABA Business Law Today: Avoiding AI Agreement Dystopia
• ABA Business Law Today: Diligencing AI-Enabled M&A Targets
• ABA Business Law Today: Cyber M&A Unique Deal Terms and Emerging Trends
• ABA Business Law Today: Delaware Chancery Court on Sandbagging
• ABA Business Law Today: Disclaiming Reliance Upon Extra-Contractual Statements
• Disclosure Schedules Template