Rigid Massachusetts Software Transaction Tax Needs a Safe Harbor

Feb. 17, 2026, 9:30 AM UTC

Massachusetts’ draft regulation on taxing software transactions introduces an upfront rigid apportionment regime that burdens multistate buyers with onerous compliance hurdles. And it doesn’t offer a safe harbor for those willing to overpay based on a fixed in-state use percentage. The system may work on paper, but it risks collapse when it encounters real-world complexity.

It would be fairer to make a simple path for those willing to pay their share—or more. A safe harbor fallback percentage would allow taxpayers to overpay without a fight rather than roll the dice on apportionment calculations and potential audits.

The draft regulation would overhaul how Massachusetts applies sales and use tax to standardized software in multistate business contexts. Under the new policy, any business that wants to apportion tax on a software purchase used across multiple states—indicating to the Department of Revenue that the tax shouldn’t be owed on the full purchase amount—would have to register through MassTaxConnect.

That registration triggers a software apportionment certificate. The buyer must then pair the certificate with a transaction-specific apportionment statement, complete with reasonable allocation percentage and clear supporting rationale, at the time of purchase.

And that isn’t all. The regulation requires this apportionment process even when the buyer is willing to accept a higher-than-necessary tax burden. A business that can’t, or doesn’t want to, calculate precise Massachusetts usage for a given piece of software must pay sales and use tax on the entire transaction—regardless of whether the software will be used by 500 employees in Boston or 5,000 in Boise.

The rule deputizes every multistate buyer as a mini-revenue department that must track use, audit employees, calculate percentages, and store paperwork for the inevitable audit. The state revenue department, for its part, assumes the role of apportionment umpire.

Enterprise software use is rarely as clean or compartmentalized as this policy structure would have one believe, though. Licenses are pooled across departments, rolled out through cloud platforms, bundled into contracts, and accessed remotely by employees who may not always live or work in one state.

Tracking exact usage across jurisdictions can be difficult; proving the usage can be nearly impossible. Even if a company wanted to comply, it may not be able to without investing in internal compliance infrastructure that could rival the rest of its technical endeavors combined.

The rule’s rigidity would punish businesses that may be willing to over-comply, which is never a good policy place to be. If a taxpayer with employees in a dozen states wanted to skip the administrative headache and just pay tax on a hypothetical generous 25% usage assumption, it wouldn’t be able to. Instead, it’d have to either document their logic, fill out the forms, and jump through all the hoops, or let the DOR assume the software is used 100% within the confines of Massachusetts.

Modernization shouldn’t mean further complicating an already opaque and tangled web of multistate transactions.
Modernization shouldn’t mean further complicating an already opaque and tangled web of multistate transactions.
Photographer: Alejandro Cegarra/Bloomberg via Getty Images

Taxpayers wouldn’t be the only one bearing this—the DOR would need to oversee this entire apportionment apparatus. It would be tasked with verifying registrations, policing certificates, and second-guessing usage statements if things don’t pass the sniff test. That’s a lot of unnecessary work to thrust into a system when a checkbox and a fixed percentage would be simpler.

The state should amend the draft regulation to allow business purchasers of standardized software to elect a fixed percentage for in-state use for tax purposes—no questions asked and with no immediate requirement of registration, an apportionment statement, or documentation of user locations or internal software deployment logic. Just a one-time binding election that allows companies to say, “We’re treating this as 25% Massachusetts use. Please tax us accordingly.”

This kind of safe harbor wouldn’t eliminate the full apportionment system; it would just serve functionally as a partial rollout. Companies that want to document actual usage could do so, and the DOR could cut its teeth on a smaller pile of compliance documents.

Audits, certificates, and transaction-level breakdowns would remain available to those who prefer precision or even wish to seek refunds later. But for everyone else, a fixed-percentage election would create a clean off-ramp.

The DOR could also implement the safe harbor on a transitional basis while evaluating how the certification regime performs in practice. If the documentation system works well, great—eliminate the safe harbor and go with the full rollout next year.

Massachusetts is right to seek to modernize how it taxes software. However, modernization shouldn’t mean further complicating an already opaque and tangled web of multistate transactions. Offering taxpayers a simple out would bring the state a rare trifecta in tax policy: higher voluntary compliance, lower administrative burden, and greater certainty on both sides of the deal.

If the state wants this regulation to work in practice, it should trust businesses that are trying to do the right thing. Make them pay—just don’t make them suffer to do so.

Andrew Leahey is an assistant professor of law at Drexel Kline School of Law, where he teaches classes on tax, technology, and regulation. Follow him on Mastodon at @andrew@esq.social.

Read More Technically Speaking

To contact the editors responsible for this story: Melanie Cohen at mcohen@bloombergindustry.com; Daniel Xu at dxu@bloombergindustry.com

Learn more about Bloomberg Tax or Log In to keep reading:

See Breaking News in Context

From research to software to news, find what you need to stay ahead.

Already a subscriber?

Log in to keep reading or access research tools and resources.