Denver Runs Its Own Multiple-Points-of-Use Rule, and Colorado's State Exemption Never Reaches It

Colorado does not tax software as a service at the state level, and will not until January 1, 2027. Denver taxes it now, under its own municipal code, on its own base, with its own registration. For an operator selling agent output into Colorado, those are not two views of one tax; they are two taxes, and only one of them is switched off today.

We have written about the state half of this — HB 26-1223 and the January 2027 flip — and that post said the home-rule cities were a patchwork that practitioners advise evaluating one at a time. That was true and it was also a hand-wave. This post does the thing the earlier one deferred: read one home-rule city's actual guidance and see what it demands of a machine buyer.

What Denver's guide says

Denver publishes Tax Guide Topic No. 18, "Software," revision 01/2021. Its first sentence is the whole problem: the Denver Revised Municipal Code "imposes sales or use tax on the purchase price for software programs, software as a service, software license fees, and software maintenance agreements." The guide points to DRMC sections 53-54(7) and 53-104(7) as the imposition provisions. Software as a service is defined in its own right — "Software that is rented, leased, or subscribed to from a provider and used at the consumer' location, including but not limited to applications, systems, or programs." There is no ambiguity to litigate about whether a subscription counts. It counts.

The taxability test is in Section B, and it has two elements. The transaction must be a retail sale, meaning a retailer, a retail purchaser, a transfer of title or possession, and consideration. And the sale, storage, use, distribution or consumption must occur in Denver.

That second element is where this stops being a routine city tax and starts being an apportionment regime. The guide is explicit:

Software that is used in Denver is subject to Denver's sales or use tax, regardless of where the software resides (inside or outside of Denver). If a retail purchaser uses software both inside and outside of Denver, Denver's tax is due only on the portion of the purchase price attributable to the software used in Denver. If the software resides on a server outside Denver and one or more users located in Denver access the software, only those charges attributable to the use of the software in Denver are subject to Denver's taxes.

Read that against what we wrote five days ago about Massachusetts and multiple points of use. Massachusetts permits apportionment by users or terminals per jurisdiction and forbids apportioning by server location. Denver arrives at the same place from the other direction: it declares server location irrelevant to the imposition and then measures the tax by where the software is used. Two jurisdictions, one state-level and one municipal, both refusing the only geography an autonomous system produces for free.

The rest of Section B and C is a bundling rule and it is a familiar one. Mandatory service charges — anything the purchaser cannot decline and still acquire the software — are taxable even when separately stated. Non-mandatory charges are not taxable if they are separately stated and identified. Genuine personal services, the work-for-hire category where the provider retains no rights in the work product, sit outside the tax entirely, with the guide listing installing software, writing code, systems design, consulting and feasibility studies as examples.

Why the state exemption does not travel downward

Colorado is a home-rule state, and Denver self-administers. That phrase gets used loosely, so here is the operational content: Denver sets its own base, publishes its own guidance, and takes its own registration and remittance. The Colorado Department of Revenue does not collect Denver's tax and does not decide what Denver's tax reaches. A state-level exemption for remotely accessed software is an exemption from the state's 2.9%, and that is all it is.

There is a second-order consequence that matters more than it sounds. Colorado's state-collected special districts and county levies — the Regional Transportation District, the cultural facilities district, county conformity — are levied on transactions the state itself taxes. They ride on the state base. So on a state-exempt SaaS sale into Denver today, the district portion is not merely someone else's problem; it is not due at all, and collecting it would be an error in the other direction. Our engine grounds that split in C.R.S. 32-9-119(2)(a) for the transportation district, with parallel provisions for the cultural district and county conformity. I have not re-read those sections against the published statute in this session, so take the pinpoints as the engine's verified position rather than as my own reading; the operative principle — district levies follow the state base, the home-rule city's tax does not — is corroborated by the district's own definition of the transactions it reaches.

What our engine returns

A $100 SaaS sale to a buyer in Denver ZIP 80202, priced today, returns $5.15. That is Denver's municipal rate alone: 5.15 percent, verified against the city's own rate guidance on 2026-08-17. The state's 2.9 percent is exempt, and the 1.10 percent of state-collected district tax stacked into the combined local figure is dropped rather than charged. The response carries a self-administered-locality advisory saying, in terms, to register and remit directly with Denver and not through the state.

Price the same transaction on a date after the HB 26-1223 flip and it returns $9.15 — the state's 2.9 percent, the districts that now have a state-taxed transaction to attach to, and Denver's 5.15 percent, which never moved.

The honest limitation: we carry seventeen Colorado ZIPs with home-rule treatment modelled. Colorado has scores of self-collecting municipalities. A buyer ZIP outside that set returns a zip-unknown advisory and a state-only answer, which today is zero — and zero is the wrong number if that city taxes software the way Denver does. Treat an unmodelled Colorado ZIP as unanswered, not as exempt. We would rather say that than let a silent $0.00 read as a determination.

Practical impact

Capture buyer location at a finer grain than state. Everything in this post turns on knowing that a user is in Denver rather than in Colorado, and a state code cannot carry that.

If your customers use your product from more than one place, Denver's apportionment language is an invitation and an obligation at once. It caps the city's reach at the Denver-attributable portion, but only if you can substantiate the portion. Usage telemetry you already collect for other reasons is likely the closest thing you have to a defensible allocation, and it is worth deciding now whether it would survive being shown to a city auditor.

Unbundle deliberately. The mandatory-charge rule means onboarding, setup or support that a customer cannot decline is taxable at the software rate no matter how the invoice is laid out. Restructuring those as genuinely optional, separately stated line items is a pricing decision with a tax consequence, and it has to be real to work.

Register where you actually owe. A Colorado state license does not authorize you to collect Denver's tax and does not discharge it. If you have customers in self-collecting cities, that is a per-city registration exercise.

What to watch

Whether Denver updates Topic 18 ahead of the state's January 2027 change, since a guide last revised in 2021 will be describing a very different relationship to the state base once HB 26-1223 takes effect. Whether other Colorado home-rule cities publish software guidance with apportionment language of their own, or whether Denver's use-based test stands alone. And whether California's forthcoming SB 122 regulations borrow the same structure — the CDTFA has said it is evaluating apportionment modeled on Massachusetts, and Denver is quiet evidence that the model has been running at municipal scale for years without anyone calling it multiple points of use.

Nothing in this post changes our engine's treatment of anything. Colorado's state cell was already dated to the 2027 flip and the home-rule guard was already charging the municipal component alone.

AgentTax determines transaction tax per call — jurisdiction, rate, and the basis for the classification, including whether the locality collects its own. See the per-jurisdiction logic at agenttax.io, or start with the AI agent sales tax hub. Denver's guide is published by the city's Treasury Division as Tax Guide Topic No. 18.

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.