Who pays but uses little AI?
Find accounts with observed revenue and low attributable model cost without assuming that missing usage means zero.
Customer profitability
Customer profitability analysis for your AI SaaS.
Revenue and AI cost only belong in the same row when they refer to the same customer account. Grow or Die makes that link explicit and keeps everything else in an unallocated bucket.
The short answer
What does customer profitability analysis measure?
Customer profitability analysis compares the revenue earned from each customer with the cost of serving that customer. For an AI SaaS, start by joining payment revenue and model usage to the same account ID, reporting window and currency. A team with several users can still be one paying account.
Observed contribution = customer revenue on the selected billing basis − attributable AI cost. This is not net profit. Support, hosting, acquisition, salaries and other expenses may be excluded. Fees, tax and refund coverage depend on the connected billing source; do not subtract an adjustment twice or assume an unavailable fee is zero.
A reproducible example
How to read a customer profitability report
These four rows come from our executable account reconciliation example. They are synthetic fixtures, not customer results. In this example only, net receipts explicitly deduct tax, processor fees and customer refunds.
| Account | Currency | Net receipts | AI cost | Contribution |
|---|---|---|---|---|
| A | USD | 15 | 5 | 10 |
| A | EUR | 8 | 1 | 7 |
| B | USD | 10 | Unknown | Unknown |
| C | USD | Unknown | 4 | Unknown |
Account A has USD 10 of contribution, not USD 10 of net profit. Do not add its EUR 7 to that number without an explicit exchange-rate policy. B has a payment but incomplete AI cost; C has model cost but no revenue evidence. Neither is proven profitable or loss-making. A known zero payment is different from a missing payment ledger.
Use the SQLite fixture and expected output to reproduce the full six-row report. For your own data, first investigate unknown coverage, then review accounts with negative observed contribution. Use the contribution margin calculator to test pricing assumptions; an estimate is not a verified customer report.
A trustworthy join
Payment identity meets model usage at your account ID.
- Observe who paid. Stripe, Lemon Squeezy, or Polar supplies orders, refunds, and its customer identifier.
- Identify the product account. Your backend links that payment customer to the opaque account ID already used by your product.
- Attribute model usage. Server SDK events carrying the same account ID contribute their priced AI cost.
- Calculate only what is covered. Revenue minus attributable AI cost becomes observed contribution; gaps stay visible and are not spread across other customers.
Questions you can answer
Make pricing and product decisions from account evidence.
Who is expensive to serve?
Compare model cost with revenue for accounts whose identity coverage is complete enough to calculate.
Where is contribution still unknown?
See unallocated revenue and AI cost separately, then fix the missing account or payment link.
What should change next?
Use the evidence to investigate pricing, usage limits, model choice, caching, retries, or a costly product feature.
No invented allocation
Unknown customer contribution should look unknown.
Dividing unlinked cost evenly across customers makes a complete table and a misleading decision. Grow or Die shows coverage beside the result so you can tell a calculated margin from an incomplete one.
Related reading
Find loss-making accounts without guessing.
How to find loss-making AI customers
Join payer identity and model usage without spreading unknown cost across every account.
Token cost is not profit
Usage needs observed revenue and a trustworthy identity link before you can calculate customer contribution.
Link a Stripe customer to AI usage
Connect Stripe revenue through one stable internal account ID, not email joins.