Research-backed calculator guide

AI SaaS Gross Margin by Plan: Compare Tier Profitability Under Real Usage

Learn how to calculate AI SaaS gross margin by plan, stress-test heavy users, and set migration or overage triggers from model, infrastructure, and support costs.

AI SaaS gross margin by plan is the share of each plan’s subscription revenue left after the direct cost of serving its customers. The important word is each. A blended company-wide margin can look healthy while a flat-price Pro or Team tier loses money when a small group of power users consumes several times the assumed allowance.

The practical method is to calculate revenue and cost per customer for every plan, then run at least two usage cases: an expected case and a heavy-user case. Include model input and output tokens, retries, retrieval or embedding work, hosting, and support costs that are directly tied to delivery. Divide gross profit by revenue. If the heavy-user result falls below your floor, use a higher tier, a usage allowance, throttling, or an overage price rather than hiding the variance in an average.

Plan gross margin = (plan price − direct monthly COGS per customer) ÷ plan price

Direct monthly COGS should be calculated from actual usage drivers, not just a company-wide API invoice divided by total subscribers. A useful AI COGS estimate is:

AI COGS = monthly requests ×
  ((input tokens per request ÷ 1,000,000) × input $/million tokens
 + (output tokens per request ÷ 1,000,000) × output $/million tokens)
 + other variable delivery costs

Then add a stress case, such as three times expected requests and tokens. A plan is not margin-safe simply because its average customer is profitable. If a heavy customer’s direct cost rises above the percentage of revenue allowed by your target margin, define a trigger to move that customer to another tier or bill the excess.

Gross margin is not net profit. It excludes costs such as acquisition, general administration, and most product development unless your accounting policy places a direct delivery cost in cost of revenue. Stripe’s SaaS guidance defines the metric as (total revenue − COGS) ÷ total revenue and lists infrastructure, direct cloud costs, and customer support among costs that may belong in COGS, while distinguishing operating expenses from direct delivery costs.^[1] Keep the policy consistent across periods and plans.

What to include in an AI SaaS plan margin model

Start with the plan’s customer-facing price and included allowance. If a plan is $49 per month, that is revenue only when the customer is billed that amount. Annual discounts should be converted to an effective monthly price for comparison. Taxes, refunds, payment processing, and sales commissions usually belong outside a gross-margin model unless your reporting policy treats one of them as a direct cost of revenue. State the choice rather than mixing definitions.

Next, model the usage that creates direct cost. At minimum, record requests or completed tasks per day, active days per month, input tokens per request, output tokens per request, and the model mix. For a RAG feature, add embeddings, retrieval calls, vector storage, and any reranking. For an agent, add tool calls, retries, queue or gateway compute, and evaluation runs that are required to deliver the feature. Fixed engineering salaries, roadmap experiments, and general marketing are not interchangeable with per-request cost.

Provider pricing is not one universal number. OpenAI’s published page uses separate input, cached-input, and output prices per million tokens and documents a 50% Batch API reduction for eligible asynchronous work.^[3] Anthropic’s pricing page quotes USD per MTok, separates base input, cache writes, cache hits, and output, and warns that newer tokenizers can produce approximately 30% more tokens for the same text in some model families.^[4] Google’s Gemini pricing similarly distinguishes input, output, context caching, batch, and tool charges, and notes that some prices change on a specified future date.^[5] Put the model, pricing mode, date checked, and unit in your worksheet. Do not call a blended rate a vendor quote.

FinOps recommends defining a business unit such as cost per customer, transaction, or analyzed task, then tying variable technology spend to that unit.^[2] For AI SaaS, the plan customer is a useful unit, but it is not enough by itself. Keep a second distribution view with percentiles or at least a heavy-user scenario. The customer who uses ten times more tokens should not disappear inside an average cost per account.

The calculation steps

1. Normalize the plan price. Convert monthly and annual plans to an effective monthly price. Record whether the price includes tax, discounts, credits, or a free allowance. A $49 annual-equivalent price and a $49 month-to-month price can have different cash timing, but the same effective revenue for this calculation.

2. Define the included workload. Write the allowance in measurable units. “Generous AI access” is not an input. “60 requests per day, 2,000 input tokens and 700 output tokens per request” is an input that can be challenged against logs.

3. Apply the current rate card. Use the provider’s current unit and model mix. If routing sends 70% of requests to a lower-cost model and 30% to a larger model, calculate both portions. If cache hits or Batch processing apply, use their separate rate only for eligible volume.

4. Add non-model direct costs. Include per-customer storage, retrieval, embeddings, gateway compute, and customer support that scales with delivery. Keep fixed hosting or a shared support team separate unless you have a defensible allocation method. The goal is a repeatable policy, not false precision.

5. Calculate normal and stress margins. The normal case supports pricing and forecasting. The stress case tests the promise made by a flat-price tier. Use observed P90 or P95 usage when you have enough data; otherwise label three-times usage as an assumption.

6. Set an action threshold. For a 70% target gross margin, direct COGS can be no more than 30% of revenue. When a plan’s stress cost exceeds that ceiling, choose an action: cap, throttle, overage, model downgrade, migration to a higher tier, or a price change. The calculation identifies the trigger; product and customer policy decide how to implement it.

Worked example

The table below is an original illustrative model, not a vendor quote. It assumes 30 days per month and a blended API rate of $0.40 per million input tokens and $1.50 per million output tokens. Those rates are deliberately labeled assumptions; a real model should use the applicable dated provider rate card. “Other variable COGS” includes an allocated amount for delivery costs such as retrieval, storage, and support. It excludes CAC, general payroll, corporate overhead, and roadmap development.

