Your AI Bill Is Hiding Your Least Profitable Customers

Every CFO can produce one number for AI spend: the monthly invoice. Far fewer can produce the number that decides the business: what a single customer's AI usage costs to serve. In AI economics, margin risk hides twice. The aggregate invoice hides the per-customer cost. The average customer hides the accounts that cost more than they pay. Both gaps can already be embedded in the current financials of an AI-enabled software company.

Two firms mapped the same problem in 2026 from opposite ends of the table. Vista Equity Partners, writing in May from inside a portfolio of more than fifty companies running agents in production, named inference as software's new variable cost and drew the blunt conclusion: left unmanaged, the revenue from agentic products is captured by the model providers and hyperscalers rather than by the software company. Vista cites an external analysis estimating that AI-native B2B companies generate nearly a quarter of revenue from AI. BCG followed in early July, arguing that companies should measure token spending against the outcomes it creates rather than in aggregate, workflow by workflow; it defines return on AI as economic return divided by the combined cost of human effort and tokens. BCG estimates AI-enabled software gross margins resetting into a 65 to 80 percent band, down from the 80-plus percent a quarter-century of SaaS underwriting assumed. Together, the two reports point to the same management problem: aggregate AI spending conceals the unit economics underneath it.

Cost per outcome is the right meter and the wrong place to stop. A software company does not earn money per token or per outcome. It earns through a contract, so the operating unit that decides the business is AI contribution margin per customer: the revenue attributable to the AI capability minus its full incremental cost to serve. That measure will not map cleanly to reported gross margin, but it exposes the economics that the aggregate statements conceal. Capability-adjusted inference costs have fallen fast over the past two years, though unevenly across tasks and models, so a workflow that fails today's economics on model price alone may turn viable as the market improves. Deflation will not rescue a workflow whose economics are broken by uncontrolled volume, heavy human review, or weak customer value. None of those problems resolve automatically when provider pricing falls. Follow the ladder to its end, and it lands on enterprise value. A company that cannot see inference cost per customer cannot tell whether its agentic revenue is accruing to the business or leaking to the model provider. A quality-of-earnings review may surface or normalize that cost during diligence, after which the buyer may underwrite the business at a lower adjusted margin.

Walk into the technical diligence of an AI-enabled SaaS target and ask the CTO to break down last month's model spend by customer. In my experience, the number almost never exists on the first ask. The common answer is the aggregate invoice from OpenAI, Anthropic, or Azure OpenAI, because nobody tagged the API calls with a customer ID, a workflow, or a feature flag when the integration first shipped. That is the One-Bill Test: if the company can only show you one bill, it is guessing at the margin on its AI feature. The forwardable version fits in a sentence that an operating partner can send tomorrow. Show me last month's model spend by customer, plus the median, 90th, and 99th percentile cost-to-serve, against revenue for those same accounts.

Passing the first half is where the work starts, because the provider invoice is only the meter. The full cost to serve one outcome runs past it, into retrieval and search, orchestration and tool calls, supporting infrastructure and monitoring, security controls, and the human time to review and approve, plus every failed attempt that burned tokens on the way to nothing.

Then the average lies the same way the aggregate did. Cost to serve follows a heavy tail. A product can post an acceptable mean while a handful of high-usage accounts run at little or no gross profit. Consider a hypothetical product where the median customer costs seven dollars a month to serve against fifty dollars of allocated revenue, while the ninety-ninth-percentile customer costs a hundred and eighty. Under a flat-price or unlimited-AI subscription, heavy users can become the least profitable customers on the book when pricing and entitlements do not scale with consumption. So the number that matters is the distribution, set against the contract terms for those accounts. This is where AI economics stops being a finance problem and becomes a product one: seeing the cost is where management starts, and tiers, usage meters, and caps are what keep the value from leaving. I have seen the same shape in large-scale cloud and data platforms: treated as one centralized invoice, infrastructure spend looks fixed, but once workloads were isolated, assigned to owners, and tied to product economics, real reductions came without taking value from customers. AI intensifies a familiar version of the problem, since customer behavior shifts the cost to serve in real time and autonomous agents can drive consumption even when no user is active.

Whether any of that is visible comes down to architecture, and this is where a code read and a spreadsheet read diverge. If the product routes model calls through a shared gateway or a common SDK, adding customer and workflow tags can be a contained instrumentation sprint. If calls are scattered across endpoints, background jobs, sub-agents, and two or three providers wired in at different times, it can become a multi-sprint program. The durable pattern is one attribution layer at the gateway, reconciled back to the provider invoice, keyed to an internal account ID rather than a customer name handed to a third-party model provider, or the cost-visibility project quietly becomes a data-governance incident. Background inference is often among the hardest usage to attribute, triggered by events rather than active user sessions: the monitoring agents and compliance jobs running continuously against every event. The job still has to inherit a tenant or cost-center identifier, or that continuous consumption accumulates outside the customer-level economics management believes it is measuring.

The gateway is necessary but not sufficient. It attributes model usage, and on its own, it still cannot tell whether the business outcome succeeded or what the customer paid for it. Both of those live in other systems. Passing the test in full means reconciling three ledgers: the provider bill, the product's own workflow and outcome telemetry, and the commercial system that holds customer revenue and entitlements. With only the first, a company can measure consumption; contribution margin requires all three.

One more thing a walkthrough surfaces that a spreadsheet can miss: customer-facing inference, internal experimentation, and development workloads often share the same provider accounts. When they do, finance cannot separate product-delivery cost from R&D and internal operating expense. A buyer's diligence team may surface or normalize those costs even when the historical statements are never restated, so the company should establish the separation before the transaction process begins.

65 to 80 percent. That is the gross-margin band BCG estimates AI-enabled software may reset into, down from the 80-plus percent most PE models still carry into the deal. Treat it as a warning; the pricing model can still move. Sell variable intelligence on a flat subscription built for near-zero marginal cost, and the margin erodes; meter it, tier it, or cap the tail, and the company keeps more of what it creates.

Portco Brief is a weekly briefing for PE operating partners and portfolio company executives focused on technology, AI, and value creation.

Subscribe at portcobrief.com.