All posts
GuideJune 15, 2026·10 min read

Why AI is now COGS, not R&D: a CFO's guide to AI cost accounting

AI spend has crossed from R&D to cost of goods sold. The accounting choice changes gross margin, valuation multiples, and the unit economics conversation with your board. Here's the framework.

By Danny Lo

TL;DR

For most of SaaS history, the cost to serve an additional customer was nearly zero. AI features broke that. A heavy user of your AI summarization feature now costs $50-100 per month in API spend. A light user costs nothing. That's a textbook cost-of-goods-sold pattern, not R&D.

Most AI-native companies still account for AI spend as operating expense or R&D. This was defensible in 2023 when AI was experimental. It's no longer defensible in 2026 when AI features are a core part of the product and scale with customer activity.

The accounting choice matters. Reclassifying AI from R&D to COGS lowers reported gross margins, compresses the SaaS multiple investors apply, and changes the unit economics conversation with your board. Companies that handle this transparently build trust. Companies that don't will have it forced on them by their auditors, public peers, or activist investors within the next two reporting cycles.

This post is a framework for making the call deliberately.

The pre-AI SaaS gross margin story

For two decades, software was the rare business where you could grow customers without growing variable cost. Bandwidth, database storage, compute — all so cheap that gross margins stayed comfortably in the 75-85% range. That structural high-margin profile is what made SaaS attractive to investors and what justified the high revenue multiples the category commanded.

The cost line that did exist (cloud infrastructure, customer support, payment processing) scaled sub-linearly with revenue. Double your revenue, your AWS bill went up 60%. The leverage was built into the model.

The narrative was clean: SaaS is high-margin because it's high-margin. Investors stopped questioning it because the numbers always supported it.

What AI did to that story

AI usage scales differently. It scales with customer activity, almost linearly.

Concretely:

  • A customer using your AI summarization feature heavily can cost you $50-100 per month in API spend
  • A customer who uses it lightly costs you nothing
  • A customer who doesn't use it costs you nothing
  • The variable cost is genuinely variable, in a way storage and bandwidth never were

That's a textbook cost-of-goods-sold pattern. Variable, customer-driven, scales with usage. The same pattern that drove gross margin compression at companies like New Relic (compute as COGS for an APM tool) and Twilio (telco minutes as COGS for messaging).

For most AI-native SaaS companies in 2026, AI spend is now somewhere between 3% and 15% of revenue. At the upper end, it materially affects gross margin. At the lower end, it's a line item the board will start asking about within the next reporting cycle.

Why the classification still defaults to R&D

Most companies still account for AI spend as either operating expense or research and development. This is not an accounting error. It's a leftover from when AI was experimental.

In 2023, classifying Claude or GPT-4 spend as R&D was defensible. The use cases were exploratory. The features weren't core to the product. The spend was small enough that it didn't move gross margin meaningfully. Audit teams approved it because the alternative classifications also fit.

By 2026, all three of those conditions have changed. AI features are no longer experimental at AI-native companies — they're the product. The use cases are core revenue drivers, not exploratory side projects. And the spend is large enough to move gross margins by several hundred basis points if reclassified.

The accounting hasn't caught up. The narrative still says AI is innovation expense. The reality says AI is the cost of delivering the product.

The math when you reclassify

Take a typical mid-stage AI-native SaaS company. Annual revenue of $25M. Reported gross margin of 72%, in line with category benchmarks. AI spend is 6% of revenue, currently sitting in R&D.

Line itemCurrent (AI in R&D)Reclassified (AI in COGS)
Revenue$25.0M$25.0M
Cost of revenue$7.0M$8.5M
Gross profit$18.0M$16.5M
Gross margin72%66%
R&D$9.0M$7.5M
S&M, G&A$10.0M$10.0M
Operating income-$1.0M-$1.0M

Notice what changes and what doesn't. Operating income is identical. Total cost is identical. What shifts is which bucket the dollars sit in.

But the bucket matters. A 72% gross margin company is benchmarked against high-margin SaaS comps. A 66% gross margin company gets benchmarked against the next tier down — companies whose forward revenue multiples are 30-40% lower. For a company at $25M ARR, the difference in implied valuation can be $50-100M.

For private companies, the impact is on fundraising. For public companies, it's on stock price. Either way, the accounting choice is not cosmetic.

Why the position is hardening

The R&D classification for AI spend was defensible when AI was experimental. As AI becomes the product, the position becomes harder to defend each reporting cycle.

Three questions are useful for testing where you stand:

  • Are the AI features experimental or revenue-generating? If customers are paying for them — directly or as part of a bundled product — they're not experimental anymore.
  • Does AI spend scale with customer activity? If yes, the cost is variable and customer-driven. That's a COGS pattern, not an R&D pattern.
  • Could a reasonable person look at this and conclude it's a cost of delivering the service? If you removed the AI spend, would the product still work the way customers expect? If the answer is no, it's a cost of delivery.

When all three answers point toward "yes, this is COGS," the R&D classification is hard to defend. When answers split — for example, revenue-generating features built on top of experimental model fine-tuning — the three-bucket model often fits best (split AI spend between R&D for model work and COGS for inference).

Most AI-native SaaS companies in 2026 answer "yes" to all three for their core product features. The accounting treatment hasn't caught up because nobody has forced the issue yet. That's changing.

What the public AI-native companies are doing

The public market is already pricing in the COGS reframing for the most exposed companies. A few examples worth knowing:

Snowflake discloses AI compute costs separately in their cost of revenue line, with explicit commentary on usage-based cost dynamics. Their gross margin has compressed from 67% in fiscal 2023 to roughly 63% in 2026, with AI usage being a named factor.

