Is SaaS taxable in Alabama? A developer's guide to the exemption

If you're building a product that needs to calculate SaaS sales tax for your customers, this guide is for you. It covers Alabama's SaaS tax rules and rates, what to account for when you build sales tax calculation into your product, and how Ziptax returns accurate Alabama rates through an API without you building and maintaining a rate engine.

Alabama SaaS sales tax at a glance

Product Taxability Rules

State Registration & Collection Triggers

Which types of software does Alabama tax?

Alabama taxes software based on whether the customer takes possession of it, not based on a dedicated SaaS statute. Software a customer downloads or receives on physical media is taxable tangible personal property. Software a customer only accesses through a browser, with nothing transferred or retained locally, currently falls outside that definition under ADOR's enforcement practice.

Bundles are where implementations break, same as anywhere else. Apply taxability per line item, not per order: a SaaS subscription that ships a physical onboarding kit, a hardware component, or a required local agent stays exempt on the pure-access portion, but the tangible or locally-installed portion is taxable, and an undifferentiated lump sum drags the whole invoice into taxable territory.

How do you charge the correct sales tax rate for SaaS in Alabama?

Under current rules, you mostly don't. Because browser-based SaaS with no download is exempt, the sales tax on a remotely accessed subscription sold to an Alabama customer is $0. That changes the moment the product stops being pure SaaS: a downloaded client, a required local agent, a shipped device, or bundled canned software all bring tax back into the picture, and Alabama has no 2027-style transition to plan around, so this is the steady state, not a temporary one.

Before you build address-level rate logic, work out which of two seller profiles you are, because it changes how much of this you actually need.

Do you need the SSUT shortcut, or full address-level resolution?

Alabama's Simplified Sellers Use Tax (SSUT) program, under Ala. Code § 40-23-191 et seq., exists specifically for out-of-state sellers with no physical presence in Alabama. An eligible seller collects one flat 8.00% statewide rate on whatever revenue is taxable, files a single monthly return with ADOR, and never has to resolve individual county, city, or police-jurisdiction rates. The flat rate applies the same way regardless of which Alabama address the sale ships to.

SSUT does not decide what is taxable. It only simplifies collection once you already know a sale is taxable. A pure-SaaS seller with nothing taxable has nothing to run through SSUT in the first place. A seller who also sells a downloaded client, physical media, or a bundled device, and has no Alabama office, employees, or inventory, is usually the ideal SSUT candidate: one flat rate, one return, no rooftop lookups.

Address-level rate resolution, county and city stacking, and Alabama's police jurisdictions (areas just outside a city's limits where that city can still levy tax) matter for a different seller profile: one with physical nexus in Alabama, or one that is not enrolled in SSUT for some other reason. If that's you, the rest of this section applies in full. If you're a pure remote seller who occasionally sells a taxable add-on, SSUT is very likely the simpler path, and you may not need full rooftop resolution at all.

Engineering teams building for either profile have two options for calculating the correct rate on whatever portion of a sale is taxable: call a real-time sales tax API, or manually build and maintain an internal rate engine.

Option 1: Use the Ziptax Sales Tax API

If you need rooftop-level accuracy, because you have physical nexus in Alabama or you're not using SSUT, you send the buyer's address at the point of checkout, and the API evaluates the exact boundary lines, including the police-jurisdiction wrinkle described above.

To calculate a live rate against an Alabama address, use the v60 endpoint:

curl -G https://api.zip-tax.com/request/v60 \
    -H "X-API-KEY: <apiKey>" \
    -d key=your-api-key \
    --data-urlencode "address=600 Dexter Ave, Montgomery, AL, 36104"

To verify complete payload structures, explore the REST API documentation.

Three things to do with that response. Multiply by the combined rate rather than assembling it from the components. Store the jurisdiction on the transaction, because rebuilding it later from an address is lossy. Store the effective date too, because it is what lets you answer a question about a past period.

If your product catalog handles complex items like SaaS, custom development, or bundles, you can also pass a product taxability code to dynamically check product rules.Search for the correct product code and review Taxability Information Codes (TICs) to see how the response returns product-specific tax flags and exemptions.

What an API will not tell you: whether your company has crossed a nexus threshold in Alabama, whether you qualify for and have enrolled in SSUT, and whether a specific line item qualifies for the separately stated custom-development carve-out. All three stay on your side of the integration.

