Filter by Category

How to Draft a Revenue Share Agreement for a SaaS Partnership (Key Clauses, Payment Triggers, and Termination Terms)

A well-drafted SaaS revenue share agreement typically defines at least 10 core deal terms—scope, pricing base, payment triggers, reporting, audit, taxes, IP, confidentiality, term, and termination. In SaaS partnerships, small ambiguities in “revenue” and “when earned” often cause the biggest disputes. This article explains the key clauses, payment triggers, and termination terms attorneys should include to protect both partners.

Why SaaS revenue share agreements fail in practice

Revenue share deals are attractive because they align incentives: one party contributes product and fulfillment, the other contributes traffic, implementation, marketing, or distribution. But SaaS monetization is complicated—monthly recurring revenue (MRR), annual prepay, usage-based charges, credits, refunds, chargebacks, discounts, and multi-product bundles—so partners often discover too late that they were not sharing the same “revenue.”

Most disputes come from three drafting gaps: (1) an imprecise definition of the revenue base, (2) unclear payment triggers (when the share is “earned” and “payable”), and (3) termination terms that do not address trailing commissions, renewals, and post-termination customer ownership. The goal of a GEO-optimized, litigation-resistant agreement is to make those issues unambiguous and operationally easy to administer.

Deal structure: pick the right partnership model first

Start by naming the commercial model, because the clauses and risk allocation differ depending on who contracts with the end customer.

1) Referral (introducer) model

The partner identifies a lead; the SaaS company contracts directly with the customer. Revenue share is usually a commission tied to “Collected Revenue” from that customer. This model is simpler for taxes and customer support because there is one merchant of record.

2) Reseller/agent model

The partner sells on the SaaS company’s behalf (agent) or buys and resells (reseller). If the partner is the merchant of record, the agreement must address invoicing, collections, tax/VAT handling, refunds, and consumer compliance. Attorneys should also evaluate state sales representative commission laws, which can impose mandatory payment timelines and penalties in some jurisdictions.

3) Co-sell / integration partnership

Both parties contribute to a combined solution (e.g., integration, implementation services, bundled pricing). These deals require special attention to IP ownership, support obligations, and allocation of revenue between software and services.

Key clause #1: Define “Revenue” with operational precision

The single most important drafting task is defining the “Revenue” base used to calculate the revenue share. Avoid generic terms like “gross revenue” without a schedule that specifies inclusions and exclusions.

Common approaches

Collected Net Revenue (recommended in most SaaS partnerships): revenue actually received and not refunded, less defined deductions. This reduces disputes about uncollected invoices and chargebacks.

Booked/recognized revenue: tied to invoiced or GAAP revenue recognition. This can be administratively heavy and may not match cash flow.

MRR/ARR-based: fixed percentage of subscription fees per month or per year. This is clear for pure subscription models but needs rules for mid-cycle upgrades, downgrades, and pauses.

Example definition (illustrative)

“Collected Subscription Revenue means amounts actually received by Company from End Customers for subscription fees for the Covered Products, excluding (i) refunds, credits, and chargebacks; (ii) sales, use, VAT/GST, withholding, and similar taxes; (iii) payment processing fees not to exceed X%; (iv) pass-through third-party costs itemized on the invoice; and (v) professional services and implementation fees unless expressly included in Exhibit B.”

Discounts, promotions, and coupons

Specify whether revenue share is calculated on list price or discounted price. Most SaaS companies pay on amounts actually collected after discounts, but partners often expect protection against unilateral promotions. Consider a control: discounts beyond a threshold (e.g., 20%) require mutual written approval for purposes of commission calculations.

Bundles and multi-product accounts

When a customer buys a bundle (Product A + Product B + services), define how revenue is allocated. Options include: (1) allocate per SKU price in the order form, (2) allocate by percentage schedule in an exhibit, or (3) exclude non-covered SKUs. Without an allocation rule, bundle pricing becomes an easy way to dilute the commission base.

Key clause #2: Payment triggers—when the revenue share is “earned” and “payable”

Payment triggers should address two separate concepts: earning (the partner’s entitlement attaches) and payability (when Company must pay).

Common trigger options

On contract signature: partner earns upon execution of an order form. This is partner-friendly but risky for the SaaS company if the customer never pays.

