AI COGS Accounting: A Clean 2026 Method

SaaS accounting evolved for products where COGS was 70% hosting and 30% support, with R&D as a separate operating expense. AI products break this pattern. Tokens are the dominant COGS, hosting is rounding error, and prompt engineering sits awkwardly between R&D and operating expense. Solo founders who use a "Cost of Goods Sold: AI services" line on their P&L produce a number that 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 traditional buckets

Traditional SaaS COGS structure:

• Hosting and infrastructure (60-75% of COGS)
• Customer success / onboarding (15-25%)
• Payment processing and tooling (5-15%)
• Total COGS: 25-35% of revenue → gross margin 65-75%

AI product COGS structure:

• Model API tokens (60-90% of COGS) — the new line that doesn't fit traditional categories
• Hosting and infrastructure (5-15%)
• Customer success / onboarding (5-15%)
• Payment and tooling (3-8%)
• Total COGS: 35-55% of revenue → gross margin 45-65%

Damodaran's software-industry margin data places median software gross margin at 71%^[3]. AI products at 45-65% gross margin look worse on this comparison until the accounting reflects the structural difference. SEC 10-K filings of public AI-adjacent companies show how the disclosure typically handles this^[4]: tokens are reported as direct cost of services, not lumped into general operating expense.

2. Tokens as variable COGS

Token spend meets every accounting definition of variable cost of goods sold:

• Direct cost incurred to deliver the product
• Scales linearly with usage
• Billed per-unit (per million tokens)
• No volume threshold below which the cost disappears

The right P&L treatment: line item "Cost of revenue: model API tokens." Sub-categorized by model (Sonnet, Haiku, GPT-4o, etc.) and by use case (user-facing inference, internal classification, evals). The sub-categorization matters because it surfaces where the spend is going and supports the routing optimizations that fix margin problems.

Anthropic and OpenAI both publish per-token pricing with clear billing trails^[1][2]. The audit trail is automatic: every API call has a timestamp, a token count, and a cost. Aggregate weekly into the P&L category. Solo founders who want a clean audit trail can use the API providers' own dashboards, exported to a spreadsheet monthly.

3. Infra as fixed COGS, allocated per user

Hosting, database, monitoring, and other infrastructure costs are typically fixed monthly subscriptions (Vercel Pro, Supabase Pro, Sentry Team) plus marginal usage costs. For accounting purposes:

• Fixed monthly tier: Treat as period cost in the month incurred. Allocate across users via simple division (total fixed infra cost / active user count = per-user infra cost).
• Marginal usage: Treat as variable COGS (similar to tokens). Tracks linearly with traffic.

At solo scale, fixed infrastructure tiers dominate (free tiers cover most products to 1,000+ users). The allocation per user is small ($0.10-$1.00 per active user per month). This is the bucket most often misreported because founders either over-allocate (treating Vercel Pro as a per-user cost) or under-allocate (forgetting to include it in COGS at all).

4. Support overhead on AI-resolved tickets

The hidden COGS line: human support time spent on AI-failed tickets. When the AI agent handles 65% of tickets and escalates 35%, the human time on the 35% is direct cost of revenue. It belongs in COGS, not in operating expense, because it's incurred per customer interaction.

The right treatment: track human support hours per resolved ticket (whether AI-resolved with human review or escalated to human entirely). Multiply by loaded hourly rate. Include in COGS. ChartMogul's 2024 retention report places customer success as a significant share of operating cost for SaaS^[5]; in AI products, the share that's specifically support overhead (vs onboarding or growth motion) should sit in COGS.

The reason this matters: a product reporting "Cost of revenue: $X" without a support-overhead line is reporting an inflated gross margin. The overhead is real and adversarial — it doesn't show up until something breaks. Including it makes the gross margin number defensible.

5. Prompts as amortizable R&D, not COGS

Prompt engineering is one of the most expensive activities in building an AI product, and it doesn't fit any traditional COGS bucket. The right treatment:

