California Named the Regulation: the CDTFA's SB 122 Package Includes a Multiple-Points-of-Use Rule

The California Department of Tax and Fee Administration has posted its S.B. 122 implementation topic to the Business Taxes Committee's list of current informal rulemaking topics, with an interested parties meeting set for September 10, 2026. The listing names eight regulations, one of them new Regulation 1600.2, "Digital Products Purchased for Multiple Points of Use." The apportionment question we have chased since the July workshop now has a regulation number.

What the department actually posted

The topic reads, in the department's own words, as proposed:

"Revisions to Sales and Use Tax Regulations 1502, Computers, Programs, and Data Processing, 1507, Technology Transfer Agreements, and 1699.6, Use Tax Direct Payment Permits, and new Sales and Use Tax Regulations 1502.2, Custom Computer Software, 1600, Application of Sales and Use Tax to Digital Products, 1600.1, Tax Liability Threshold for Digital Products, 1600.2, Digital Products Purchased for Multiple Points of Use, and 1600.3, Digital Products Purchased Solely for Use Outside this State or in Interstate or Foreign Commerce"

The department describes the package as amendments and new regulations "to implement, interpret, and make specific the amendments and additions made to the Sales and Use Tax Law by Senate Bill No. 122 (Stats. 2026, ch. 23)." The Upcoming Meetings column reads "Interested Parties Meeting September 10, 2026." The Notice/Information column is empty.

That last detail is the honest headline: the discussion draft has not circulated. What has landed is the architecture and the date.

It also tells you where the draft will appear. The department's description of its own process says a Discussion Paper "generally include[s] ... the text of the proposed regulation(s)," and that the Business Taxes Committee "posts the Discussion Paper on its website" with an invitation to discuss it. So the awaited draft is a Discussion Paper, it goes on this page, and September 10 is the outside marker. The department gives no posting date for the listing itself and I will not guess one; as of our checks through August 22 the public record carried only "late August or September" and no regulation titles.

Reading the package by its regulation numbers

A regulation title is not a rule. But a department that has decided which regulations to write has already made structural decisions.

1600 — Application of Sales and Use Tax to Digital Products. The imposition regulation; everything else in the series hangs off it.

1600.1 — Tax Liability Threshold for Digital Products. The threshold gets a dedicated regulation rather than a subdivision. Practitioner readouts of the July 21 workshop described a vendor-specific dollar threshold that flips buyers into use-tax self-assessment once crossed, which we wrote about on August 1. The title does not confirm the number, only that the mechanism is being built.

1600.3 — Digital Products Purchased Solely for Use Outside this State or in Interstate or Foreign Commerce. The mirror image of 1600.2 — and note "solely." A process that touches California once in a billing period is not solely anything.

1502.2 — Custom Computer Software. The custom-versus-prewritten boundary gets its own regulation. It decides whether a bespoke agent stack sits inside or outside the base, and it is where the fights will be.

1699.6 — Use Tax Direct Payment Permits. Amended, not new.

Why 1600.2 is the one that matters for agent operators

When we read the Massachusetts multiple-points-of-use rule on August 16, we were working from a signal in a workshop readout — that the CDTFA was evaluating apportionment modeled on other states, Massachusetts among them. The bet paid. Multiple points of use is not a footnote to a certificate procedure here. It is a standalone regulation with its own number, sitting between the imposition rule and the out-of-state-use rule, which is where an apportionment mechanism belongs if the department intends it to do real work.

None of which resolves the objection we raised. These regimes apportion by a denominator, and the denominators they use are licensed users and terminals or devices per jurisdiction. An autonomous agent operator has neither: there is no seat to count, the process runs where the scheduler put it, and the one geography the operator gets for free — server location — is the thing developed multiple-points-of-use regimes typically refuse to measure by. A regulation number tells you the mechanism will exist. It does not tell you whether the denominator will reach consumption, benefit, or anything else an agent produces.

Denver has run a municipal use-based apportionment rule since at least 2021; Massachusetts does it at state scale; California is now writing the third. Three jurisdictions independently refusing the single situs an autonomous system produces cheaply is a direction of travel. Plan for allocation to be the normal case.

Regulation 1699.6, Use Tax Direct Payment Permits, points the same way. An existing regulation amended inside a digital products package reads as a department expecting a class of buyers to self-assess rather than be charged at the register. That inference is mine — the listing says only that 1699.6 is being revised — but it fits every multiple-points-of-use regime we have examined, where the purchaser certifies, allocates and accrues. If so, the allocation burden sits with the buyer, and for an agent operator buying model access and hosted components, the buyer is you.

Two rulemakings, one regulation

Easy to miss: the department's 2026 Rulemaking Calendar carries a separate item — under the schedule for statutes enacted before 2025 — amending Regulations 1502 and 1507 and adopting new Regulation 1507.1, Software Technology Transfer Agreements, which the calendar describes as implementing the technology transfer agreement statutes together with the Nortel Networks (2011) and Lucent Technologies (2015) decisions, projected for notice publication in September 2026. The S.B. 122 package does not appear on that calendar at all: no 1600-series entry, no reference to S.B. 122 anywhere in it.

So two amendment streams are converging on Regulation 1502 on roughly the same schedule — one formal and nearly ready for notice, one informal and heading into a meeting. Anyone reading the current text of 1502 to plan for January is reading a regulation with two pending edits that have not been reconciled in public.

What agent operators should do before September 10

Get on the list. The Business Taxes Committee accepts requests by email to join a topic's mailing list. That is how the Discussion Paper reaches you the day it posts, not the week practitioners write it up.

Start the allocation record now, not when the text lands. Whatever denominator 1600.2 adopts will demand contemporaneous records. No apportionment rule can be satisfied by reconstruction, and the period you will need to substantiate has already started.

Decide who your purchaser is. If 1699.6 is being amended because buyers will self-assess, the entity that signs the software agreement inherits the allocation obligation — an org-chart question with a tax consequence, cheaper to answer now than to unwind later.

Write the comment you want to make. The meeting is the last practical venue to affect the text before formal rulemaking begins, and the useful comment is not "agents are different" — it is a specific proposed denominator an operator can measure and an auditor can test.

What our engine does today, stated plainly

For a $100 SaaS sale to a California buyer, AgentTax returns $0 today and $7.25 after the January 1, 2027 flip — the 7.25% state rate — rising to $9.75 in ZIP 90001, where the Los Angeles district adds 2.50%. API access, raw compute and cloud infrastructure return $0 on both sides, on the basis that S.B. 122 reaches prewritten software and SaaS rather than infrastructure or custom software.

Two limits worth disclosing. We carry 26 California ZIPs; an unmodelled California ZIP returns the state rate with a ZIP_UNKNOWN advisory rather than a district-inclusive answer, so treat it as incomplete rather than final. And we do not apportion — one destination state produces one answer. If 1600.2 arrives with an allocation election, that is a modelling gap on our side, and I would rather name it now than be asked in January.

Nothing here changes our engine's treatment of anything; California's cell was already dated to the 2027 flip.

What to watch

Whether the Discussion Paper posts before the meeting or with it, and whether it carries proposed text for all eight regulations or only some. Whether 1600.2's denominator is written in terms of users and devices or something broader. Whether 1600.3's "solely" is softened to a predominant-use test. And whether the department reconciles the two pending edits to Regulation 1502.

If you are mapping which software inputs in your agent stack become taxable in California, how they should be sourced, and what the January 2027 flip does to your cost, that is the classification and situs problem AgentTax is built to model, effective-dated change included. See the per-jurisdiction logic at agenttax.io.

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.