Get four fields ready before California taxes your software in 2027.

Two states, one date, and four fields.

California signed Senate Bill 122 on 29 June 2026, and Colorado signed House Bill 26-1223 on 4 June 2026. From 1 January 2027 both states tax prewritten software however it reaches the customer, which includes a subscription somebody opens in a browser. For California that ends a position that had held for more than thirty years, and the state expects the change to raise around nine hundred million dollars a year for the general fund with roughly one point one billion more in local sales tax.

That much is in every alert. The part worth an hour of your time is what the statute actually asks you for. It does not ask what your product is. It computes the answer from four fields on records you already keep: the address on the customer, the class on the revenue line, what that customer has bought from you so far this calendar year, and the period the line covers. Three of those four are usually thin or missing in a billing system that has never had to charge sales tax on software. That is the actual project, and it is smaller and more concrete than the headline suggests.

What the two bills say, read from the text.

The mechanism in California is worth understanding because it has consequences the summaries skip. SB 122 does not create a separate tax on software. It amends section 6016 so that tangible personal property means either personal property perceptible to the senses or a digital product, and then defines the digital product in a new section 6016.1. Folding software into the existing definition means every rule that already keys off tangible personal property now reaches software without anybody rewriting it, which is how the existing economic nexus test picks up an out of state software seller.

One sentence in section 6010.9 deserves to be pulled out, because it is the cheapest thing on this whole list to act on. Custom computer software is defined to include those services represented by separately stated charges for modifications to existing prewritten computer software that are prepared to the special order of the customer. Separately stated is carrying that sentence. The same integration work, bundled into one platform fee or stated as its own line, gives two different answers, and both firm reads of the draft rules say a combined charge risks being taxable in full. Changing invoice structure in October is a billing change. Changing it in February is a restatement.

The address field carries more money than you would expect.

Section 6010.5(b)(3) sources a remote sale to the purchaser’s known address in California shown in your records maintained in good faith in the ordinary course of business, and where the purchaser gave you more than one it sets a fixed order: billing address, then shipping or delivery address, then the mailing address associated with the payment instrument, then the mailing address. Where the purchaser gave no address during the sale, the same order runs across addresses previously provided. Where none of it applies, section 6010.5(b)(4) deems the sale to be outside the state.

That fallback reads like relief and is better understood as exposure. Section 6054 relieves a retailer whose sale was sourced outside the state under that rule only where the retailer demonstrates to the department that it made a reasonable effort to obtain accurate and complete address information from the purchaser. So a blank address field is not a quiet exemption. It is a position you will be asked to evidence, and the evidence is easy to capture at the point of sale and close to impossible to reconstruct two years later.

The reason this field matters more than it looks is section 7202.1, which applies the same sourcing rule to local district tax. One address drives both the state rate and the local rate. Running the state base rates the calculator published on this site ships with, and supplying a district or local rate per address as the tool asks you to, the split is stark.

Look at the Denver line. The local portion is 14,184.00 dollars against 6,960.00 dollars of state tax, so the local rate carries more than twice what the state rate does, driven by the same address field. Colorado is a home rule state with self collecting municipalities, around seventy of which already taxed software before the state did, and Denver and Boulder already taxed remotely accessed software on their own account. The state change adds a layer to that patchwork rather than tidying it up.

There is a second address question hiding behind the first. Section 6010.5.1 places use where any right or power over the product is exercised, and says the right to access remotely is exercised where the person accessing it is located. That is a different attribute from the billing address, and it is what the draft multiple points of use framework would draw on. On the published reads of that draft, allocation by counting users or computers by location is treated as presumptively reasonable, while allocation by server location alone is not. Counting users by location means user records have to carry a location, which is a product question as much as a finance one.

Classify the line, not the product.

Section 6016.1 brings prewritten computer software inside the definition however it is delivered, and puts seven things outside it. The one that will matter most to software companies is digital infrastructure, which section 6016.1(c)(8) defines as a cloud based service provided remotely that lets a user create, deploy, scale or run the user’s own computer software on the provider’s platform without managing its own infrastructure. A seat subscription and a platform a customer runs its own code on are therefore not the same answer, even when they appear on the same invoice under the same product name.

