AI COGS Accounting: A Clean 2026 Method

SaaS accounting grew up around products whose cost of revenue was mostly hosting and support, with development as a separate operating expense. AI products change the mix: model tokens can be the largest cost of serving a customer, and prompt and evaluation work sits somewhere founders are unsure how to book. A single "AI services" line on the P&L has no audit trail and no analytical use. This article lays out a method that fixes that.

1. The problem: AI COGS doesn't fit one line

For reference, the listed US software companies in Damodaran's January 2026 dataset report an aggregate gross margin of 71.72% (Software, System & Application, 309 firms; 62.58% for Software, Internet)^[3]. An AI product's gross margin depends mostly on the model tier: in the hub's AI micro-SaaS unit economics report, the same $39-a-month product runs at 77% to 98% gross margin depending on the model, with the model line between about a quarter and nearly all of the cost of serving a user.

That spread is the reason for a method. If token spend, hosting, support and development all sit in one line, nobody can tell whether a margin change came from usage, a model switch, a support backlog or a burst of prompt work.

2. Tokens as variable COGS

Token spend has every property of a variable cost of revenue:

• It is incurred to deliver the product.
• It rises with usage.
• It is billed per unit (per million tokens).
• There is no volume below which it disappears.

The P&L treatment: a cost-of-revenue line for model API tokens, next to hosting. Sub-categorize it by model and by use (customer-facing inference, internal classification, evaluation runs), because that is what shows where routing to a cheaper model would pay off.

Anthropic and OpenAI both publish per-token prices and per-request usage records^[1][2], so the audit trail is mostly automatic: export usage from the providers' consoles monthly and reconcile it to the invoices. Evaluation runs are development work, not service delivery; tag them separately so they can go to R&D.

3. Infra as COGS, allocated per user

Hosting, database, monitoring and similar costs are usually fixed monthly plans (such as Vercel Pro, Supabase Pro, Sentry Team) plus usage above the plan:

• Fixed plan fees: cost of revenue in the month incurred. For unit economics, divide by active users to get a per-user figure.
• Usage above the plan: variable cost of revenue, like tokens.

This is the bucket most often misreported: founders either leave it out of COGS altogether or treat a fixed plan as if it scaled per user. The AI Stack Cost calculator shows how the fixed lines and the model line move as users grow.

4. Support overhead on AI-resolved tickets

The easily missed COGS line is human time on the tickets the AI does not resolve. If an AI agent resolves 65% of tickets and escalates 35%, the human handling of that 35%, and any review of AI answers, is a cost of serving customers and belongs in cost of revenue alongside the AI's own token cost.

Track human minutes per escalated ticket, multiply by the loaded hourly cost and book the total in COGS. A cost of revenue without this line overstates gross margin, and the gap widens exactly when the AI's resolution rate drops. The AI vs human support cost calculator models the trade-off at your ticket volume.

5. Prompts and evals: R&D, not COGS

Prompt engineering and evaluation suites are among the most expensive work in building an AI product, but they are not incurred per customer, so they are never COGS. The question is only whether to expense them or capitalize them on the books:

• Expense as R&D in the period incurred. Simple, conservative and what many small companies do.
• Capitalize as internal-use software under ASC 350-40, which covers the software behind a hosted product, if the work meets its criteria. Under ASU 2025-06 (effective for fiscal years beginning after December 15, 2027, with early adoption permitted) capitalization starts once management has authorized and committed to funding the project and it is probable the software will be completed and used as intended; significant unresolved development uncertainty means the threshold is not met^[4]. Ongoing tuning of a working product is generally expensed.

Capitalized costs are amortized over a useful life you set and disclose; there is no standard figure for prompts, and a model upgrade that forces a rewrite shortens it. Whichever policy you pick, apply it consistently and write it down.

6. The audit trail that makes this defensible

• Provider usage exports. Per-request usage with timestamps from the model providers, reconciled to their invoices each month.
• Vendor invoices. Hosting, database, auth and monitoring invoices, each line mapped to the same P&L category every month.
• Time records. Hours on prompt and evaluation work, separated from support and other work, if you capitalize any of it.

The audit trail matters most at an acquisition or financing. A buyer reviewing the P&L will ask what is in the AI cost line; a founder who can decompose it by bucket, with the source data behind each, answers in minutes rather than weeks.

7. Implementing this in a solo SaaS

• Restructure the P&L. Split the existing AI cost line into the four buckets and backfill recent months from invoices and usage exports.
• Track support time. Add a field for human minutes to the support tracker and total it monthly into COGS.
• Choose the prompt policy. Expense, or capitalize under the ASC 350-40 criteria; separate development hours from tuning if you capitalize.
• Write a short accounting policy. Name the four buckets, the data sources and the capitalization policy. It is the document an acquirer or auditor will ask for.
• Close monthly. Invoice review, usage export, support minutes, time records. The cadence is the same as any SaaS close; the categories are finer.

The four-bucket split matters more as AI features multiply: one feature can survive single-line accounting, but a product using models for support, content, classification and search cannot be read without it.

Tax is a separate decision from the book treatment. For US federal tax, amounts paid or incurred in developing software are treated as research and experimental expenditures, and domestic ones are deductible in the year incurred for tax years beginning after December 31, 2024 (with an election to amortize instead)^[5]. Capitalizing prompt work on the books does not by itself change that deduction, and since prompt work is not COGS, neither choice changes the gross margin. Confirm both treatments with an accountant who works with software companies.

The AI Product Margin calculator handles the unit-economics piece, the AI Stack Cost calculator the infrastructure allocation and the Profit Margin calculator the broader P&L. Together they cover the quantitative side of the four-bucket method; the categorization discipline and the audit trail stay with the founder.

Frequently asked questions

Why does AI need its own COGS method?

Because one "AI expense" line hides four different kinds of cost. Model tokens scale with every request, hosting is mostly fixed, human support on escalated tickets scales with conversations, and prompt and evaluation work is development rather than a cost of serving a customer. Splitting them shows where gross margin actually goes and which lever (model routing, plan size, support process) moves it.

Are tokens really variable COGS?

Yes. Token spend is incurred to deliver the product, rises with usage and is billed per unit, which is what a variable cost of revenue is. Put it in cost of revenue next to hosting, not in operating expenses or R&D, so the gross margin reflects what it costs to serve each customer.

Why are prompts not COGS?

Prompt and evaluation work is development: done once (and then revised), used across all later customer interactions, and not incurred per customer. On the books it is either expensed as R&D or, if the work meets the internal-use software capitalization criteria in ASC 350-40, capitalized and amortized; many small companies simply expense it. For US tax, software development is treated as research and experimental expenditure, deductible in the year incurred for tax years beginning after 2024 under section 174A, whatever the book treatment. Confirm both with your accountant.