Here is how the Pro row is produced. At 60 requests per day for 30 days, the customer generates 1,800 requests. Input cost is 1,800 × 2,000 ÷ 1,000,000 × $0.40 = $1.44. Output cost is 1,800 × 700 ÷ 1,000,000 × $1.50 = $1.89. Add $1.25 of other variable COGS and total direct COGS is $4.58. Gross margin is ($49.00 − $4.58) ÷ $49.00 = 90.7%.

That result is not a promise that every Pro customer produces a 90.7% margin. In the 3× case, the same customer costs $11.24, and gross margin falls to 77.1%. If a Team customer reaches 3× usage, direct COGS rises to $39.45, leaving 60.2% margin. If the target is 70%, the Team customer needs total monthly revenue of $39.45 ÷ (1 − 0.70) = $131.50. At a $99 base price, the required excess charge is $32.50 per month under this scenario.

That $32.50 is a decision input, not a recommended public price. A product team could instead route eligible work to a cheaper model, reduce the allowance, cap the expensive operation, or migrate the account to an enterprise plan with a different service promise. If the customer’s workload is genuinely valuable, a usage-based overage may be clearer than silently degrading quality.

How to compare plans without hiding heavy users

A plan comparison should show at least three columns that a blended margin report omits: expected direct cost, heavy-user direct cost, and the margin floor after stress. Add the share of customers in each plan and the share of total AI usage. A plan with 10% of customers can create more than 10% of AI cost if its users have long contexts, expensive output, tool calls, or high retry rates.

Use logs to replace assumptions over time. Join subscription records to request-level usage by plan, customer, model, and feature. Reconcile the resulting estimate to provider invoices; the AI API invoice reconciliation calculator can help structure the estimate-versus-actual check. If you cannot attribute a shared invoice, mark the allocation as an estimate and show a variance range rather than presenting a precise margin.

Watch the factors that move margin quickly. Output tokens can be more expensive than input tokens, so a verbose answer policy can hurt a plan even when request counts are stable. Cached prompts may reduce eligible input cost but do not make every request free. Model routing can improve the blended rate, but routing quality, fallback calls, and retries must be counted. A plan that looks safe at average usage can still breach its floor during a burst or after a model migration.

A practical operating dashboard tracks plan price, active customers, requests per customer, input and output tokens, model mix, retries, direct infrastructure, support minutes, estimated COGS, gross profit, and P50/P90/P95 cost per customer. For a broader model of monthly AI infrastructure and usage, use the AI Agent Cost Calculator. For investment decisions about instrumentation and incident reduction, compare the resulting economics with the AI observability ROI calculator.

Limitations and accounting boundaries

This method is a management model, not a substitute for financial-statement policy. Stripe notes that SaaS companies may classify hosting, direct cloud costs, support, and maintenance differently depending on their accounting approach.^[1] Decide with finance which costs belong in cost of revenue, document the rule, and apply it to every plan. Do not compare a margin that includes support labor with one that excludes it.

Provider pages change. Prices may differ by model version, geography, cloud marketplace, service tier, commitment, batch eligibility, cache behavior, or negotiated enterprise contract. OpenAI, Anthropic, and Google publish different units and discount mechanisms, so a single blended rate should be refreshed when your model mix changes.^{[3] [4] [5]} The table’s three-times case is an assumption, not measured customer data. Replace it with a measured percentile when the sample is reliable.

Finally, gross margin does not answer whether the company is profitable. It does not include acquisition cost, sales compensation, most R&D, G&A, interest, tax, or cash timing. It answers a narrower and useful question: after the direct cost of delivering a plan’s promised service, how much revenue remains to fund the rest of the business?

FAQ

What is a good AI SaaS gross margin by plan?

There is no universal target because model mix, support promises, customer segment, and accounting policy differ. Use a target that leaves room for the rest of your operating model, then test every plan under expected and heavy usage. A plan can exceed a company-wide target on average while failing for its power users, so report both weighted margin and the distribution of cost per customer.

Should API spend be included in AI SaaS COGS?

Customer-triggered model calls are usually a direct cost of delivering an AI feature and are a sensible COGS input for a management model. Internal experimentation, general R&D, and employee productivity tooling may belong in operating expense instead. The classification should follow your accounting policy and remain consistent. Stripe’s guidance is useful for separating direct delivery costs from sales, marketing, G&A, and other operating expenses.^[1]

How do I calculate gross margin for a free AI SaaS plan?

Set revenue to zero for the free customer and calculate the direct cost of the included usage. The gross margin percentage is not meaningful when revenue is zero; report direct cost per free user and the paid conversion rate instead. Then allocate the free-tier cost to the paid cohort only if that is your chosen unit-economics view, and label the allocation clearly.

When should an AI SaaS customer move to a higher plan?

Define a trigger before a customer breaches the margin floor. For example, migrate when forecast direct COGS at the customer’s trailing P95 usage would exceed 30% of current revenue for a 70% target margin, or when usage exceeds the included allowance for two consecutive billing periods. Give the customer a clear explanation and service choice: upgrade, buy overage, reduce usage, or accept a lower-cost model path.

Should I use average tokens or a percentile?

Use both. The average is useful for forecasting total spend, but a percentile protects the plan promise. Model P50 for a typical customer and P90 or P95 for a heavy-user stress case once you have enough observations. If you lack data, use a transparent scenario such as 3× usage and replace it when production evidence becomes available.

How often should the plan-margin model be updated?

Refresh it when provider prices, model routing, tokenization, cache behavior, allowances, or plan prices change. A monthly review is a practical minimum for a growing AI product; review sooner when a vendor changes a rate card or when usage distribution shifts. Reconcile the estimate to invoices and keep the checked date beside every rate assumption.