The Predominant Character Rule: How Mixed AI Services Get Classified for Tax

Nobody buys "pure inference." Real AI transactions are messy bundles: you sign up for a platform and get API access to a foundation model, a downloadable SDK, fine-tuning capabilities, hosted storage for your training data, a support SLA, and maybe a dashboard for monitoring usage. Each of these elements, if sold separately, would have a different tax classification.

So which one wins? The 2025 Treasury regulations answer this with the predominant character rule — and understanding how it works is critical for anyone pricing or purchasing AI services.

The Problem: Multi-Element Transactions

Tax law likes clean categories. The 2025 regulations define two main buckets:

• Digital content transactions (reg. 1.861-18) — Transfers of copyrightable computer programs and other digital content. Classified as transfers of copyright rights, transfers of copies, services, or know-how.

• Cloud transactions (reg. 1.861-19) — On-demand network access to hardware, digital content, or "other similar resources." Always classified as services.

But a single AI platform contract often contains elements of both. An enterprise customer paying for Azure OpenAI Service might receive:

• On-demand inference (cloud transaction — services)

• A downloadable Python SDK (transfer of a copy — copyrighted article)

• Fine-tuning through the platform (cloud transaction — services)

• The right to deploy a fine-tuned model on Azure's infrastructure (cloud transaction — services)

• Technical documentation and integration support (services)

Each element has a clear individual classification. But the regulations don't let you split a single transaction into five pieces and classify each one. Instead, you classify the entire transaction based on its predominant character.

The Three-Prong Hierarchy

The predominant character is determined through a strict hierarchy. You use the first prong that gives you an answer:

Prong 1: Primary Benefit to This Specific Customer

What is the primary benefit or value that this particular customer receives? If you can determine what the customer is really paying for — what they'd walk away from the deal without — that's the predominant character.

Example: A hedge fund signs up for an AI platform. They use inference for 10,000 API calls per day and downloaded the SDK once during initial integration. The primary benefit is clearly inference access, not the SDK. The transaction is a cloud transaction (services).

Example: A startup licenses a foundation model specifically to embed it in their product. They get cloud access too, but the deal was structured around the right to distribute the model within their application. The primary benefit is the distribution right — a transfer of copyright. The transaction is a digital content transaction.

Prong 2: Primary Benefit to a Typical Customer

If you can't determine the primary benefit to the specific customer, look at usage data for typical customers in similar circumstances. How do most customers actually use the product?

Example: A hyperscaler offers a foundation model with both API inference and optional fine-tuning. Usage data shows that 95% of customers only use inference and never fine-tune. For a customer whose specific usage pattern is unknown, the typical customer data indicates the predominant character is inference access — a cloud transaction.

Prong 3: Other Factors

If typical customer data isn't available, the regulations fall back to three indicators:

• How the provider markets the transaction. Is it marketed as "cloud AI services" or as a "model license"? Marketing positioning reveals what the provider considers the core value proposition.

• Relative development costs. If the provider spent $100M training the model and $500K building the SDK, the model is clearly the high-value element.

• Relative pricing of elements in uncontrolled transactions. If comparable inference services cost $X per token and comparable SDK licenses cost $Y, and $X >> $Y, inference is predominant.

All-or-Nothing Classification

Once you determine the predominant character, the entire transaction is classified under that bucket. This is critical: if inference access is the predominant element, the whole payment — including the SDK portion — is treated as a service payment. You don't split out 5% and call it a copyrighted article transfer.

This is a major difference from the OECD model treaty approach, which generally bifurcates mixed contracts and classifies each element separately (unless an element is de minimis). U.S. domestic classification and OECD treaty classification can therefore reach different answers for the same transaction — which creates complexity for cross-border deals.

Fact Patterns in AI Transactions

The following fact patterns illustrate where the predominant character question arises in AI commerce. Each presents a transaction structure and the classification issue it raises under the 2025 regulations.

Fact Pattern 1: Standard API Access

Transaction: A customer pays a hyperscaler for on-demand inference via API, with rate limiting, documentation, and a usage dashboard included.