Two clauses close off the obvious escape routes. Section 6016.1(c)(11) says software counts as prewritten if it is held or existing for general or repeated sale or lease even if it was initially developed on a custom basis or for in house use, and that a combination of two or more prewritten programs is included. So the product you built for one customer in 2022 and have sold eleven times since is prewritten, and assembling prewritten components does not make the assembly custom. On the Colorado side the same idea appears from the other direction: modifications to an existing platform do not by themselves make the underlying prewritten software exempt.

The practical consequence is that the taxability class belongs on the revenue line rather than on the product family, with the reason recorded beside it. A single blended platform fee that covers a seat subscription, a customer specific integration and infrastructure the customer deploys onto cannot be classified at all, and it cannot be split retrospectively without reissuing paper. Finding those fees is a morning of work in the catalogue and the most useful morning available before January.

A running total nobody has had to keep before.

Sections 6052 and 6201.55 are the provisions most likely to surprise a finance team, because they introduce a measure that does not exist in any billing system today. Once digital product sales to a single purchaser pass five million dollars in the aggregate in a calendar year, the seller is relieved of the liability to pay sales tax and of the obligation to collect use tax, and that purchaser self assesses instead. From 1 January 2028 the test looks at the current or the preceding calendar year. The amount is adjusted for inflation from October 2031, rounded to the nearest million.

Read that as a data requirement and it is specific. You need a cumulative digital product total per customer per calendar year, on a measure that matches the statutory one, visible to whoever approves an invoice before it goes out. Not a fiscal year, not all revenue, not a quarterly report. A number that can change who remits part way through a year, per customer.

The mechanics on the seller’s side are a document control problem. The purchaser obtains a use tax direct payment permit under section 7051.3 and issues a certificate to you. Section 7051.3(d) issues that permit for a period of twelve months, so what you hold expires on a schedule. Section 7051.3(f)(3) relieves you only where the certificate is taken in good faith, and makes the purchaser that issued it solely liable if the transaction turns out to be subject to sales tax, which is a strong protection and an evidenced one. Section 7051.3(f)(2) keeps a certificate effective until the holder revises or withdraws it or you receive actual notice that the permit was revoked, so you also need somewhere for that notice to land.

Two caveats keep this honest. The relief does not apply where the purchaser is an insurer. And section 6052(c) lets the department waive the purchaser self assessment where that is necessary for efficient administration, in which case you are liable again, with the purchaser required to give the department and you the places of business it expects to be a place of first use. So the customer record needs a dated status rather than a yes or no flag. It is also worth being clear about what the bill does and does not settle: the statute attaches purchaser liability to the transaction that caused the threshold to be exceeded, and the operating detail of how the rest of the year is treated sits in the draft rules rather than in the text.

The contracts you have already billed.

The question a controller asks first is usually about the contract already on the books: an annual subscription invoiced in October 2026 for a term running to September 2027. The bill gives an operative date and not an answer. The answer is forming in the California Department of Tax and Fee Administration draft package, published on 1 September 2026, discussed at a workshop on 10 September and closed for comment on 24 September 2026, with finalisation expected before the end of the year.

Two independent readings of that draft agree on the substance. Each subscription billing period is treated as a continuing sale, payments attributable to periods before 1 January 2027 fall outside the tax, and periods on or after that date fall within it. Take that at face value and the field that decides the answer is the service period on the line, not the invoice date and not the contract signature date. A twelve month term starting 1 November 2026 has two untaxed periods and ten taxed ones.

Because the draft can still move, the design that survives either outcome is the same: carry a service period start and end on every subscription line, and make sure credit notes and proration carry it too. A proration that loses the period it relates to cannot be split, and a credit note without a period cannot be matched back to the line it reverses. That is worth building now whatever the final text says, because it is also how you would restate if the text changes.

# The four fields, and where they sit. A worked example of structure.
# Nothing here describes a real customer, contract or company.