• Initial prompt development: Capitalize as internal-use software R&D. Amortize over the useful life (typically 12-24 months for a production prompt before substantial rework).
• Ongoing prompt iteration: Treat as R&D operating expense in the period incurred. Don't capitalize incremental tweaks.
• Eval suite development: Capitalize as R&D. Useful life 18-36 months because evals carry forward across model upgrades.

The reason prompts aren't COGS: they're an asset created once and used across many customer interactions, not a cost incurred per customer interaction. Treating them as COGS would mean a founder who spent 80 hours on a prompt in January would have a terrible gross margin in January and a great gross margin in every subsequent month. That doesn't match the underlying economics.

SEC reporting conventions for internal-use software development costs (ASC 350-40) support this treatment for AI products. Solo founders who plan to ever exit or raise outside capital should adopt it now — retrofitting is harder than starting clean.

6. The audit trail that makes this defensible

The method only works if the data is traceable. Three sources of audit trail:

• API provider dashboards. Anthropic, OpenAI, and other vendors expose per-call billing detail with timestamps. Aggregate monthly into the P&L line. Reviewable by any third party.
• Vendor invoices. Vercel, Supabase, Clerk all send monthly invoices with line items. Map line items to P&L categories consistently.
• Time logs for prompts. Toggl or similar for the engineering time spent on prompt development. The capitalization amount depends on the time tracked.

The audit trail matters most at acquisition or due-diligence moments. An acquirer reviewing a SaaS purchase will ask "what's in this AI cost line" and a founder who can't decompose it loses credibility immediately. SEC 10-K filings from public software companies are the gold standard for how this should look^[4]; solo founders should build toward that standard from day one.

7. Implementing this in a solo SaaS

Five steps to convert from "single AI expense line" to defensible AI COGS:

• Week 1: P&L restructure. Split the existing "AI cost" line into the four buckets (tokens, infra, support overhead, prompts). Backfill 6-12 months of historical data from invoices and API dashboards.
• Week 2: Track support overhead. Add a column to the support-ticket tracker for "human minutes spent." Aggregate monthly into the COGS line.
• Week 2-3: Capitalize prompt development time. Identify the prompt-engineering hours from the engineering log. Capitalize the production-prompt work; expense the iteration work.
• Week 4: Document the method. Write a 2-page accounting policy that names the four buckets, the data sources, and the amortization periods. This is the document that goes to an acquirer or auditor.
• Ongoing: Monthly close. Same as traditional SaaS — invoice review, ticket review, time-log review. The cadence is identical; the categorization is more granular.

The method takes 2-4 weeks to implement and adds 2-3 hours per month to the close cycle. The payoff is a P&L that holds up under sophisticated review and supports operational decisions (where is the AI spend going, what's the real gross margin) that the single-line approach cannot.

One additional pattern worth pre-empting. Most founders avoid this kind of accounting work because it feels like overhead. The opposite is true at acquisition. A founder with clean, audited AI COGS gets a 10-25% valuation premium over a comparable founder with messy accounting, because the acquirer's due diligence cost drops dramatically. The 2-4 weeks of upfront work is one of the highest-return time investments in a solo SaaS — pays back at exit by 100x or more.

A second pattern: the four-bucket method becomes more important as AI features expand. A product with one AI feature might survive single-line accounting. A product with five AI features across acquisition, support, content generation, classification, and embeddings cannot — the spend pattern is too varied to interpret without the structural decomposition.

The third extended pattern is about tax treatment. The capitalize-vs-expense decision on prompts has tax implications. Capitalizing reduces current-year deductible expense but produces a higher gross margin number on the P&L. Most solo founders prefer the current-year deduction (lower tax bill now) over the higher gross margin. The right answer depends on the founder's tax situation and the strategic value of the higher reported margin (e.g., for acquisition prep). Consult a CPA familiar with software accounting before deciding.

The AI Product Margin calculator handles the unit-economics piece of this story. The AI Stack Cost calculator handles the infrastructure allocation. The Profit Margin calculator handles the broader P&L picture. Together they implement the quantitative side of the four-bucket method; the founder still owns the categorization discipline and the audit trail.