If your business sells services, software/SaaS, subscriptions, licenses, or other intangibles into California, the state just raised the bar on how you’re supposed to source revenue into the California sales factor. This is one of those rules that doesn’t look scary until you get audited—and then it’s expensive.
California’s Franchise Tax Board (FTB) finalized amendments to Cal. Code Regs., tit. 18, §25136-2 (market-based sourcing for sales other than tangible personal property). The FTB’s final rulemaking file makes the key point clear: the amendments are designed to apply prospectively for taxable years beginning on or after January 1, 2026.
What “market-based sourcing” actually means (in plain English)
California generally wants service and intangible receipts sourced to where the customer receives the benefit (or where the intangible is used), not where you performed the work or where your team sits.
So a company headquartered in Texas can still have a big California sales factor numerator if it sells to customers who use/benefit in California.
What changed for 2026 (the practical delta)
The amended regulation is meant to be more structured and more auditable—especially for industries and fact patterns where the old rules created ambiguity.
From the FTB’s final statement of reasons, you can see they explicitly moved the applicability date to January 1, 2026 to ensure the amendments apply prospectively.
Separately, the FTB’s Tax News Flash notes the amendments were approved by the Office of Administrative Law, filed with the Secretary of State on Aug 27, 2025, and have an effective date of Oct 1, 2025 (effective date ≠ when you’ll typically feel it on filed returns; the “first filing season impact” is the 2026 tax year for calendar filers).
Who gets hit hardest
You should assume this matters if you have any of the below:
SaaS / subscriptions / cloud services sold to customers with multi-state users
Professional services with lots of clients (think agencies, consultancies, managed services, legal/accounting-adjacent firms)
Licensing (software, IP, content, brand, data, know-how)
Financial services / asset management and other intangible-heavy revenue streams
Any business where your “customer location” data is messy or inconsistent across systems
Translation: if your revenue model scales by adding customers—not by adding physical shipments—this is your problem.
The core issue: your data model drives your tax result
These rules don’t just live in a tax workpaper. They live in your CRM, billing platform, product analytics, and contracts. If your data can’t answer “where is the customer receiving the benefit/using the product,” you’ll end up defaulting to weak assumptions—and that’s where audits get leverage.
The regulation itself bakes in a hierarchy concept: determine location, then reasonably approximate when you can’t, and in certain cases fall back to billing address. You can see this structure in the regulatory text around reasonable approximation and billing address fallback for intangible use.
Practical playbook: what you need to do before your first 2026 provision run
1) Inventory your revenue streams (don’t lump everything together)
Break revenue into buckets that map to sourcing rules:
services (implementation, consulting, support)
SaaS/subscriptions
licenses/royalties
data/content
other intangibles
If you source “total revenue” using a single blunt method, you’re asking for an adjustment.
2) Decide your sourcing “signal” for each bucket
For each bucket, define the primary data you will use to determine customer location / benefit location:
Common signals that hold up better
“Ship-to” / service delivery location for location-based services
user seat locations (admin-defined) for SaaS
usage telemetry by jurisdiction (when it’s actually reliable)
customer legal entity location plus documented user/benefit location when different
Signals that are weaker but sometimes necessary
billing address (works as a fallback, but it’s not always the “benefit” location)
HQ state when your customer is national/global (often wrong)
The FTB’s rulemaking file shows they were explicitly debating reliance on billing address and trying to align sourcing to where the benefit is received, which is exactly what auditors will push on.
3) Write down your “reasonable approximation” method
If you can’t pinpoint the location cleanly, you need a documented approximation method that is:
consistent
tied to real business records
explainable in one page
This is not optional. The regulation contemplates reasonable approximation when exact location can’t be determined.
4) Build an “audit file” now, not during the exam
Keep a sourcing support package for 2026 with:
a one-page policy memo: what we source, how, and why
system screenshots/data extracts showing where your sourcing fields come from
contract language showing customer locations / user locations when available
a mapping of revenue streams → sourcing method → underlying data source
a sample set of customer files showing the method in action
The FTB’s commentary makes clear they’re trying to reduce confusion and push toward more administrable, supportable application.
5) Pressure-test “big customer” edge cases
These are the ones that swing dollars and attract scrutiny:
enterprise customers with multi-state operations
reseller/channel structures
services delivered remotely but benefiting an in-state operation
intangible use that moves over time
What to expect in audits (and how taxpayers lose money quietly)
Most market-based sourcing disputes come down to one question:
Can you prove your numerator?
If you can’t, you’ll get forced into an approximation you don’t like—or worse, a default that inflates California receipts. The taxpayers who win are the ones who show up with a clean story and clean data.
CTA
If you sell services/SaaS, align your revenue data model with the sourcing rules before the first 2026 provision run.