Why AI-Native Software Runs Lower Gross Margins Than SaaS

Classic SaaS cost of goods sold is mostly hosting, a customer success or support allocation, and third-party data costs, all of which scale slowly relative to revenue. An AI-native product adds inference cost that scales roughly with usage, and usage doesn't scale neatly with revenue the way a per-seat SaaS contract does: a customer paying the same subscription fee can drive wildly different inference volume month to month depending on how heavily they use the product.

That volatility is the part a classic SaaS finance model was never built to handle. A per-seat contract lets you forecast cost of goods sold from headcount alone; an AI-native contract needs a usage forecast too, and a customer who ramps up usage faster than expected moves your margin even though the invoice they're paying hasn't changed at all.

Software companies broadly post some of the strongest gross margins of any industry¹, and that figure is the reference point most board members and investors still carry in their heads when they look at your gross margin line. An AI-native product running meaningfully below that reference isn't necessarily unhealthy, it may simply be a different cost structure, but you need to be the one explaining that gap before someone else assumes it's a problem.

A traditional SaaS company's main margin decision is infrastructure efficiency: moving to cheaper compute, optimizing a database query. An AI-native company has that same decision plus a second one that matters more: which model tier handles which request, since routing a simple query to an expensive frontier model is pure margin erosion with no quality benefit the customer would ever notice.

Caching is the third decision that doesn't map cleanly onto the classic SaaS playbook: a cached response costs a fraction of a fresh model call, and a product where many requests are similar enough to cache well can improve its margin substantially without touching the model or the infrastructure at all. Products where every request is genuinely unique don't get that option, which is itself a useful thing to know about your own cost structure.

Show gross margin trending in the right direction as volume grows, since inference cost per customer should improve with better routing, caching, and negotiated vendor rates even if the absolute margin percentage stays below a classic SaaS benchmark. A board that sees the trajectory understands the story; a board that only sees a single quarter's number next to a generic software benchmark will ask why you're behind, without the context of what's actually driving it.

When you show gross margin to a board or investors, cover these points:

• Show the trend as volume grows, since routing, caching and negotiated vendor rates should lower inference cost per customer over time.
• Explain that a margin below the classic SaaS reference is not automatically a red flag, and point to trajectory rather than one quarter.
• Report inference cost as its own line so readers can see it behaves differently from ordinary hosting cost.
• Confirm inference spend is coded consistently as cost of goods sold, so the number you present is actually accurate.

None of this benchmarking means anything if inference cost is miscoded as an operating expense instead of cost of goods sold, or the other way around, which happens more often than it should when a vendor bill gets routed through whatever code the finance team last used for a similar-looking invoice. A bill-pay platform like BILL is where that coding decision actually gets made line by line, and it's worth a specific policy for AI vendor invoices rather than leaving it to whoever processes the bill that month.

Write the policy down once, which model providers' invoices count as cost of goods sold, which internal tooling spend counts as opex, and apply it consistently across every new vendor rather than deciding case by case, since an inconsistent policy makes quarter-over-quarter margin comparisons meaningless even if each individual quarter's number is defensible on its own.