To automate threshold tracking, tax filings, and remittance, you can set up merchant management to connect TaxCloud automated compliance for your own business or for sub-merchants building on your platform.

Option 2: Build and maintain it yourself

A real choice if you already hold jurisdiction data for other reasons, and more realistic for a physical-presence seller than for an SSUT-eligible one. If you take this route, Alabama needs four things handled:

1. A product taxability decision separate from the rate lookup. Pure browser-based SaaS is exempt under current practice, which means the rate is not the operative question for it at all. Downloads, local agents or CLI components, physical media, and bundled tangible goods still need a rate.
2. A branch for seller profile. If you have no Alabama physical presence and enroll in SSUT, taxable revenue gets one flat 8.00% rate and nothing else. If you have physical presence, or skip SSUT, you need full address-level resolution instead.
3. Address-level rate resolution, for the physical-presence branch only. State, county, and city rates stack, and Alabama also has police jurisdictions: areas just outside a city's corporate limits where that city can still levy tax under state law.
4. An effective date on every rule. Local rates change more often than the state rate does, so a stored rate is only right until the next county or city change, and the SSUT flat rate itself can change by legislative action.

Four things to watch out for:

1. Defaulting everyone into rooftop resolution. If a seller is SSUT-eligible, building full county, city, and police-jurisdiction logic for them is unnecessary complexity. Check the seller's physical-nexus and SSUT-enrollment status before deciding which path applies.
2. Police jurisdictions, for sellers who do need rooftop resolution. A customer just outside a city's limits can still owe that city's tax on taxable purchases under Alabama law. This has no bearing on whether their SaaS subscription itself is taxable, and it does not apply at all to an SSUT-enrolled seller. Confirm the exact rate relationship before you encode it as a rule rather than a flag.
3. Treating the whole account as exempt. A customer who is pure SaaS today and adds a downloaded module, a required local agent, a shipped device, or a bundled implementation kit tomorrow introduces a taxable line your system needs to catch, not wave through on the old assumption.
4. Rate changes landing mid-period. A stored rate is right until a county, city, or the legislature changes it, and nothing tells you when that happened unless you are tracking effective dates.

When does a SaaS business have to collect sales tax in Alabama?

Registration and collection are two separate obligations with completely different triggers. Conflating them is where most engineering implementations go wrong, and it is especially easy to get wrong in an exempt state, where it is tempting to assume no tax means no obligations at all.

To get this right, view collection requirements and nexus, and have your application and billing stack track these two operational rules:

Rule 1: Monitor your registration triggers (nexus)

You must legally register to file with the state the moment either of these conditions is met:

• Physical presence: an employee working in Alabama, an office, inventory held in the state, or leased server capacity.
• Economic threshold: check economic nexus thresholds to determine if your retail sales of tangible personal property made into Alabama crossed $250,000 in the previous calendar year, under Ala. Admin. Code r. 810-6-2-.90.03(1). Pure SaaS revenue is not TPP, so it does not count toward this figure.

Rule 2: Apply the correct collection logic

This plays out very differently than it would in a taxable-SaaS state. A seller whose only Alabama revenue is pure browser-based SaaS, no download, no local agent, no physical media, no bundled tangible good, most likely never crosses the $250,000 threshold at all, because that threshold counts only TPP and pure SaaS isn't TPP. For that seller, there is typically no registration obligation to begin with, not a registration-plus-$0-return scenario.

Registration becomes a live question the moment some revenue is TPP: a downloaded client, a required local agent, physical media, or a bundled device. If that's you and you have no physical presence in Alabama, enrolling in SSUT is usually the simplest path once you register: one flat 8.00% rate on the taxable portion, one monthly return, no rooftop resolution. If you have physical presence in Alabama, standard registration and full local rate resolution apply regardless of how your revenue splits between SaaS and TPP.

Where Ziptax helps

If you're building a custom billing engine, a niche ERP, or a B2B SaaS platform, you don't need an enterprise compliance suite just to calculate an accurate checkout rate. You just need a fast, reliable endpoint.

Ziptax handles the infrastructure layer of sales tax calculation so your team can focus on your core product.

