AI Gross Margin in Software: What Sets the Number

TL;DR AI gross margin in software is a distribution, and the reported number is its average. Usage is never evenly spread across a book, so a healthy blended margin can sit on top of a cohort running underwater, often the one expanding fastest. The value metric, the packaging boundary and the discount surface decide the number before finance reports it, and the value metric also decides who keeps every cost saving.

Which wrapper architecture or cost-reduction move to make belongs to the thin-wrapper treatment; which tooling platform models the scenarios belongs to B2B pricing software.

Gross Margin Stopped Being a Constant

What gross margin measured when marginal cost was near zero

Traditional software’s marginal cost sat near zero, so far below any defensible price that cost never entered a pricing conversation, and gross margin was a reporting exercise rather than a pricing input.

What LLM inference changed

Generative AI put a real cost under every use of the product. Each query consumes tokens, tokens cost money, and the cost is roughly linear with consumption and moves when a model supplier decides it moves. The cost floor rose toward the price ceiling.

Why AI gross margin is now a pricing output

For an AI software product, AI gross margin is an output of the licensing decision rather than a line on a report. The three architectural decisions behind it are covered in the AI software pricing pillar.

A pricing team we worked with was hitting its number and would have rated its own practice comfortably mid-ladder. The read from its own deal records said otherwise. Enterprise accounts were quoted to a ceiling far above where they bought, while the published value metric capped each account’s growth well below the value it was extracting. Every packaging and discount fix downstream had been compensating for that one licensing choice, and nobody had reopened it. The fix ran from the metric outward, account by account, without a disrupted renewal.

The Blended Number Hides the Distribution

What the blended average conceals

In our engagements, software usage has never been normally distributed: a minority of accounts drives most of the consumption. A company-level AI gross margin is therefore an average over a book where a small cohort carries most of the LLM inference cost.

That average can read healthy while a cohort is underwater. To illustrate: a 74% blended margin can sit on top of a set of accounts running at 40%, offset by a larger set running at 85%. The 40% cohort is invisible until you look at the distribution.

Which accounts sit in the tail

The cohort in the tail is frequently the one expanding fastest. Heavy users are the accounts most engaged with the product and the most likely to expand, renew and refer. So the blended number degrades exactly as the business succeeds: as the high-consumption cohort grows as a share of revenue, it pulls the average toward its own margin.

Why capped plans suppress their own cost signal

Modeling work on capped-usage subscription economics isolates the problem. A fixed fee collected against consumption that varies account by account and month by month carries risk across the whole book, and the exposure sits in the heaviest accounts rather than in the average one.

The same body of work shows that fitting consumption expectations to data collected under a cap biases the estimate downward: a capped plan suppresses the signal you would need to price it correctly.

The average is the wrong statistic. The tail is where the margin lives.

One company we advised had converted its base to all-you-can-eat licenses under a chief revenue officer who beat every sales goal that year. Years later a read on its largest accounts showed them consuming many multiples of what their contracts charged, and no blended figure had flagged it, because the rest of the book diluted them. Every attempt to correct the grant met the threat of litigation. Those accounts carry no expansion path now. The tail set the margin and the average hid it.

Three Places the Number Is Decided Before Anyone Reports It

All three are made when the product is packaged and priced; cost-reduction work leaves them untouched.

Decision 1: The value metric

The value metric is the unit revenue scales against. If revenue scales against the supplier’s unit (tokens, compute units, credits used as surrogate units), every increase in consumption raises the bill proportionally, and infrastructure margin is the ceiling.

Where the metric is denominated in customer value, consumption can increase without a proportional cost increase.

Credits and other surrogate units relocate the margin question without answering it; the credit-based pricing treatment covers why a credit caps revenue at infrastructure margin.

Decision 2: The packaging boundary

Packaging determines which capabilities sit in which offerings, whether those are editions, modules on a platform, add-ons or a single offer, and therefore which consumption patterns sit behind which prices. A consumption-heavy capability sold in the entry offering produces a different margin profile than the same capability sold only in an offering with a price that carries it.

The boundary is set at packaging time and cannot be corrected by discounting policy; the scheduled net price at every commitment level is downstream of the offering structure.

Decision 3: The discount surface

The discount surface is where the pricing architecture meets the sales motion. Scheduled net prices may carry margin targets; the realized price is whatever the approval matrix produces deal by deal.

Margin-calibrated discounting covers the discount surface. Where the surface erodes deal by deal, the margin problem surfaces in win-loss data, and by then the cohort has been booked at the wrong price.

Comp structure is where the surface is enforced, or is not; the gross-profit compensation treatment covers that sequencing.

A vendor we worked with had given its representatives open discretion on price, deal by deal, with nothing in the approval path that referenced cost. Across its records the same configuration at the same volume sold at close to list in one account and at a small fraction of it in the next. The pricebook carried a healthy margin target on every line, and the realized price landed wherever the last negotiation left it. The company called this sales empowerment. The margin line recorded it as variance nobody had chosen. That is the common pattern.

The rare pattern is the one in the BDNA case study. BDNA replaced discretionary discounting with structure, calibrated every discount to the margin on the line, and held it through quarter end. Deals then landed within a few points of the calculated net price. The sales force attained 264% of plan while holding the line on discounts. When Flexera acquired the company two years later, a 20% exit premium was attributed to the pricing architecture. The mechanics of that discipline are in margin-calibrated discounting.

Cost Engineering Buys Time, and the Metric Sets the Ceiling

Caching, model routing, prompt discipline, context management, committed-spend agreements with a model supplier: these are real levers and they move the number.

Every efficiency improvement lands on whoever the value metric points at. Where the metric is denominated in the supplier’s unit, a cost reduction passes to the customer automatically: the customer’s invoice shrinks and the vendor’s margin holds where it was. Where the metric is denominated in customer value, the cost reduction accrues to the vendor. Two companies can run identical infrastructure, achieve identical efficiency gains, and report different margin trajectories because they chose different units.

AI price cuts and deflation capture carries the full argument; the falling-cost rescue argument for wrapper products covers why declining API prices are not a structural fix for a cost-anchored price. The AI pricing subsidy cliff covers the model layer repricing against a cost floor the vendor never engineered into the surface.

We have watched this pattern recur in optimization platforms priced as a percent of the spend they optimized. The better the software performed, the less spend there was to take a percent of, so every improvement the product team shipped cut the vendor’s own revenue. A metric denominated in compute units does the same thing to an AI product: cut inference and the invoice falls with it, because the saving was never the vendor’s to keep.

Tests to Run on Your Own Margin Reporting

Each of these questions isolates a place the blended number can mislead.

Can you produce AI gross margin per account, per edition, and per Customer Group, or only at company level?

Which accounts in your book would be margin-negative if their consumption doubled? If you cannot answer that question, you are holding tail risk you have not priced.

Does your margin improve or degrade as an account adopts more of the product? An expanding account is consuming more. Under a fixed or capped fee, margin falls as adoption grows, because cost rises against revenue that does not. Under a metric denominated in the supplier’s unit, margin stays pinned at infrastructure markup however much the account adopts. Only a metric set above the token layer lets margin improve with adoption.

When your model supplier reprices, which line in your architecture responds? How long before that response reaches your realized price? A pricing surface with no cost-floor reference has no answer to this question until the margin has already moved.

If your reported AI gross margin is a weighted average, what is the weight, and who is carrying it? The weight is usage.

If those questions are hard to answer from current reporting, a conversation with an expert is the right next step. The distribution is readable. It requires looking at the right level.

Assessment: Does your AI pricing architecture set a margin ceiling or just report one?

FAQs