customer:
  id: CUST-1042
  legal_name: [customer legal name]
  # The address that sources a remote sale under RTC 6010.5(b)(3).
  # Effective dated, because the rule reads the record as it stood at the sale.
  addresses:
    - type: billing            # priority 1 of 4
      state: CA
      city: San Francisco
      effective_from: 2025-04-01
      effective_to: null
      source: signed_order_form
      captured_by: USER-118
    - type: shipping           # priority 2, held but not selected
      state: CA
      effective_from: 2025-04-01
      effective_to: null
      source: onboarding_form
  sourcing_decision:
    selected_address: billing
    priority_rank: 1
    basis: RTC 6010.5(b)(3)(B)(i)
    # Where no CA address exists at all, 6010.5(b)(4) sources the sale
    # outside the state. Section 6054 then asks what effort was made.
    reasonable_effort_evidence: null

  # Where the right to access is exercised, per RTC 6010.5.1. A different
  # attribute from the billing address, and the input an MPU allocation
  # would draw on if the draft framework survives.
  access_locations:
    - state: CA
      users: 180
    - state: TX
      users: 70
    measured_on: 2026-09-01
    method: named_user_count_by_location

  # RTC 6052 and 6201.55. Aggregate digital product purchases from us,
  # per calendar year. Crossing it moves the obligation to the customer.
  digital_product_ytd:
    calendar_year: 2027
    amount: 4_910_000.00
    threshold: 5_000_000.00
    status: approaching          # approaching | crossed | not_applicable
  direct_payment_permit:
    permit_number: [permit number]
    certificate_held: true
    taken_on: 2027-01-14
    taken_by: USER-118
    good_faith_basis: certificate_on_file_matched_permit
    expires_on: 2028-01-14       # RTC 7051.3(d), issued for 12 months
    waiver_in_force: false       # RTC 6052(c) puts liability back on us

revenue_lines:
  # The class belongs here, not on the product family.
  - line_id: LINE-9001
    description: Platform subscription, 250 seats
    tax_class: digital_product           # RTC 6016.1(a)
    class_reason: prewritten_software_accessed_remotely
    classified_on: 2026-10-02
    classified_by: USER-204
    service_period_start: 2026-11-01     # straddles 1 January 2027
    service_period_end: 2027-10-31
    amount: 240_000.00

  - line_id: LINE-9002
    description: Customer specific integration build
    tax_class: custom_software           # RTC 6010.9
    class_reason: separately_stated_modification_to_prewritten_software
    separately_stated: true              # the word the exemption turns on
    amount: 48_000.00

  - line_id: LINE-9003
    description: Managed runtime, customer deploys its own services
    tax_class: excluded_digital_infrastructure   # RTC 6016.1(c)(8)
    class_reason: customer_creates_deploys_and_runs_its_own_software
    amount: 36_000.00

# The split a continuing sale treatment implies for LINE-9001.
# Draft only: proposed Reg 1600, comments closed 24 September 2026.
period_allocation:
  line_id: LINE-9001
  periods_before_2027_01_01: 2           # Nov and Dec 2026, outside the tax
  periods_from_2027_01_01: 10
  basis: each_billing_period_is_a_continuing_sale
  rules_version: cdtfa_draft_2026_09_01  # restate if the final text moves

One note on the classification example above. The department’s own position in the draft, on the published reads, is that training software on jurisdiction specific content does not turn taxable software into exempt custom software merely because the outputs are individualised. Custom is a narrow door: software prepared to the special order of a single customer. Treat it as narrow when you classify, and let your adviser argue it wider if the facts support that.

Decide the pricing question on purpose.

There is a commercial decision sitting inside this that is easy to make by accident. Every contract without a tax clause that lets you add tax is a contract where doing nothing means absorbing it. The size of that is not a rounding difference. Running the same 240,000 dollar California subscription through the calculator twice, once with tax added to the price and once with the price treated as already including it, the tax inclusive version leaves 220,943.61 dollars as revenue instead of 240,000.00. Absorbing the tax on that one contract costs 19,056.39 dollars.

So there are three defensible answers, and one of them is a decision rather than a default: pass it on, absorb it and reprice at renewal, or split it by contract cohort depending on what your paper allows. What matters is that somebody chooses, writes it down, and checks the standard contract says the same thing. Three months is enough time to do that calmly. It is not enough time to discover in February that nobody did.

What to do between now and January.