Issue: All elements involve on-demand network access to the model. The question is whether any element — such as downloadable documentation — constitutes a separate digital content transfer that could change the classification.

Fact Pattern 2: Fine-Tuning Bundle

Transaction: A customer pays for platform access to fine-tune a foundation model, run inference on the fine-tuned model, and store the fine-tuned weights on the provider's infrastructure. The customer does not receive ownership of or a right to download the fine-tuned weights file.

Issue: The customer accesses the fine-tuned model only through the provider's platform. The question is whether the absence of a property right in the weights file keeps the entire transaction within cloud transaction classification — and whether contracts that do grant ownership or portability of the weights file would shift the predominant character.

Fact Pattern 3: Model Licensing to a Hyperscaler (2P Model)

Transaction: A model owner transfers a copy of its foundation model to a hyperscaler, along with the right to make copies of the computer program for inference and the right to make copies of the weights and biases file. Maintenance and support are included.

Issue: The transaction contains both copyrightable elements (the computer program) and potentially noncopyrightable elements (the weights and biases). The predominant element could be:

• The computer program — which would make the transaction a transfer of a copyrighted article (rent or sale under the digital content regulations)

• The weights and biases — which, if treated as trade secrets or know-how, would fall outside the digital content regulations and potentially give rise to royalty income

The KPMG report observes that "it seems artificial to treat a foundation model differently from other software" and notes the digital content regulations could arguably cover the whole package — but acknowledges the regulations as written may not support that reading.

Fact Pattern 4: Marketplace Model (3P)

Transaction: A model owner pays a hyperscaler to host its foundation model, provide storage and compute for customer inference, and facilitate sales through the hyperscaler's marketplace.

Issue: Although the model owner transfers a copy of the foundation model to the hyperscaler, the hyperscaler is not paying for the model — the model owner is paying the hyperscaler for hosting and marketplace services. The question is whether the transfer of the model changes the predominant character from cloud hosting (services) to something else, or whether it is properly viewed as merely facilitating the hosting arrangement.

Fact Pattern 5: Agent-to-Agent API Calls

Transaction: An AI agent calls another agent's API endpoint to complete a task. Payment is per-request or per-token, with no software transfer or licensing involved.

Issue: Whether per-request API access to another agent's compute constitutes on-demand network access under the cloud transaction regulations. No transfer of digital content occurs.

Open Questions

Several areas of the predominant character rule present unresolved issues in the context of AI transactions:

Near-equal value splits. The regulations require identifying a predominant element but do not address transactions where two elements are genuinely equal in value. This can arise when a platform bundles cloud inference access with a software license of comparable commercial value.

Evolving usage patterns. The predominant character is determined based on the transaction as structured, but customer usage can shift over the life of a multi-year contract — for example, from primarily inference to primarily fine-tuning. The regulations do not address whether a change in usage triggers reclassification.

Bundling incentives. Providers may structure transactions to emphasize elements that produce a favorable classification. A model owner seeking services treatment (rather than royalty treatment subject to withholding) could bundle its model license within a larger cloud services agreement. Tax authorities may examine these arrangements under substance-over-form principles.

U.S. vs. OECD divergence. The U.S. predominant character rule classifies the entire transaction under one category. The OECD model treaty generally bifurcates mixed contracts and classifies each element separately (unless an element is de minimis compared to the primary element). Cross-border transactions may therefore receive different classifications under each framework.

Relevance to State Sales Tax

The predominant character question arises at the federal income tax level, but its outcome affects state sales tax obligations. If the predominant character of a transaction is a cloud transaction (services), the payment is subject to state sales tax rules governing digital services, data processing, or information services — which vary significantly by jurisdiction.

The AgentTax engine handles the downstream classification: given a transaction type and jurisdiction, it applies state-specific taxability rules across all 51 U.S. jurisdictions.

This post draws on the 2025 Treasury regulations (T.D. 10024, T.D. 10025) and KPMG's "No Need to Reboot: GenAI Fits the Tax Stack" (Tax Analysts, DOC 2026-5375, March 19, 2026).

AgentTax classifies AI agent transactions across 51 U.S. jurisdictions with per-state taxability rules. Try the demo →