SaaS · Saas

Gross Margin for SaaS — A Field Guide

Gross Margin for SaaS — A Field Guide is the work that turns a product into a business. The code is one thing; the business is the company that ships the code, sells it, supports.

John Kihiu12 min read

Gross margin is the metric most SaaS founders think they understand and most get wrong in the same way: they calculate it like a software company from 2005, where COGS is basically hosting, and ignore everything else it actually costs to keep a customer paying. Gross margin is revenue minus cost of goods sold, divided by revenue — but for SaaS, COGS is a wider bucket than server bills, and getting that bucket right is what makes the number mean anything to an investor or to you.

What actually belongs in SaaS COGS

Cost of goods sold is the cost of delivering the service to an existing customer, as opposed to the cost of acquiring a new one (that's sales and marketing, a separate line). For a SaaS business, that means hosting and infrastructure, obviously, but it also means customer support headcount, customer success managers (if their job is retention and onboarding rather than upsell), third-party API costs baked into the product, payment processing fees, and any data or licensing costs passed through per customer. A common mistake is putting customer success entirely under sales and marketing — if that team's job is keeping existing customers successful rather than closing new logos, its cost belongs in COGS, and moving it there usually drops reported gross margin by several points.

The formula, correctly scoped

Gross Margin % = (Revenue − COGS) / Revenue. COGS = hosting/infrastructure + customer support + customer success (retention-focused) + payment processing fees + third-party/embedded API costs. Sales, marketing, and product engineering for new features sit below the gross margin line, not inside it.

Why 70% is the line people cite

Public SaaS benchmarks cluster gross margin in the 70-85% range for healthy companies, with best-in-class product-led businesses pushing past 85%. Below roughly 70%, investors start asking whether the business is really software margins or whether it's a services business wearing a SaaS label — heavy implementation costs, high-touch onboarding, or a support burden that scales linearly with customer count instead of staying flat. A company selling itself as pure SaaS with 55% gross margin usually has a services or support cost structure that needs to be either automated away or explicitly priced as a separate line item.

SQL · MONTHLY GROSS MARGIN
SELECT
  DATE_TRUNC('month', invoice_date) AS month,
  SUM(revenue)                                   AS revenue,
  SUM(hosting_cost + support_cost
      + cs_cost + payment_processing_fee)        AS cogs,
  ROUND(
    (SUM(revenue) - SUM(hosting_cost + support_cost
        + cs_cost + payment_processing_fee))
    / NULLIF(SUM(revenue), 0) * 100, 1
  )                                               AS gross_margin_pct
FROM monthly_finance_ledger
GROUP BY 1
ORDER BY 1;

Gross margin vs. contribution margin per customer

Aggregate gross margin hides which customers are actually profitable to serve. A large enterprise account that needs a dedicated support engineer and custom integration work can have a much lower per-customer contribution margin than a self-serve customer who never opens a ticket, even though both pay the same subscription price. Segmenting COGS by customer tier — self-serve, mid-market, enterprise — usually reveals that one tier is subsidizing another, which is useful information for pricing and for deciding where support automation investment actually pays off.

Where margin improves, and where it plateaus

The classic SaaS margin improvement levers are: moving support volume from humans to self-service and automation, negotiating better infrastructure rates as usage scales, and reducing the ratio of CS headcount to customer count through better onboarding and product-led retention. These levers have diminishing returns — a support team can only get so lean before response times and churn suffer, and infrastructure costs rarely fall below a floor set by actual usage. Margin that looks like it's improving because support headcount is frozen while revenue grows is a warning sign, not a win; it usually shows up later as a churn or NPS problem.

Don't let R&D or new-feature engineering leak into COGS

Engineering cost for building new product belongs in R&D below the gross margin line. Only the engineering cost of keeping the existing product running for existing customers — infrastructure operations, on-call, critical bug fixes — arguably belongs in COGS, and even that's a gray area many finance teams exclude entirely. Inflating COGS with general engineering cost understates gross margin and misleads everyone reading the number.

Wrapping up

Gross margin only tells the truth if COGS is scoped honestly: hosting, support, customer success, and payment processing — not sales, not new-feature engineering. Track it monthly, segment it by customer tier, and treat any margin "improvement" driven by frozen support headcount as a retention risk in disguise, not a finance win.

John Kihiu
Acumatica ERP Developer · Laravel Engineer

Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.