• Pull a list of every customer with a California or Colorado address and check which address fields are actually populated. The four step priority in section 6010.5(b)(3) only helps if something sits in one of the four slots, and a blank set sources the sale outside the state, which is the answer you least want to defend later.
• Write down, per revenue line rather than per product, whether it is prewritten software, custom software prepared for a single customer, or a service that falls in one of the seven exclusions. Record the reason next to the class. Anything you cannot classify is a line that has to be split before January.
• Find every blended fee in the catalogue. A single platform charge that covers a seat subscription, a customer specific integration and infrastructure the customer runs its own code on has three different answers inside one number.
• Separate implementation and modification charges onto their own invoice lines now, while it is a billing change rather than a restatement. Section 6010.9 preserves the custom treatment for separately stated modification charges, and both firm reads of the draft say a combined charge risks being taxable in full.
• Build the per customer per calendar year digital product total and put it somewhere the person approving an invoice can see it. Five million dollars sounds far away until you notice it is measured per customer per year across every digital product line, and that crossing it changes who remits.
• Add certificate status and expiry to the customer record for any customer near the threshold, and diary the twelve month permit life in section 7051.3(d). A certificate taken in good faith is what relieves you, so keep the evidence of when and how you took it.
• Put a service period start and end on every subscription line, including credit notes and proration. If the draft treatment of each period as a continuing sale survives into the final rules, that field is what lets you split a term that straddles 1 January 2027 without reissuing the contract.
• Decide the pricing question deliberately and in writing: pass the tax on, absorb it, or split it by contract cohort. On a 240,000 dollar California contract the difference is 19,056.39 dollars of revenue, so this is a commercial decision with a date on it rather than a tax one.
• Check the economic nexus position even if you have no California presence. Because section 6016 folds digital products into tangible personal property, software sales count toward the existing threshold, so a company with real California revenue and no office there can still land in the same place.
• For Colorado, record which customers are on negotiated agreements and which are on standard terms, and hold the document reference. Then watch for Department of Revenue guidance, because the statute leaves the term undefined.
• Read the final CDTFA text when it lands rather than working from the September draft. Comments closed on 24 September 2026 and finalisation is expected before the end of the year, so the operating detail can still move.

Where this goes wrong, and how to see it coming.

• Treating this as a tax engine project. An engine answers what rate applies to a classified line sold to a known address. It cannot invent the address, decide which of your SKUs is prewritten software, or tell you what a customer bought from you so far this year. Those are your records, and three of the four fields are usually the thin ones.
• Classifying at product family level. One family routinely contains a seat subscription, a customer specific build and a platform component, which in California are a taxable digital product, likely custom software, and possibly excluded digital infrastructure. The class belongs on the line.
• Leaving implementation revenue bundled. It is the easiest thing to fix and the most expensive to leave, because the separately stated wording in section 6010.9 is what keeps the custom treatment available.
• Tracking the five million dollar threshold annually in a spreadsheet. It is a running total that can cross mid year and it changes who remits, so it belongs next to the invoice approval rather than in a quarterly review.
• Assuming a certificate on file settles it. Section 6052(c) lets the department waive the purchaser self assessment and put the liability back on the seller, and section 7051.3(d) issues the permit for twelve months, so what you hold is a dated status rather than a permanent exemption.
• Reading the district rate as a rounding detail. On the Denver example above the local portion is 14,184.00 dollars against 6,960.00 dollars of state tax, so the local rate carries more of the money than the state rate does, and it is driven by the same address field.
• Deciding the pricing question by default. Doing nothing means absorbing the tax on every contract that does not have a tax clause, which is a revenue decision made by omission.
• Building to the September draft as though it were final. The continuing sale treatment, the multiple points of use framework and the waiver mechanics all sit in a draft whose comment period closed on 24 September 2026.

Data and API considerations.

• Addresses need history, not just a current value. The sourcing rule reads your records as they stood when the sale was consummated, so a customer that moved in March leaves two different correct answers in the same year. An effective dated address with the source recorded answers that, a single overwritten field does not.
• The priority rank is itself data worth keeping. Section 6010.5(b)(3)(B) ranks billing above shipping above the payment instrument address above the mailing address. Recording which slot the selected address came from turns a later question into a lookup.
• Place of sale and place of use are different fields. Section 6010.5.1 puts use where the right to access is exercised, which is where the person using the software sits. That is a different attribute from the billing address, and it is the one the multiple points of use framework in the draft rules would draw on.
• A multiple points of use allocation needs a countable input. The draft treats allocation by counting users or computers by location as presumptively reasonable, and allocation by server location as not reasonable on its own. Counting users by location means user records carry a location, which is a product data question as much as a finance one.
• The threshold measure has to match the statutory measure. It is aggregate digital product sales to one purchaser in a calendar year, so it excludes non digital lines and it does not follow your fiscal year. A group of related buying entities is a question to put to your adviser rather than to assume.
• Certificates are documents with dates. Store the certificate, the permit number, the date taken, who took it, and the expiry, because section 7051.3(f)(3) turns on good faith and good faith is evidenced rather than asserted.
• Service periods have to survive credit notes. A proration or a mid term upgrade that loses the period it relates to breaks the split at 1 January 2027, and a credit note without a period cannot be matched to the original line.