Databricks (private but heavily covered) reportedly treats AI inference cost as COGS for its Mosaic AI offerings, separating it from R&D for new model development.

CrowdStrike has begun discussing Charlotte AI compute as a cost of delivering the security platform rather than a research expense.

Salesforce has not yet reclassified AI spend at the Einstein/Agentforce level, and analysts have started asking pointed questions about gross margin trajectory as a result.

The pattern: the companies acting transparently get rewarded for clarity. The companies waiting get analyst pressure. Within a year, the choice is likely to be made for everyone in the category.

What CFOs should do about it

Five concrete moves, in roughly this order:

1. Get the data — and recognize this is an engineering investment, not a finance one.

You can't have the COGS conversation without knowing what AI actually costs per customer, per feature, and per product line. This data does not exist by default at most companies. Engineering didn't build it because finance didn't ask for it. Finance didn't ask for it because they didn't know it was possible.

This is the first cross-functional gap to close. Send your engineering counterpart (VP Engineering, Head of Platform, or the team lead managing AI infrastructure) a specific request: "I need per-customer AI cost attribution, refreshed monthly, broken down by feature. Help me understand what it would take to build."

What you'll typically hear back: it requires instrumenting LLM calls with customer and feature tags, building a data pipeline to a queryable store, and creating dashboards. Realistic build time at a mid-stage company: 2-4 engineering weeks for a v1. Some teams already have parts of this from cost-monitoring work; few have the full picture.

The mistake to avoid: treating this as a one-time data pull. The right framing is an ongoing operating capability. AI usage changes monthly; the data infrastructure has to keep up.

2. Run the reclassification analysis internally.

Before changing how you report externally, model the impact. What does gross margin look like in three scenarios — AI as R&D (current), AI as COGS, AI split between R&D for model fine-tuning and COGS for inference? The three-bucket model is often the most defensible answer.

This is finance work, not engineering work — but it depends on the data engineering produced in step 1. The conversation needs to flow: engineering provides the cost breakdown, finance applies the accounting treatment, both sides validate the result makes sense. If engineering's data shows $2M annual AI cost and finance's reclassification analysis assumes $5M, something is wrong with the data definition. Catch that before it shows up in board materials.

3. Build a shared monthly operating review with engineering.

This is the move most companies miss and the one that compounds over time. Set up a recurring monthly review — 30 minutes — where finance and engineering look at AI cost data together. Same dashboard, same questions, same room (literal or virtual).

The agenda is consistent every month:

  • What did AI cost us last month, total and per customer?
  • Which features drove the biggest changes month-over-month?
  • Are any customer segments becoming unprofitable on AI alone?
  • What's the trajectory and what does it project for next quarter?

The value of doing this monthly is alignment. Finance learns what engineering is shipping and how it affects unit economics. Engineering learns what financial signals to optimize for. The board conversation becomes a synthesis of work already done, not a fire drill three days before the meeting.

Companies that establish this cadence early end up with much better instincts about pricing, customer profitability, and feature investment. Companies that don't end up making these decisions in isolation and getting them wrong.

4. Update the unit economics dashboard your board sees.

If you've been showing gross margin as a single line, start segmenting it. Software gross margin (the traditional view), AI-inclusive gross margin (the COGS-reclassified view), and AI cost as a percentage of revenue tracked over time. Three lines instead of one.

The board will appreciate the transparency, and the framework will hold up as the category matures. More importantly, it forces internal consistency — engineering and finance now have to agree on the numbers because they show up on the same dashboard.

A practical tip: build the dashboard so engineering can see it too. The same dashboard finance uses for board prep should be visible to your VP Engineering. When both sides see the same numbers, the cross-functional conversations get easier.

5. Tie engineering priorities to AI cost outcomes.

This is the highest-leverage move and the one most companies do not do.

If AI cost is now a structural part of unit economics, the engineering team that owns AI infrastructure should have AI cost efficiency in its OKRs or quarterly priorities. Not as a vanity metric — as a measurable target. Something like: "Reduce cost-per-active-user by 15% through caching optimization and model routing improvements by end of Q3."

This sounds obvious. In practice, almost no AI-native company has this in their engineering OKRs today. Engineering is incentivized on shipping features and reliability; AI cost is treated as somebody else's problem (usually finance's).

Closing that incentive gap is the single highest-ROI thing a CFO can do on AI cost. When engineering owns the cost outcome, decisions get made differently — prompt caching gets prioritized, model selection gets rigor, expensive features get redesigned. Cost compresses as a natural byproduct of aligned priorities, not as a remediation project.

The harder question this raises

Reclassifying AI from R&D to COGS isn't just an accounting move. It's a strategic admission that AI cost is structural, not transient.

That changes how you think about pricing. If AI cost is 6% of revenue today and growing 30% year over year, your gross margin is on a glide path down unless you act. Flat-rate pricing on usage-based costs is structurally unstable.

It changes how you think about customer profitability. If your top 5% of users consume 60% of AI spend, you might have customers who are unprofitable on AI alone. Worth knowing before you renew them at flat pricing.

It changes how you think about feature roadmap. Features that drive AI cost without driving retention are optimization candidates. Features that drive both are pricing candidates.

The accounting question is the gateway to a larger strategic question: in a world where the cost to serve a customer is no longer zero, what is your actual unit economics, and what are you going to do about it?

The CFOs who answer this clearly will define the next decade of SaaS finance. The ones who don't will be defined by their auditors and analysts.

Tracking AI cost per customer requires data infrastructure that most engineering teams haven't built yet. AIWatcher is the operational layer that handles per-customer, per-feature, per-team AI cost attribution across coding tools and product AI. We work with AI-native SaaS companies in design partner mode. Request access →

See AIWatcher in action

The control loop for AI work — catch it before it runs, prove it after.

Get started