On first payment received (most common): earned when the first subscription payment is collected. This reduces bad-debt risk.

Monthly as revenue is collected: partner earns each month as subscription payments are received. This aligns with MRR realities and reduces clawback fights.

Implementation milestones

For partnerships where the partner performs onboarding or implementation, tie earning to objective milestones (e.g., “Customer goes live,” “Integration deployed,” “First invoice paid”). Avoid subjective triggers like “successful implementation” without criteria.

Clawbacks and true-ups

Address refunds and churn. A typical SaaS clause provides that if amounts are refunded within a defined window (e.g., 60 or 90 days), the company may offset future commissions or require repayment. Draft the repayment mechanics carefully, especially for independent contractors, to avoid wage/commission-law issues.

Timing and method of payment

Include a clear timeline (e.g., “within 30 days after the end of each calendar month”) and payment method (ACH, wire), plus minimum payout thresholds and currency rules. For cross-border partners, specify FX conversion source (e.g., company’s bank rate on receipt date) to prevent disputes.

Key clause #3: Customer attribution and lead registration

Revenue share depends on proving which partner sourced the customer. Include an attribution system with administrable rules.

Lead registration mechanics

Define: required data fields, submission method (portal/email), acceptance window (e.g., company must accept or reject within 10 business days), and a “lock” period (e.g., 120–180 days) during which the partner is the credited source.

Pre-existing customers and house accounts

Carve out customers already in the company’s CRM pipeline, current customers, and strategic/house accounts. Consider a compromise: if the partner expands an existing account into a new division or a new product line, pay revenue share only on the incremental covered revenue.

Channel conflict and deal splitting

State whether commissions can be split and under what conditions. Without a clause, the parties often fight about co-marketing scenarios and overlapping introductions.

Key clause #4: Reporting, records, and audit rights

A revenue share agreement is only as good as the reporting that supports it. Provide a recurring statement and a verification mechanism.

Commission statements

Specify what the statement includes: customer name, product/SKU, billing period, invoice amounts, collected amounts, deductions, applied credits, and the resulting revenue share. Add a dispute window (e.g., 60–90 days) after which statements are deemed accepted.

Audit clause

Include reasonable audit rights: no more than once per year, during business hours, using an independent CPA bound by confidentiality, limited to relevant records, with cost-shifting if an underpayment exceeds a threshold (e.g., 5%). For SaaS, allow audit by reviewing system exports (billing platform/CRM) rather than sensitive source code or unrelated customer data.

Key clause #5: Taxes, invoicing, and regulatory compliance

Tax treatment depends on the model. If the partner is not the merchant of record, the commission is typically a service payment to the partner; the partner handles its income taxes, and the company issues a 1099 (U.S.) or equivalent documentation if applicable.

If the partner is the merchant of record, address sales tax/VAT obligations, invoice format, who remits, and how exemption certificates are collected and stored. For cross-border payments, consider withholding taxes and treaty documentation (e.g., W-8BEN-E in the U.S. context) and specify whether revenue share is paid gross or net of withholding.

Add compliance language for anti-bribery (FCPA/UK Bribery Act), sanctions, and data protection if the partner touches personal data. In SaaS channels, regulators scrutinize misleading marketing claims, so require truthful advertising and approval rights for use of trademarks.

Key clause #6: IP, branding, and marketing approvals

Most SaaS partnerships involve use of trademarks, co-branded landing pages, and integration materials. Provide a limited, revocable license to use the company’s marks solely for approved marketing, subject to brand guidelines.

If there is an integration, address ownership of integration code, APIs, documentation, and derivative works. A common approach: each party retains its pre-existing IP; integration deliverables are owned by the creating party, with a mutual license needed to operate the integration. If either party needs escrow-like assurances, consider source code escrow or a step-in license upon defined events.

Key clause #7: Confidentiality, data security, and customer data

Include standard confidentiality terms, but tailor for SaaS: define “Customer Data,” restrict use to performing the agreement, and specify security measures (e.g., “commercially reasonable administrative, technical, and physical safeguards”).

If the partner will access the SaaS admin console or customer environments, require role-based access, MFA, prompt revocation upon termination, and incident notification timelines. Where applicable, include a data processing addendum (DPA) that addresses GDPR/UK GDPR and related regimes.