The evidence to keep as you go.

The first audit conversation with a software company about 2027 is likely to start with a simple question: show me why this line was not taxed. Everything below is cheap to capture at the time and expensive to reconstruct, which is the usual signature of evidence worth designing for rather than gathering later.

• For each taxed line: the address used, which of the four priority slots it came from, the record it was read from, and the combined rate applied, so a reviewer can reproduce the rate without asking anyone.
• For each untaxed line: the reason, named against the statute. Custom software prepared for a single customer, a separately stated modification charge, one of the seven exclusions, a certificate held from a purchaser above the threshold, or a sale sourced outside the state.
• For each sale sourced outside California on the section 6010.5(b)(4) fallback: the evidence of the reasonable effort to obtain address information that section 6054 asks for. This is the one that is hard to reconstruct later and easy to capture at the time.
• For each customer near the threshold: the running total as it stood at each invoice, the certificate and permit with dates, and any waiver correspondence.
• For each contract spanning 1 January 2027: the service periods, the split applied, and the version of the rules it was applied under, so a change in the final text is a restatement with a known basis rather than a rebuild.
• For the catalogue itself: a dated record of the classification decision per revenue line and who approved it, because the first audit question about a software company in 2027 is likely to be why a line was not taxed.

This is the part that tends to decide how a first audit feels, and it is worth saying what a ledger can and cannot do for you here. Rivane records sales tax on a transaction as it posts with the rate and type set by jurisdiction, builds the liability by jurisdiction and period, rolls it forward, and drills from any summary figure back to the transaction behind it, which is the difference between reviewing a workpaper and rebuilding one. What it does not do is decide taxability for you or file your returns, and it is not a substitute for tax advice. Determination stays with you and your adviser. The fields above are what either of you will need to make that determination hold.

Questions worth asking at the next finance meeting.

• How many of our California customers have a billing address on file today, and how many would be sourced outside the state by default because none of the four fields is populated?
• Which of our revenue lines can we classify with confidence right now, and which are blended fees that have to be split before January?
• Is any single customer within reach of five million dollars of digital product purchases from us in a calendar year, and would we see it before the invoice went out?
• Are implementation and modification charges stated separately on our invoices today, and if not, how long would it take to change that?
• Have we decided whether we pass the tax on or absorb it, and does our standard contract have a clause that says so?
• For Colorado, can we tell from our records which customers are on a negotiated agreement and which accepted standard terms?
• Who is watching for the final CDTFA text, and what is the trigger that makes us revisit the design when it lands?

A tax change that is mostly a billing change.

Read as a compliance event, 1 January 2027 looks like a large project with a hard date. Read as a data brief, it is four fields and a pricing decision. Which address do we hold for this customer, and which slot did it come from. What class is this revenue line, and why. What has this customer bought from us this calendar year. What period does this line cover. Answer those four for your own book and most of the rest is configuration.

The genuinely good news is the timing. Every one of those fields can be populated before the date rather than after it, and three of the four are useful whatever the final rules say, because a customer address with a source, a revenue line with a class, and a subscription line with a service period are things a finance team wants anyway. The one piece to hold loosely is the draft detail: the continuing sale treatment, the multiple points of use framework and the waiver mechanics were all still in draft when this was written, with comments closed on 24 September 2026, so design for them and confirm against the final text.

If you want to put a number on your own exposure before doing anything else, the quickest start is the arithmetic. Take your California revenue for the year, split it by the addresses you actually hold, and price it both ways. The Rivane US sales tax calculator takes an amount, a state and a local rate, adds or removes the tax, and shows the state and local split separately, which is the same engine every figure in this article came from. It runs in the browser and it is free to use.

Sources

