California Published the Software Tax Rules, and Every Load-Bearing Term Is Anchored to a Human

Key Takeaway: On September 1, 2026, the CDTFA issued its discussion paper and eight draft regulations implementing S.B. 122, which makes prewritten software and SaaS taxable in California on January 1, 2027. This is an emergency rulemaking; the interested parties meeting is September 10 and written comments close September 24. Draft Regulation 1600.2 defines a "user" as an employee or agent of the purchaser, presumes that counting users or computers is a sound apportionment method, and states that apportioning by the location of the servers where the software is installed is not. If you run autonomous agents, that is the one physical anchor you have, and the draft rule rejects it by name.

What actually posted

The CDTFA's Business Taxes Committee page carried this topic with an empty Notice column for the better part of a month. When we reported that the package had a regulation number on August 23, there was no paper behind it. There is now.

The cover letter is dated September 1, 2026, signed by Sandy Barrow, Chief of the Tax Policy Bureau, and describes "the proposed emergency rulemaking action to clarify the application of tax to the sale and use of digital products." The enclosure is an 18-page discussion paper plus eight exhibits carrying the full text of amendments to Regulations 1502, 1507 and 1699.6 and new Regulations 1502.2, 1600, 1600.1, 1600.2 and 1600.3. The meeting is September 10 in Sacramento with a Teams option; written comments close September 24; every new regulation is operative January 1, 2027.

The word "emergency" is doing real work. Anyone who assumed a leisurely comment-and-revise cycle running into next spring should revise that assumption. The comment window is three weeks long and it opened yesterday.

The apportionment question, answered

Draft Regulation 1600.2 governs digital products purchased for multiple points of use. It defines a user as "an employee or agent of the purchaser that is authorized by the purchaser to use the digital product in the performance of their duties as an employee or other agent of the purchaser."

The mechanics that follow are workable, and for a normal software buyer generous. A purchaser may use "any reasonable method that is consistent and uniform" to calculate the in-state and out-of-state measure, so long as its books and records support it when the transaction is reported. Methods based on the number of users or computers inside and outside the state are expressly included, and the draft goes further: it is presumed that counting users or computers is a sound alternative method. A purchaser who knows at purchase that the product will be used in multiple places may issue a multiple-points-of-use certificate, and a seller who takes one in good faith is relieved of liability on the out-of-state measure.

Then comes subdivision (d)(4), one sentence long: "A method of calculating the measure of tax based on the location of the servers where the software is installed is not considered reasonable."

For an agent operator that sentence is the whole document. An autonomous workload has no employees and no seats. The number of natural persons authorized to use the product may be two founders and a contractor, while the product executes millions of calls across regions with no human in any of them. The one thing such a workload does have is a physical place where the compute happens, and California has just said it will not accept that as a method.

Be careful about what this does and does not mean. The draft leaves "computers" as a permitted denominator, defining "computer" through Regulation 1600 and RTC section 6010.9. Counting client computers is not the same as locating the servers where software is installed, and there is a reading in which an operator counts the machines that access the product rather than the machines that host it. That is what I would build toward - but it is a reading, not a stated rule, and it sits beside a prohibition an auditor could stretch to cover it. Someone should ask that question at the September 10 meeting, in those words.

The word "agent" in the definition of user will attract attention, and I would not lean on it. In context it carries its ordinary agency-law sense: a person acting for a principal.

This also resolves a comparison we have tracked all summer. Michigan adopted a software MPU certificate and repealed it effective January 2009; Chicago operates one today on a denominator of Chicago users over total seats; Massachusetts apportions too. California is the fourth and lands where Chicago did, on headcount. No United States jurisdiction apportions software tax by machine activity, and California considered the closest available proxy and rejected it in one sentence.

The human-effort exemption, and the carve-out that swallows it

The more consequential find is not in 1600.2. RTC section 6372.1, added by S.B. 122 and restated in draft Regulation 1600(g)(3), exempts a digital product representing a service provided in electronic form where two things hold: the service primarily involves the application of human effort by the provider, and that human effort originated after the customer requested the service. That exempts the electronically delivered professional service while taxing the packaged product.

Subdivision (b) then states the exemption does not apply to the right to use the provider's software running on cloud infrastructure, or to access that software "from various client devices through either a thin client interface, including a web browser, or a program interface."