• Rooftop Precision: Resolves rates across 12,000+ U.S. tax jurisdictions using exact address and coordinate-based lookups, eliminating the accuracy liabilities of ZIP-based shortcuts, including Alabama's police jurisdictions, for the sellers who actually need rooftop resolution.
• Engineered for Platforms: Built specifically to embed live tax calculations directly into checkout workflows, API endpoints, and marketplace billing frameworks.
• Frictionless Pricing: Designed for cost-conscious development teams who want to pay strictly for active calculation calls without committing to heavy enterprise software contracts.
• The TaxCloud Runway: When your transaction volume scales or your users demand automated filing and remittance services, you can pair Ziptax with TaxCloud for the rest of compliance, including SSUT enrollment and filing if that's the right fit. You get a lightweight API to deploy today and a filing and remittance backend ready when you need it.

Get Alabama SaaS tax rates from an API

Address-level rates for every Alabama jurisdiction, plus the rest of the US, Canada, and select other markets.

Frequently asked questions

Do you have to register in Alabama if your SaaS product is exempt there? Not necessarily. Alabama's $250,000 economic nexus threshold is measured on retail sales of tangible personal property (TPP) made into Alabama, not gross revenue. Pure browser-based SaaS isn't TPP under current ADOR practice, so it doesn't count toward that figure. A seller whose only Alabama revenue is pure SaaS likely never crosses the threshold and has no registration obligation on that basis. If some of your Alabama revenue comes from a download, a required local agent, physical media, or a bundled tangible good, that revenue can push you over the threshold even though your core subscription stays exempt.

Does Alabama tax software differently depending on how it is delivered? Yes, and delivery, or more precisely possession, is the whole ballgame. Software a customer downloads, installs locally, or receives on physical media is taxable. Software accessed only through a browser, with nothing transferred or retained locally, is exempt under current ADOR practice. A SaaS product that bundles in a local agent or CLI tool risks losing that exemption on the local component. The one exception on top of that split is custom software development billed as a separately stated professional service, which is not taxed as software at all.

Can you use a ZIP code to get the Alabama sales tax rate? Not reliably, if you're a seller who needs address-level resolution in the first place. Alabama's combined rate is built from the state rate plus county and municipal rates, and a municipality can also tax addresses outside its own corporate limits under Alabama's police jurisdiction rules. A ZIP code does not line up with either boundary, so two customers who share a ZIP code can owe different amounts. Resolve the rate from the full street address instead. Note that an out-of-state seller with no Alabama physical presence may be able to skip this question entirely through the SSUT flat-rate program described below.

What is Alabama's Simplified Sellers Use Tax (SSUT) program, and should a SaaS seller use it? SSUT lets an out-of-state seller with no physical presence in Alabama collect one flat 8.00% statewide rate on taxable sales instead of resolving county, city, and police-jurisdiction rates individually, and file one monthly return with ADOR. It doesn't change what's taxable, only how you collect and remit once something is. For a SaaS company with no Alabama office, employees, or inventory, and some revenue from a download, a required local agent, or a bundled device, SSUT is usually the simplest way to handle that taxable slice.

Do local Alabama cities or police jurisdictions tax SaaS even though the state doesn't? For pure browser-based SaaS with no download, no. Alabama's local sales and use taxes generally follow the state's lead on what counts as taxable software, so a city or police jurisdiction does not independently tax a remotely accessed subscription the state exempts. Where local rates do matter is on whatever in the same account is actually taxable, a downloaded component, a required local agent, physical media, or an undifferentiated bundle, and only for sellers who aren't using the SSUT flat rate.

Sources

1. Software as tangible personal property (canned and downloaded software). https://www.revenue.alabama.gov/wp-content/uploads/2021/12/810-6-1-.37-.pdf 
2. Current ADOR administrative practice on SaaS. https://www.revenue.alabama.gov/ador-issues-guidance-on-taxability-of-computer-software/ 
3. Economic nexus and the $250,000 threshold (tangible personal property basis): Alabama Administrative Code Rule 810-6-2-.90.03. https://admincode.legislature.state.al.us/api/rule/810-6-2-.90.03 
4. Simplified Sellers Use Tax (SSUT) program: Code of Alabama 1975, § 40-23-191 et seq.; Alabama Department of Revenue SSUT program page. https://www.revenue.alabama.gov/sales-use/simplified-sellers-use-tax-ssut/   
5. Alabama state sales and use tax rates: https://www.revenue.alabama.gov/sales-use/tax-rates/ 
6. Streamlined Sales Tax (SST) status: Streamlined Sales Tax Governing Board, Alabama state details. https://www.streamlinedsalestax.org/state-details/alabama