• California Senate Bill 122, Taxation, chaptered 29 June 2026, the budget related bill that adds sales and use tax on digital products. The chaptered text was downloaded and read section by section rather than through a fetched summary. Source for the amendment to section 6016 that brings a digital product inside tangible personal property from 1 January 2027, for the definition of a digital product and its seven exclusions in section 6016.1, for the definitions of accessed remotely and transferred electronically in section 6016.2, for the sourcing rule and its four step address priority in section 6010.5(b), for the place of use rule and the ninety day presumption in section 6010.5.1, for the custom software definition and the separately stated modification charge in section 6010.9, for the five million dollar purchaser threshold in sections 6052 and 6201.55 and the inflation adjustment from October 2031, for the address effort relief in section 6054, for the reproduction right exemption in section 6362.4, for the out of state use exemption and its certificate in section 6372, for the twelve month direct payment permit and the good faith certificate rules in section 7051.3, and for section 7202.1 sending local tax down the same sourcing rule.
• Holland and Knight, Coming Attractions: California Previews Rules on SaaS and Digital Products Tax, September 2026. Read directly. Source for the shape of the California Department of Tax and Fee Administration draft package: proposed Regulation 1600 published on 1 September 2026, the workshop held on 10 September 2026, the comment deadline of 24 September 2026, the treatment of payments for subscription periods before 1 January 2027 as outside the tax, the multiple points of use framework in proposed Regulation 1600.2 with user based allocation treated as presumptively reasonable and server location not, and the department position that training software on jurisdiction specific content does not turn taxable software into exempt custom software.
• Snell and Wilmer, CDTFA Proposes Emergency Regulations to Implement California’s New Sales and Use Tax on Digital Products. Read directly, and used as the second independent read of the same draft package. Source for the treatment of each subscription billing period as a continuing sale, for the allocation methods that count users or computers by location being presumptively acceptable while server location alone is not, for the direct payment permit and waiver mechanics sitting in proposed Regulation 1600.1 with a waiver request made before the purchase, for the position that combined charges for prewritten software and modifications may be fully taxable unless the modification work is significant enough to stand as custom software, and for the expectation that the package is finalised before the end of 2026.
• EisnerAmper, Colorado Expands Sales Tax to More Software Transactions Beginning in 2027. Read directly. Source for the Colorado position under House Bill 26-1223 effective 1 January 2027: software delivered by any means including download and remote internet access, the custom software exemption for software designed and developed for a specific customer, the surviving exemption for software governed by a negotiable license agreement and the point that a standard online subscription on uniform terms will not usually qualify, the note that modifications to an existing platform do not by themselves make the underlying prewritten software exempt, and the roughly seventy home rule cities that already taxed software before the state did.
• CliftonLarsonAllen, SaaS Sales Tax Rules in California and Colorado. Read directly. Used for two points it states plainly: that the Colorado negotiable license agreement exemption is not further defined in the statute and awaits Department of Revenue guidance, and that Denver and Boulder already taxed remotely accessed software independently of the state, so the state change adds a layer to a local patchwork rather than replacing it. Also carries the revenue estimates attached to the California change.
• Rivane US sales tax calculator. The combined state and local engine referred to in this article, published on this site. Every dollar figure quoted here was produced by running its own published logic, using the California and Colorado state base rates the tool ships with and a district or local rate supplied per address as an input, on both a tax exclusive and a tax inclusive basis.

A note on how this was researched. Every statement about what California law requires comes from the chaptered text of SB 122, downloaded and read section by section rather than through a fetched summary, and the section numbers quoted here are the ones in that text. That matters on one point in particular: the five million dollar threshold is easy to describe loosely, and reading sections 6052, 6201.55 and 7051.3 together is what surfaces the twelve month permit life, the good faith requirement, the insurer carve out and the department’s power to waive the purchaser self assessment and put the liability back on the seller. The California Department of Tax and Fee Administration package was still in draft at the time of writing, so it is cited through two independent firm reads that agree on the substance, and it is labelled as draft everywhere it appears. Colorado House Bill 26-1223 is cited through published analyses rather than the bill text, because the Colorado legislature site refused automated requests during research, and the points taken from it are limited to ones where two independent sources agree. The dollar figures were produced by running the published logic of the calculator on this site, using the state base rates it ships with and district or local rates supplied per address as inputs, and the tool’s own caveat applies: local rates vary widely and the effective rate at a given address has to be confirmed with the state. The four posts on X are public, were verified against the accounts and dates shown, and are quoted briefly and attributed. The data model and every identifier in it are a worked example of structure and describe no real customer, contract or company. Rivane has no public customers to cite and none are implied. Dates and details are as published at the time of writing, and with the California rules expected to be finalised before the end of 2026 and Colorado guidance on the negotiable license agreement exemption still outstanding, check the current text before acting. Nothing here is tax advice.