A program interface is an API. The statute draws the line between human effort and machine execution, then confirms that anything reached through an API sits on the taxable side regardless. Advisory work delivered by a person after you asked for it is exempt; the same analysis produced by a model behind an endpoint is not. That is the sharpest human-versus-machine boundary I have seen written into a state software tax, and it is not accidental - the exemption and the carve-out closing the API route through it are consecutive subdivisions.

Three more things worth knowing

Infrastructure is excluded. Draft Regulation 1600(a)(6)(E) excludes "digital infrastructure," described as cloud-based IaaS and PaaS "that allow customers to create, deploy, or run their own software application," from the definition of digital product. Raw compute sits outside the tax; the SaaS layer above it sits inside. Where you draw that line in your own product is now a tax question.

A fully automated sale can never be a California sales tax transaction. Draft Regulation 1600(c)(1) applies sales tax only where there is participation by a California place of business of the retailer - and "participation in the sale must involve some genuine physical human interaction with the sale from a California place of business." An agent-to-agent transaction has no such interaction, so it falls to use tax, moving the burden to the buyer.

The $5 million threshold flips who pays. Draft Regulation 1600.1 relieves a retailer of liability on sales to a single purchaser once they exceed $5,000,000 in a calendar year; the purchaser must then self-assess, obtain a use tax direct payment permit and report local use tax by place of first use, or seek a waiver. The threshold is per-purchaser and holds through 2031 before indexing.

How AgentTax handles California

Verified against the live engine while writing this, not from documentation:

• California is exempt across the board for agent work today. SaaS, API access, compute, data processing, cloud infrastructure and subscriptions all compute $0 through December 31, 2026. Prewritten software sold as a licensed digital good is the exception and is taxed now.

• The 2027 cliff is modeled. A SaaS transaction dated after January 1, 2027 computes $85.00 on $1,000 at ZIP 94102 - San Francisco's 8.5% combined rate on a 7.25% state component.

• Our infrastructure exclusion matches the draft rule. Compute, cloud infrastructure and data processing still compute $0 in 2027. Regulation 1600(a)(6)(E) is the first authority to confirm that position rather than merely permit it.

• API access defaults to $0 in 2027 and flags itself. We return a CA_SB122_PREWRITTEN_SOFTWARE advisory telling you to reclassify as SaaS if the product is prewritten software. That advisory is now understated: RTC 6372.1(b) puts a program interface outside the human-effort exemption. If you sell API access into California, do not rely on our conservative default past January 1.

• We carry 28 California ZIPs. Anything outside them returns the 7.25% state rate with a ZIP_UNKNOWN advisory rather than a guessed local figure - ZIP 94105, a short walk from 94102, returns $72.50 instead of $85.00.

One finding against our own classification: a transaction sent as consulting computes $85.00 in 2027, and consulting is close to the paradigm case of the 6372.1 exemption. That is an over-collection, and the fifth state where I have found this pattern in our handling of advisory work after New Jersey, Chicago, Ohio and Texas. I am logging it rather than editing it; taxability positions are guardrail-class here and do not get changed by the person who found them.

Try it on your own transaction types. Run a California SaaS transaction now (no account needed), or get a free API key. See where California sits in the 50-state SaaS taxability guide and the AI agent sales tax hub.

What to watch

The September 10 meeting, and whether anyone puts the machine-apportionment question on the record. The September 24 comment deadline, the last cheap opportunity to get a definition of "user" that contemplates non-human execution. Whether the emergency designation holds, since it decides how much of this text reaches January 1 unchanged.

And the question this package did not answer. We asked in July where an agent uses software. Draft Regulation 1600(e)(1) now replies: the place of use is where any right or power is exercised over the product, and "the right or power to remotely access a digital product is exercised at the place where the person accessing the digital product is located." That is a complete answer for a person and no answer at all for a process. At every load-bearing joint - the user, the participation in the sale, the human effort, the person accessing - the rule reaches for a human being. The agents are not in the text yet.

This analysis is for informational purposes only and does not constitute legal or tax advice. This post reflects AgentTax's current interpretation of evolving law. Consult a licensed tax professional for compliance decisions.